STM32H503 Debugging Issue in CLion 2026.2.3

Hi MarcV!

I'm having trouble debugging STM32H503 devices from CLion 2026.2.3 using the built-in STM32 support.

By the built-in STM32 support, do you mean the ST-LINK debug profile (Settings | Build, Execution, Deployment | Debugger | Debug Profiles)?

If so, please provide screenshots of all tabs of this debug profile.

I was eventually able to get debugging working in CLion by creating a custom Embedded GDB Server configuration using the same ST-LINK GDB Server command line generated by CubeIDE.

Please share the command with which the debugging process succeeded and a screenshot of the Embedded GDB Server configuration.

By the built-in STM32 support, do you mean the ST-LINK debug profile (Settings | Build, Execution, Deployment | Debugger | Debug Profiles)?

Yes, I use the built-in ST-LINK profile that works perfectly fine with my STM32G0 and STM32G4 projects, but not with a STM32H5 based board.

With the help of an AI tool I managed to figure out how to setup a custom Embedded GDB Server configuration which seems to work…

The name of this particular project is “speedtest”…

These are essentially the settings as they are used by STM32CubeIDE for that type of microcontroller. With this configuration I can start a debug session but the “RUN” button is greyed out.

MarcV, thank you for the provided details!

I see that in the command used by the ST-LINK debug profile, the GDB server and programmer from C:\ST\STM32CubeCLT_1.22.0 are used. While in the Embedded GDB Server configuration, you use the GDB server and programmer from C:\ST\STM32CubeIDE_2.2.0\STM32CubeIDE\plugins.

Could you please check if this makes any difference? What happens if you change the GDB server and programmer in the Embedded GDB Server configuration to C:\ST\STM32CubeCLT_1.22.0\STLink-gdb-server\bin\ST-LINK_gdbserver.exe and C:\ST\STM32CubeCLT_1.22.0\STM32CubeProgrammer\bin? Does it still work?

That works equally well. It didn't occur to me that it referred to the STM32CubeIDE variants. That's what you get when blindly following AI 🫣.

It is now setup like this:

When I start the debug session, I get this output:

The error message pops up every time, also when using the STM32CubeIDE based configuration.

MarcV, thank you for the update!

Please try configuring the ST-LINK debug server with the same options you use in the Embedded GDB Server configuration:

1. Go to Settings | Build, Execution, Deployment | Debugger | Debug Profiles;
2. Select your ST-LINK debug server;
3. Open the Device Settings tab;
4. Enable the Connect under reset option;
5. Disable the Halt all cores option;
6. Enable the Verify flash download option.

Does debugging with the ST-LINK debug server work after these changes?

I've been experimenting a bit with the gdbserver on a command line prompt. It looks like there's a bug in the command line generated by CLion. Now it looks something like this:

C:\ST\STM32CubeCLT_1.22.0\STLink-gdb-server\bin\ST-LINK_gdbserver.exe -p 61234 -cp C:\ST\STM32CubeCLT_1.22.0\STM32CubeProgrammer\bin --apid 61234 -d --frequency 8000 --initialize-reset -s

The problem seems to be the --apid parameter. The value passed is 61234. This is supposed to be the cpu core the debugger should connect to. Changing that value to ‘1’ makes it work. Unfortunately I believe there's no way to change that in the device settings.

This does work:

C:\ST\STM32CubeCLT_1.22.0\STLink-gdb-server\bin\ST-LINK_gdbserver.exe -p 61234 -cp C:\ST\STM32CubeCLT_1.22.0\STM32CubeProgrammer\bin --apid 1 -d --frequency 8000 --initialize-reset -s
 

MarcV, I see that in the command that you shared in the original post

C:\ST\STM32CubeCLT_1.22.0\STLink-gdb-server\bin\ST-LINK_gdbserver.exe -p 61234 -cp C:\ST\STM32CubeCLT_1.22.0\STM32CubeProgrammer\bin --halt --apid 0 -d --frequency 8000

--apid was set to 0.

It seems that something changed in the debug server configuration.

Could you please check the Access port field in the Device Settings tab of your ST-LINK debug server? Is it set to 61234 by any chance?

That must have been the issue. “Access port” was set to ‘0’ in that case (the value 61234 came from another PC). I changed it to ‘1’ and now it works 🙂. Not sure how it became ‘0’ because I normally don't touch these parameters…

Anyway, I'm glad this is sorted out! Thanks for your support!

Not sure how it became ‘0’

MarcV, I think this is the default value for this field.

I'm glad to hear the issue is resolved!

It is indeed the default value, I just created a STM32H503 cmake project from scratch and the port is set to ‘0’. This value appears to be microcontroller dependent. I tried with a STM32G431 and there it only works with the port set to ‘0’.