Skip to main content
Mohan1
Mohan1
Associate III
January 14, 2020
Solved

How can I remove error like 'Waiting for debugger connection... Debugger connected Debugger connection lost. Shutting down...'

  • January 14, 2020
  • 14 replies
  • 11283 views

I am generating code using STM32CubeIDE, but when I start to debug I am getting errors like:

"STMicroelectronics ST-LINK GDB server. Version 5.2.3

Copyright (c) 2019, 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

Waiting for debugger connection...

Debugger connected

Debugger connection lost.

Shutting down..."

I am using the latest version of st-link USB driver(en.stsw link009). Also I am using USB to TTL converter. Initially everything was working very well, near about ten code executed successfully. But now facing the above error. So how can I solve it?

This topic has been closed for replies.
Best answer by mattias norlander

We have seen issues with a few number of devices that the user is forced to perform a mass erase before being able to flash a new bianry. This is obviously a bug and we try to fix it for the next version. If you do run into this problem with CubeIDE and ST-LINK GDB server then you can try to add the following to force a mass erase before programming the new binary:

In your debug configuration > Startup tab > Initialization commands > Add: monitor flash mass_erase

This will force CubeProgrammer_CLI version to peform a mass erase before programming new content. At least it automates the procedure you describe @GNels.2​ in your post above.

Other issues leading to debugger connection lost after the initial launch of your application typically includes:

  • Device goes into low-power mode without being configured to allow debug.
  • The application re-assigns the SWD related IO pins to some other function

14 replies

Ozone
Ozone
Principal
January 14, 2020

Does you application use sleep mode ?

Mohan1
Mohan1Author
Associate III
January 17, 2020

@Ozone​ thanks for your reply sir.My application not use sleep mode.

Ozone
Ozone
Principal
January 17, 2020

From the information provided, it looks like the target disconnects itself somewhere later in your application.

I don't use Cube. nor CubeIDE.

Have you tried to debug your application from the reset vector on ?

Mohan1
Mohan1Author
Associate III
January 17, 2020

@Ozone​ thanks for your reply sir,there is not any reset vector option for debug in IDE.

Ozone
Ozone
Principal
January 20, 2020

I don't know your IDE.

Perhaps there is a debugger setting "Run to main".

Disable that, and your debugger will supposedly stop at the reset vector.

ATrev
ATrev
Associate II
April 7, 2020

I've been tinkering with this problem for two days. I expose before the clumsy attempts I made and in the end my solution.

I recompiled my app and its elf: failed. I upgraded st-link and STM32CubeProgrammer: failed. I changed some settings of elf debugger section: failed. Once I succeded, but the day after, on the same app the problem persisted: not viable. The last app could be debugged and its elf could be used by the other not debuggable apps: just an experiment. For sure the upgrading of some tools has been

a good thing, but doesn't solve the issue.

Then, with some fears about loosing my NUCLEO F446RE, as personal mobility is at present reduced,

I applied STM32CubeIDE ST-LINK GDB server UM2576 3 Troubleshooting pag 8:

 If STM32CubeProgrammer can connect to the target, try to:

1. Erase the Flash with STM32CubeProgrammer.

That's it. Now I can re-program my old apps and their elf debug fine with GDB server.

BChaâ.1
BChaâ.1
Associate
May 18, 2020

hello did you found a solution ?

Gbasi.1
Gbasi.1
Associate III
June 3, 2020

i dont know about him, but i am having the same problem and i can not find a solution yet

OTosu.1
OTosu.1
Associate
December 1, 2020

same problem here, no solution jet??

GNels.2
GNels.2
Visitor II
December 3, 2020

I got the same problem with two brand-new NUCLEO-L476RG boards.

I think the root cause lies somewhere in the pre-flashed memory, because in trying the bulk erase process that ATRev attempted worked for me.

  1. Open CubeMXProgrammer
  2. Connect to the board via ST-LINK
  3. Click the eraser button in the lower left and click through the confirmation to bulk-erase the flash
  4. If these are brand-new boards, the rapidly blinking LD2 green led should extinguish.
  5. Disconnect from the board in CubeMXProgrammer
  6. Back in CubeIDE, go ahead and try to debug again.

0693W000006EZzzQAG.pngAs I said, this worked for me using the Cube toolchain (code generated in CubeMX, edit/compile/debug in CubeIDE).

Good luck!

LaurentL
LaurentL
ST Employee
December 4, 2020

Hi,

Yes, erasing flash is a good thing.

But the STLink gdb server should be able to erase the flash itself and reprogram the appli.

Try with CubeIde 1.5.0 and select "Connect under reset" mode (default reset mode) to be able to connect if appli uses SWD pins or low power modes and It should be able to erase the flash (STLink gdb server using CubeProgrammer cli).

Rgds,

Laurent

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
mattias norlander
mattias norlanderBest answer
ST Employee
December 4, 2020

We have seen issues with a few number of devices that the user is forced to perform a mass erase before being able to flash a new bianry. This is obviously a bug and we try to fix it for the next version. If you do run into this problem with CubeIDE and ST-LINK GDB server then you can try to add the following to force a mass erase before programming the new binary:

In your debug configuration > Startup tab > Initialization commands > Add: monitor flash mass_erase

This will force CubeProgrammer_CLI version to peform a mass erase before programming new content. At least it automates the procedure you describe @GNels.2​ in your post above.

Other issues leading to debugger connection lost after the initial launch of your application typically includes:

  • Device goes into low-power mode without being configured to allow debug.
  • The application re-assigns the SWD related IO pins to some other function
GNels.2
GNels.2
Visitor II
December 4, 2020

Thanks! That works well. We'll put it in our knowledgebase.

peterka
peterka
Associate II
January 8, 2021

I had the same problem. I changed the USB cable, now it works.

Show more replies
Terms & ConditionsAccessibility statement