Can anyone help me solve the "failed to start GDB server" error.

H.Ahmed · ‎2022-10-25

I'm trying to program STM32F103C8T6 using CUBEIDE. After solving so many errors now I have this error " failed to start GDB server" tried different PORT NUMBERS and also changed debug prob from " OPEN OCD" to "GDB SERVER" but could not help.

MM..1 · ‎2022-10-26

Explain how is connected your SWD , explain how is powered , and from your reply i have zero info if your design work with STM32CubeProg - STM32CubeProgrammer software for all STM32 - STMicroelectronics

PHolt.1 · ‎2022-10-26

Here you go...

STMicroelectronics ST-LINK GDB server. Version 7.0.0
Copyright (c) 2022, 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...
Debugger connected
Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.11.0                  
      -------------------------------------------------------------------
 
 
 
Log output file:   C:\Users\peter\AppData\Local\Temp\STM32CubeProgrammer_a11496.log
ST-Link Server is running on port : 7184
ST-LINK SN  : 003B000E5553500D20393256
ST-LINK FW  : V3J10M3B5S1
Board       : STLINK-V3SET
Voltage     : 3.27V
Error: ST-LINK error (DEV_TARGET_CMD_ERR)
2nd connect tentative with a lower frequency (8MHz)
ST-LINK SN  : 003B000E5553500D20393256
ST-LINK FW  : V3J10M3B5S1
Board       : STLINK-V3SET
Voltage     : 3.27V
Error: ST-LINK error (DEV_TCP_CMD_ERR)
Encountered Error when opening C:\ST\STM32CubeIDE_1.10.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.301.202207041506\tools\bin\STM32_Programmer_CLI.exe
Error in STM32CubeProgrammer
Shutting down...
Exit.

and, guess what, that .log file doesn't exist! I was working remotely so now I have another dead system and have to drive there to unplug the USB cable...

Actually this loss of the debugger happens much more often when working remotely (over Remote Desktop).

win7-64.

If I repeat (with F11) I get this

 
STMicroelectronics ST-LINK GDB server. Version 7.0.0
Copyright (c) 2022, 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
 
Target unknown error 33
 
Error in initializing ST-LINK device.
Reason: Unknown. Please check power and cabling to target.

Fortunately my system has a remote code load option over http which avoid using the debugger, but then of course I can't single step...

H.Ahmed · ‎2022-10-26

I have issued my devices from my University.

Can you please tell me how to check stm32 or ST-Link is either genuine or not.

MM..1 · ‎2022-10-26

Explain how is connected your SWD , explain how is powered , and from your reply i have zero info if your design work with STM32CubeProg - STM32CubeProgrammer software for all STM32 - STMicroelectronics

mattias norlander · ‎2022-10-27

The check has been done by the tool. The device is not genuine. ST has no obligations to support fake devices - end of story. Sorry about that, but I trust that you accept and respect this reasonable policy.

The unfortunate lessons learned is to obtain boards from real distributors.

Where to find a real distributor in your country?

Use this link, sort on:

By contact point = Distributors
By country = your country?!

Using e-bay/aliexpress/... is likely to lead to this issue.

Kind regards, Mattias

mattias norlander · ‎2022-10-27

This is a problem are where we would like to improve the situation!

But it is quite hard to narrow down the problem.

For example when dealing with customer PCBs and soldered on ST-LINKs long wires may impact debug stability... Such issue is outside ST control but will still "taint" the reputation of the debugger. Important for us is to understand which percentage of errors that truly are tools related. Which debug tool is the root-cause and how can we "robustify" the debug experience.

The more you are able to share, the better. I will reply below to your console output.

PHolt.1 · ‎2022-10-27

For example when dealing with customer PCBs and soldered on ST-LINKs long wires may impact debug stability... Such issue is outside ST control but will still "taint" the reputation of the debugger. Important for us is to understand which percentage of errors that truly are tools related. Which debug tool is the root-cause and how can we "robustify" the debug experience.

I have tried all kinds of things over past 2 years, on several development setups, some win7-64 and some win10, some stlink v2 isol and some stlink v3 and some stlink v3 isol. All of them fail sometimes. I have tried different debugger speeds, all the way down th silly stuff like 1MHz (stlink v3 should do 24MHz, v3 isol about 8MHz). And different ITM console speeds too. Nothing really makes much difference; the USB end needs unplugging to recover the debugger.

Also a frequent issue on some systems is the debugger losing contact with the target, so you lose any breakpoints you are waiting on. Have to rebuild/reload with F11.

Re target cables, I have done all kinds. This is the shortest I can do. I am using the Olimex 20way to 10 way adapter and a very short 10 way cable (out of the STLINK cable set) and you can see how close the CPU is.

If I plug that 10 way cable directly into the 10 way socket in the debugger, it works but much less reliably than using the 20 way socket on the debugger.

More posted here a while ago

https://www.eevblog.com/forum/microcontrollers/10-pin-debug-connector-and-stlink-v3-isol-not-reliable/msg3564782/#msg3564782

PHolt.1 · ‎2022-10-27

Can the "More answers" feature be disabled, please? It is horrible. Just show the whole thread.

". I will reply below to your console output."

I cannot see a reply anywhere.

mattias norlander · ‎2022-10-28

Hi @PHolt.1 ,

Sorry for lack of reply.

Had to seek some info internally to understand some error messages I am not familiar with:

Error: ST-LINK error (DEV_TARGET_CMD_ERR)
...
Error: ST-LINK error (DEV_TCP_CMD_ERR)

These error messages are propagated from ST-LINK firmware. Will see if we can get some experts on the ST-LINK into the loop. Why? Not sure. Normally, long wires, too fast SWD speeds. Could also be an ST-LINK firmware bug.

@PHolt.1 , looking at your screenshots it looks like you are running CubeIDE 1.10.0? Reason for asking is that we previously had a "race condition" inside CubeIDE on Windows only when terminating debug sessions. That bug could put the ST-LINK in a state where it did not accept new connections. It has was fixed in 1.9.0 if I remember well...

Will see if I can get the eyes of the ST-LINK expert on this thread. Please hold :)

PHolt.1 · ‎2022-10-28

Yes, Version: 1.10.1

Build: 12716_20220707_0928 (UTC)

This intermittent debugger loss (which, once it happens, is permanent until USB unplug, or PC reboot) has always been there.

This is not related to the SWD clock speeds.

I also find that if the SWV ITM data console is enabled, with

this can fairly rapidly make the debugger lose contact with the target. The target runs ok but of course no breakpoints anymore.

Earlier versions of Cube were more reliable in some other respects e.g. I sometimes find, after some hours, that breakpoints don't work until Cube is exited and restarted. I certainly cannot do debug builds all day without Cube getting into a mess.