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

[Mohan1]

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?

[OTosu.1]

same problem here, no solution jet??

[GNels.2]

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.

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

Good luck!

[LaurentL]

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

[mattias norlander · Accepted solution]

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]

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

[peterka]

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

[paul19]

Got the same problem. @mattias norlander​'s solution didn't work for me, but @AT.1revisan​ 's one did.

Here is what I did exactly (source at https://www.st.com/resource/en/user_manual/dm00613038-stm32cubeide-stlink-gdb-server-stmicroelectronics.pdf, page 8):

1. Download and install STM32CubeProgrammer from https://www.st.com/en/development-tools/stm32cubeprog.html
2. Run STM32CubeProgrammer
3. Click "Connect" (top right green button)
4. Click the bottom left eraser icon

Done. After that STM32CubeIDE could run and debug my program correctly.

[MDe V.3]

I had the same problem.

I tried adding "monitor flash mass_erase" to the debug configuration, as suggested above, without solving the error.

But,

I opened a new project on CubeIDE, just an empty project.

I loaded it onto the MCU and it removed the error.

Going back to my original project the problem disappeared.

That's my 2 cents.

Mauro

[mt95]

I followed precisely these steps and it worked for me. Thank you for guiding through them, @paul19​! (the solution by @mattias norlander​  unfortunately also didn't work for me)

I can at last start with my brand new Nucleo board after a day of frustration and looking for solutions.

[ypiotrp]

I had the same issue with my STM32L071. The problem turned out to be with flash memory address in linker script. I accidentally changed it to 0x80000000, when it supposed to be 0x08000000. That's why the debugger couldn't flash the MCU with my program. Hope it helps someone.