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.

[KGU-SRE]

The PEMicro GDB server is only provided by PEMicro for use as part of an eclipse plugin https://www.pemicro.com/products/product_viewDetails.cfm?product_id=15320151

Public documentation of the functionality is only provided of the GUI interface https://www.pemicro.com/downloads/download_file.cfm?download_id=459

For clarity here is the full extent of GDB commands documented publicly in the documentation provided by PEMicro

The missing/undocumented functionality was discovered as a part of my personal reverse-engineering efforts. Unfortunately I no longer have access to the probe HW so I am no longer able to provide extra input. If more documentation/development effort is needed someone else needs to provide it.

[SMNJS]

Hello,

I hope this is the right place to ask a further question for loading multiple files using a PEMicro probe with the cortex-debug extension.

I am using a PEMicro Debugger for several years now and currently I am switching from eclipse based development to VS code with your cortex-debug extension.
For now, I managed to get single application launching and attaching to work, but my final issue is launching multiple files as described above. As PEMicro currently uses GDB v8.3 for it's eclipse plugin (and its covered gdb and the gdbserver console), I need to use cortex-debug v1.4.4 in order to make it work.

I can't catch up how you did access the PEMicro GDB server with cortex-debug v1.12.1 or v1.12.2 prerelease without having the GDB version restrictions.
Can you tell me what I am missing here, as I really would like to use the possibility to load multiple files with the extension.

Furthermore: is there any plan to update the cortex-debug extension as a full release with this feature?

Kind regards.

[haneefdm]

First, PEMicro needs a maintainer. I can't do it since I don't have any HW and I do not like huge customizations for silicon vendors or proprietary probes with no documentation or support. So, this PR is unlikely to make it into a release.

Second, we will not support super old versions of GDB as that will break many aspects of what cortex-debug does. We had big compatibility issues. We moved to version 9+ and not looking back. I am not sure that there is even a dependency between PEMicro and gdb. It may be specific to the Eclipse plugin you were using.

Also, it is not that PEMicro uses gdb, it is the other way around gdb is a client of PEMicro's gdb-server. Also, gdb 8.3 is from 2019. I am surprised that PEMicro has not been updated since.

[SMNJS]

Ok so at first thank you for the super quick response!

I already contacted the PEMicro support due to the old gdb version they are using but to me it seems they don't see a strong necessity of upgrading, as the old version fully fits their needs. Nevertheless they put my request to the development list, so lets see how this develops in the future.

As they also mentioned that GDB is generally good at maintaining backwards compatibility, they suggested using just a never version of the arm-none-eabi-gdb with my current gdbserver console. The latest version from the latest toolchain failed when trying to flash my device, but earlier releases (in my case GNU gdb 10.2.90.20210621-git from GNU Arm Embedded Toolchain 10.3-2021.10) works just fine with both the latest version of your extension as well as the pemicro gdb server console.

So at this point, thank you for the idea of exchanging this!

Finally there is just one question for me:
is there a possiblity to test the coretx-debug v1.12.2pre as mentioned above (which should fix the mutli load), as I can't see this version in the releases panel. Or did I get anything wrong? Is there no v1.12.2pre for testing?

kind regards