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.

[haneefdm]

I don't like device-specific information creep into what is supposed to be support for a particular probe. I would rather go by the capabilities of the probe rather than one specific device/family from one specific vendor.

[KGU-SRE]

@haneefdm this functionality is probe specific. It just had to be reverse-engineered from the STM32 IDE.

[haneefdm]

It just had to be reverse-engineered from the STM32 IDE.

We had to do that to all the probes we supported to some extent, at least initially. But they eventually co-related with the probe documentation. Reverse engineering should not be our only reference.

@haneefdm this functionality is probe specific

The stuff that is in the "Debugger" tab of Eclipse may be probe specific. The other dialog stuff is not. Please point me to the documentation from PEMicro documentation. You can also do monitor help to get monitor specific commands -- if it is a good gdb-server.

[tsweaver321]

@haneefdm As a user of these tools, I would say usability of the tool should be right up there as a goal along with code maintainability. Otherwise, few are going to use it. It's not clear if you share that view. Settings up a new dev environment can be (and often is) a long and frustrating experience as it is without building obscurity in as a feature. Please put the development ideology aside and think link a user who is new to all of this and trying to figure it all out.

[haneefdm]

@haneefdm As a user of these tools, I would say usability of the tool should be right up there as a goal along with code maintainability. Otherwise, few are going to use it. It's not clear if you share that view.

I am not going to argue about this anymore. Your idea of usability is different from mine. I care a LOT about usability -- but for all and on balance.

Please put the development ideology aside and think link a user who is new to all of this and trying to figure it all out.

Thanks for the free lecture, but not sure what you are talking about. I am asking questions and instead of answers to help me understand, I am getting lectures.

For every probe that needs special attention, we have a (short) Wiki page that describes it. Anyone can edit/create it. If there is zero probe documentation we can refer to, then we have an issue. Adding functionality comes with responsibility.

Maybe PEMicro is too proprietary and closed for me to support/add.