Adds some missing PEMicro GDB server functionality

[KGU-SRE]

• fixes pemicro loading of multiple files - current release [1.12.1] erases whole flash for each object/binary file this fixes it so erase only happens once
• adds pemicro preserving of memory ranges
• adds pemicro catching of exceptions

[tsweaver321]

@KGU-SRE Many thanks for this! It's exactly what I need. Hopefully, this PR gets merged soon.

[tsweaver321]

@KGU-SRE I have your 1.12.2-pre installed in my VS Code. I've attempted to define a preserved range as follows, but it doesn't seem to be working. Is my configuration correct? Do you have a working launch.json (successfully preserves a flash range) that you could share?

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "cortex-debug",
            "request": "launch",
            "name": "Debug with PE Micro GDB Server",
            "servertype": "pe",
            "device": "NXP_S32K1xx_S32K148F2M0M11", // Specify your target device
            "rtos": "FreeRTOS",
            "executable": "${workspaceFolder}/Debug/app.elf", // Path to your ELF executable
            "pemicro": [
                {
                    "preserve_ranges": [
                        {
                            "preserve0": [
                                {
                                    "enabled": true,
                                    "start": 0,             // 0x00000000
                                    "stop": 16383           // 0x00003FFF
                                }
                            ]
                        }
                    ]
                }
            ],
            "cwd": "${workspaceFolder}",
            "serverpath": "${workspaceFolder}/tools/com.pemicro.debug.gdbjtag.pne_5.7.5.202311071732/win32/pegdbserver_console.exe", // Path to pegdbserver_console executable
            "showDevDebugOutput": "both",
            "runToEntryPoint": "true",
            "showDevDebugTimestamps": true,
            "svdFile": "${workspaceFolder}/tools/S32K148.svd", // Path to your SVD file
            "postLaunchCommands": [
                "break main",
            ],
        }
    ]

}

[KGU-SRE]

here is a sample "pemicro" configuration snippet:

"pemicro": {
    "preserve_ranges": {
        "preserve0": {          // keep bootloader
            "enable": true,
            "start": 4194304,   // 0x400000
            "stop": 4325375     // 0x41FFFF
        }
    },
    "exception_catching": {
        "busfault": true,
        "checking_error": true,
        "exception_entry_or_return": true,
        "hardfault": true,
        "memmanage": true,
        "no_coprocessor": true,
        "reset_vector": true,
        "state_info_error": true
    }
}

If you use intellisense (ctrl+space) it will also give you the correct syntax

[tsweaver321]

I just confirmed with the pre-release that the ability to define preserved memory ranges works as expected.

[haneefdm]

Can we separate this into two PRs. One for loading/preserving and one for exceptions. Other questions

• Why preserve0/1/2 instead of an array of preserves?
• We don't do this preserve stuff with any other gdb-server. Why is it needed here? Needs to be explained both here and in code
• For exception catching, is this really a good way to do this? Why can't this already be done with post/pre/override launch commands? Is this how other debuggers do this?

Finally, are you willing to support the pemicro server interface support in the future?

[tsweaver321]

@haneefdm Regarding your question about why it's needed -- For those transitioning from NXP's S32 Design Studio, these are features we're used to having available.

[haneefdm]

I still think "Why preserve0/1/2 instead of an array of preserves?" is valid. NXP may have done it that way for GUI convenience but doesn't an array make more sense? Waiting on @KGU-SRE to respond. Also, why can't this be done with existing launch.json properties?

The changes we make should make sense for the longer term and be coherent with how we support other gdb servers.

[tsweaver321]

@haneefdm If these PE specific properties did not exist, how would PE users know these capabilities exist and how to use them?

[KGU-SRE]

@haneefdm this structure mirrors the syntax of the raw commands being passed to the GDB server. I like it because it explicitly defines the the whole interface (3 separate named ranges that can be enabled/disabled) in a way that is discover-able via intellisense suggestions.