cancel
Showing results for 
Search instead for 
Did you mean: 

GDB Server fails to start

MHast.1
Associate II

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

Copyright (c) 2021, STMicroelectronics. All rights reserved.

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...

15 REPLIES 15
MHast.1
Associate II

It happens on any project on this machine, regardless of configuration (release, debug). I have another machine with v1.7.0 installed and I can run all the same projects without issues.

I have no problem using STM32Programmer and connecting to ST-Link.

Using Windows 10, P-NUCLEO-WB55 board.

MHast.1
Associate II

Problem doesn't happen with STM32CubeIDE v1.6.1 (ST-LINK GDB server v5.8.0). So it's an issue from the latest release.

mattias norlander
ST Employee

Some follow-up questions...

Q1: What happens if you switch to a new workspace with a new project? Same problem then?

Q1a: If not, what happens if you import your old projects into a new workspace?

Q2: But if you just click build the project builds successfully?

Q3: What happens if you go into the debug configuration and click "disable auto build"?

Q4: Do you have any anti-virus firewall running that may be blocking any debug relates service from running? Maybe worth to try to quickly disable or examine related logs...

MHast.1
Associate II

Hello, thanks for your response

Q1 - Yes, same problem. I've tried new workspaces, removing and reinstalling everything, different launch configs.

Q2 - Yes, no issues with builds, the problem is running it

Q3 - Same issue

Q4 - I checked Windows firewall settings, both stm32cubeide and st-link_gdbserver were allowed access

The main thing is that it happens with IDE v1.7.0 and not v1.6.1. I'm using Windows 10, nothing special with the setup, I use some drive letters mapped with SUBST.

Bgrth.1
Associate

Yes its the same issue that I am facing in my GDB server its not starting like an ideal server you can see here this guys is mentioning the same issue that I am facing in my server please help us to solve this issue.

JFeut.1
Associate II

I have done a video to fix the issue : Failure starting GDB server - YouTube

the video is in french, but simply just change the TCP port 61234 to anything else and it has solved my problem

Well the GDB-server seem to start just fine. It is waiting for the GDB-client to connect to it. So this part seem to work well.

But it seems like the GDB-client is not permitted to *** through on the port.

Q5: Maybe you can do as @JFeut.1​ proposed below and change the port to see if that is for some reason blocked?

Q6: Since things work in CubeIDE 1.6 but not in 1.7, then we need to understand if the is the GDB-server or the GDB-client in 1.7 which is the root-cause. Maybe you can try this by mixing the tools like this:

  • Launch the GDB-server from 1.7 externally via command-line terminal. Hint: You can copy the full launch parameters from the debug config by clicking "show command line". Now launch CubeIDE 1.6 and setup a debug config which remote connects to the externally launched GDB-server from the 1.7 package.
    • If it fails, there is some issue with the 1.7 GDB-server on your system.
  • Next. Try the opposite. Launch GDB-server from 1.6 and launch remote debug from CubeIDE 1.7.
    • If it fails then there is some issue with CubeIDE or the GDB-client on your system.

Alternatively you could try in the CubeIDE 1.7 to launch a debug session relying on OpenOCD instead of ST-LINK GDB-server. That could also hint about whether client or server is the issue?!

I think this issue is quite specific to your (and maybe a few other's) environments. My best bet is still AV/firewall configurations. Let's see what your tests indicates..

Slove.1
Associate

One other (maybe obscure) reason that leads to very similar symptoms (namely the hanging of the start of the debugging process) is that STM32cubeIDE does not use an absolute path of stlink-server. I have an alias in my PATH named stlink-server that points to st-util of https://github.com/texane/stlink.

Once querying PATH leads to the stlink-server binary installed with the IDE everything works fine. Maybe something similar happens with multiple versions of the IDE installed too.

Hard to help since we cannot re-produce the issue. We have to rely on you guys trying our suggestions and provide feedback on if any of the suggestions work or not.

So, please go through the suggestion questions/suggestions above, try them and provide answers to if any of them seem to help...