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