NUCLEO-H503 Debug Support

[Calamity1911]

Hello all,

I recently purchased a Nucleo H503 development kit from STMicro. I was able to create a project using CubeMX which is just a simple blinky using LD2 on the board and a hardware timer.

I generated the project as a Makefile project, and opened it in VSCode. Within VSCode, I have the "official" STM32 extension, which depends on the cortex-debug extension. The issue then arose when I tried to actually debug the chip just to see if I could. Below is the launch.json which was used. I know that this platform supposedly also supports some form of authenticated debugging system if the chip has been properly provisioned, but using CubeProgrammer, I ensured that all related features were disabled and the product state was set to "open."

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Cortex Debug",
            "cwd": "${workspaceFolder}",
            "executable": "./build/h503dk.elf",
            "request": "launch",
            "type": "cortex-debug",
            "runToEntryPoint": "main",
            "servertype": "stlink",
            "gdbPath": "C:/arm-toolchain/bin/arm-none-eabi-gdb.exe",
            "serverpath": "C:/ST/STM32CubeCLT_1.16.0/STLink-gdb-server/bin/ST-LINK_gdbserver.exe",
            "svdFile": "C:/ST/STM32CubeCLT_1.16.0/STMicroelectronics_CMSIS_SVD/STM32H503.svd"
        }
    ]
}

Attempting to debug produces the following output.

Waiting for gdb server to start...[2024-08-10T04:03:46.543Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session connected. You can switch to "DEBUG CONSOLE" to see GDB interactions.
"C:/ST/STM32CubeCLT_1.16.0/STLink-gdb-server/bin/ST-LINK_gdbserver.exe" -p 50000 -cp "C:\\Program Files\\STMicroelectronics\\STM32Cube\\STM32CubeProgrammer\\bin" --swd --halt

STMicroelectronics ST-LINK GDB server. Version 7.8.0
Copyright (c) 2024, STMicroelectronics. All rights reserved.

Starting server with the following options:
        Persistent Mode            : Disabled
        Logging Level              : 31
        Listen Port Number         : 50000
        Status Refresh Delay       : 15s
        Verbose Mode               : Disabled
        SWD Debug                  : Enabled

COM frequency = 24000 kHz
Target connection mode: Default
Target connection failed. Try connecting under reset
Target connection failed
COM frequency = 8000 kHz
Target connection mode: Default
Target connection failed. Try connecting under reset
Target connection failed
COM frequency = 3300 kHz
Target connection mode: Default
Target connection failed. Try connecting under reset
Target connection failed
COM frequency = 1000 kHz
Target connection mode: Default
Target connection failed. Try connecting under reset
Target connection failed
COM frequency = 200 kHz
Target connection mode: Default
Target connection failed. Try connecting under reset
Target connection failed
COM frequency = 50 kHz
Target connection mode: Default
Target connection failed. Try connecting under reset
Target connection failed
COM frequency = 5 kHz
Target connection mode: Default
Target connection failed. Try connecting under reset
Target connection failed
Target unknown error 32

Error in initializing ST-LINK device.
Reason: Unknown. Please check power and cabling to target.

Again, I verified that I could actually communicate with the device by manually loading the generated .elf file using CubeProgrammer, and the firmware does indeed blink LD2. CubeProgrammer doesn't seem to have any issues communicating with the Cortex-M33 core on the STM32H503, so I'm just curious if anyone has any ideas as to how I can actually debug using VSCode.

Let me know if there is any other information that could be helpful.

[haneefdm]

We don't connect to the chip/board. The STLink gdb-server does. Focus on the following

"C:/ST/STM32CubeCLT_1.16.0/STLink-gdb-server/bin/ST-LINK_gdbserver.exe" -p 50000 -cp "C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin" --swd --halt

This command has to work. Maybe additional options are needed in launch.json. See how ST is using the gdb-server. Also, contact ST.

Are you using STs VSCode plugin? It may generate the proper launch.json for you.

[DanielLiebler]

Hi, Im probably a bit late to the party, but I ran into this issue some time ago, too. Even though the processors are not multicore, you need to set the apID to be able to connect.

so as in your launch.json you need to add: "serverArgs": ["-m 1"],

STM32CubeIDE also uses this flag to debug.

I tested it for H503 and for H563, but this is probably applicable to the whole H5 family.