GDB Server fails to start

MHast.1 · ‎2021-08-06

Hello, I have a problem running any project in STM32CubeIDE v1.7.0

When I press 'Run' I usually get "Launching: Performing pre-launch check..." and it just hangs there.

Sometimes it gets past that, and then I get the following error

Error in final launch sequence: Failed to execute MI command: target remote localhost:61234

Error message from debugger back end: localhost:61234: The system tried to join a drive to a directory on a joined drive.

at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.processMIOutput(AbstractMIControl.java:1014) at org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.run(AbstractMIControl.java:843)

Console output:

STMicroelectronics ST-LINK GDB server. Version 5.9.1

Starting server with the following options:

Persistent Mode : Disabled

Logging Level : 1

Listen Port Number : 61234

Status Refresh Delay : 15s

Verbose Mode : Disabled

SWD Debug : Enabled

InitWhile : Enabled

Waiting for debugger connection...

PFirt.1 · ‎2022-03-22

I had the same issue with CubeIDE v1.7.0 and this also worked for me. Thnaks

PHolt.1 · ‎2022-03-22

This is just a common issue which happens randomly. With a bit of luck, not often. I find it happens more often when running Cube over RDP (remote desktop). Often the solution is to unplug/replug the USB cable into STLINK, close Cube, and terminate the ST process in Windows Task Manager, which is a hassle because you can't unplug the USB cable remotely : - )

Aksl · ‎2022-06-01

It seems to me that the solution in the video was to tweak the USB cable

JBern.7 · ‎2022-10-18

Well ... It is 2022 now, perhaps I am late. But just in case someone has the same question and tried removing/changing the USB as suggested in the previous comment, it did not work. So, my board only started to behave in such a manner after I turned on the FreeRTOS and changed the Serial wire to the Trace function. So cut long story short. I used STM32CubeProgrammer and cleared the full chip and upgraded the firmware, after this everything works perfectly.

iforce2d · ‎2022-10-19

Just find the gdb process that is using the port in question and kill it. Eg. in my case on Linux I do this:

killall ST-LINK_gdbserver

You can likely find the process by doing:

ps -aux | grep gdb

As to why this problem happens or how to prevent it in future, I have no clue.

Nik128 · ‎2024-05-29

This worked for me .
Thank you so much for the solution :)