Debugger connection lost.

[Robert Poor]

Summary:

STM32CubeIDE 1.6.1 debugging works on a new, blank project but fails on the UART_Printf example.

Details:

I'm running STMCubeIDE Version: 1.6.1 Build: 9958_20210326_1446 (UTC) on macOS 11.1 (Big Sur), and connecting to a NUCLEO-G431RB dev board.

I created a new, blank project for the board (New => STM32 Project => Board Selector => NUCLEO-G431RB), compiled it and started the debugger. It started without error and I could single step through the instructions. Here's what was printed on the console:

STMicroelectronics ST-LINK GDB server. Version 5.8.0
Copyright (c) 2020, 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
      -------------------------------------------------------------------
                        STM32CubeProgrammer v2.7.0-RC1                  
      -------------------------------------------------------------------
... (continued without error)...

I then created a new example project for the board (New => STM32 Project => Example Selector => UART_Printf), selecting the version for the NUCLEO-G431RB, compiled it and started the debugger. The debugger immediately shut down. Here is what was printed on the console:

STMicroelectronics ST-LINK GDB server. Version 5.8.0
Copyright (c) 2020, 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
Debugger connection lost.
Shutting down...

Just to make sure it wasn't a sequencing issue, I re-opened the blank project I previously created and launched the debugger. It worked without trouble.

Question:

So there appears to be something in the UART_Printf example that's causing the debugger to fail. What should I check for to diagnose this?

[Pavel A.]

If you open directly the CubeIDE project (not via example selector), will it work?

https://github.com/STMicroelectronics/STM32CubeG4/tree/master/Projects/NUCLEO-G431RB/Examples/UART/UART_Printf/STM32CubeIDE

[ONadr.1]

I have this problem alvays when I forgot alow MCU debug port in configuration (in CubeMX)

[mattias norlander]

@ONadr.1​, you have this problem with STM32CubeIDE or another IDE/debugger? It should not be necessary since CubeIDE forces the required GPIO pins to be used in SWD mode when connecting to target. So this is a bit surprising to me. Any specific board this happens with?

@Robert Poor​, I do not have access to this board (home office era), so cannot test run this particular example. Reading your console output it seems as if the connection to the ST-LINK crashes before CubeProg is allowed to download the example project binary. I think this rules out that there could be a problem with the elf-file of the UART_Printf example. Could you tell me which version of the CubeFW you are relying on? There are not .launch-files bundled with the example projects --> means that your CubeIDE environment was responsible to generate the debug configuration. I am wondering if it in some way could be corrupt? Things you can try:

• If you inside the debug configuration enabled "Log to file" checkbox, then the ST-LINK GDB-server will become a bit more verbose. Maybe we can learn something from this additional logging level...
• You can also try to delete the debug configuration and re-create another one to see if this metadata is corrupted
• You can try to create another debug configuration selecting Probe = OpenOCD instead of ST-LINK GDB-server. Let's look at this as a work-around. Not fixing the root-problem, but at least "uncblocking" you from progress in your project...

[Robert Poor]

For better or worse, deleting and regenerating the project fixed the problem. As a result, I've not been able to replicate the problem, so we may never know what happened.

But thank you for your answers and suggestions!

[JJako.1]

Hello,

Just reviving this thread due to experiencing the same problems and by now having tried all the "fixes" that I've been able to find. 

STMicroelectronics ST-LINK GDB server. Version 5.8.0

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

Debugger connection lost.

Shutting down...

I'm evaluating the STM32L4 (brand new nucleo-l476rg board) for a new design and thus far I have not been able to even get started... 

Has there been any development regarding this issue?

Edit:

Enabling verbose mode doesn't provide me more information:

ST-LINK device status: HALT_MODE

ST-LINK detects target voltage = 3.27 V

ST-LINK device status: HALT_MODE

ST-LINK device initialization OK

Waiting for debugger connection...

Waiting for connection on port 61234...

Accepted connection on port 61234...

Debugger connected

Debugger connection lost.

Shutting down...