Regression of ST-Link_gdbserver 1.10 compared to previous version ?

[Gpeti]

For a long time I have been using the following setup:

• two STM32H7 eval boards
• one gdbserver session for each STM32, with a different port
• remote debugging on the two STM32

I just switched from STM32CubeIDE 1.0 to 1.10.1 and now I have this weird behaviour:

 

It looks like the gdbserver now tries to connect to the two STM32 that are connected to the PC, even is I specified the STM32 serial number.

I have to connect to the second board on port 61236, since the 61235 seems busy.

Also my previous gdb command "monitor reset halt" seems to not be supported anymore.

[mattias norlander · Accepted solution]

Hi Gpeti,

Which version did you upgrade from?

I think that the screenshot you submit with the console output where the GDB-server uses two GDB-ports is not related to debugging two cores simultaneuously.

The reason that you see two ports being used by one GDB-server is because in later versions of ST-LINK GDB-server the "Live Expressions" is fed via its own TCP port. So if you disable "Live expressions" in the debug configuration you will probably only see one line of "Waiting for debugger connection..." and "Accepter connection on port xxxxx".

Do you have any debug related errors now? Or you just compared and observed this difference between versions?

Please note that we recommend using at least +4 ports between the two debug configurations to allow each configuration to launch all services which may require hidden ports.... :)

[Gpeti]

Thank you for your advices.

No debug errors anymore except that the connection between gdbserver and the target is sometimes shutting down unexpectedly (after like 4 or 5 debug sessions). Hard to reproduce / identify the root cause.