STM32 UART output occurs before code execution starts (Debug > Resume)

[durna]

Hi everyone,

I'm working on an STM32 project using STM32CubeIDE. I'm using the built-in debugger with ST-LINK and UART (via HTerm) to monitor communication between the STM32 and a host PC.

Here's something odd I noticed:

When I click the "Debug" button in STM32CubeIDE (but before I press "Resume"), I already see some UART output in HTerm, like:

AA 00 40 02 00 00 4D 55

AA 00 50 02 00 00 2A 55

Then, when I press "Resume", the same two messages are sent again. So in total I see them twice.

This seems strange because I wouldn't expect the UART to be transmitting anything before the code is running (i.e., before Resume is hit). But clearly, something is happening during the debugger halt or initialization phase.
Is this normal?

Is it common for STM32CubeIDE to somehow "pre-run" some initialization code before Resume?

Could it be something about HAL_UART_Transmit being called from main() before HAL_Init() fully returns?

Or maybe the ST-LINK somehow triggers this?

The program runs fine otherwise, but I want to understand the root cause — especially to avoid confusing behavior in downstream systems (like GUI apps reacting to these messages).

Thanks in advance!

[mbarg.1]

I guess you have to better understand MCU/CPU structure.

USART use a shift register clocke by internal clock.

Internal clock runs always (or pll would unlock).

Debug gates ( but not stop) clock to CPU; therefore any shift register like uart or ethernet or RTC clocked fron internal clock will work when debugger halts clock to CPU and few other peripherals.

This is not uniform in all MCUs; some use free running clocks on some perpherlas while use gated clocks.

Refer to manual of your device to see ( if it is described, some believe it is tp secret info) how your device is bult.

[Pavel A.]

There are no miracles. If you see this UART output, the MCU sends it. Maybe there's some "bootloader" that is executed when the MCU resets. The first reset can occur between powering up the MCU and connection of the debugger. Then the debugger can reset the MCU again. To be sure that no extra code remains on the MCU, do mass erase of the flash. Then debug again.

[TDK · Accepted solution]

When you hit "Debug", the device resets a few times and ends up running the first ~350 ms of the code before it resets again within the actual debugging session. This is the reason you see double--the code runs twice. Track the NRST pin on a scope if you want to see this explicitly.

Put a HAL_Delay(500) before program code if you're doing something that you don't want to happen. The UART printing double isn't a problem, obviously, but if you were doing something like modifying flash, it can be an issue.

[durna]

Thanks a lot