Strange behavior of STM32CubeIDE debugger

[KKase.1]

When I start the debugger of my program (c++), a function gets called even before

the debugger halts at first default breakpoint (usually at HAL_Init).

The name of this function is getElapsed (returns double, no parameters) and its a

public member function of my custom class named Clock. The funny thing is that if

I rename the function (for example getElapsedEx) then it does not get called anymore.

Additional information:

- It exists a global object of Clock but there are no member calls in global scope.

- I think this strange call just happens when using the debugger.

- I identified the strange function call by placing a breakpoint at the beginning of the

function body before I start the debugger. 

- Microcontroller: STM32H743VIT

How is it possible that a function gets called even before the first default breakpoint?

And why does it change the behavior if I change the name of the function? Linker problem?

[TDK]

Unlikely to be a linker issue. More likely to be an IDE display bug or a software bug. What is the call stack when it hits that point and where does it go if you single step through?

[Markus GIRDLAND · Accepted solution]

Hello @KKase.1​ ,

When the debugger is out-of-sync with the expected execution behavior then the most common issue is that the user does not have the intended binary loaded in the target device.

It could be the case that the flash operation failed. Then GDB might have loaded the symbols from a new/modified elf file, while an old binary is still executing in flash.

To test this hypothesis do this:

• Turn on the flash verification by activating "Verify Flash Download" in the debug configuration
  • Launch the debug and have a look at the console output
• Perform a flash mass erase. In the debug configuration (startup tab) in the initialization commands field add:
  • monitor flash mass_erase

[KKase.1]

Thanks for your answers.

I renamed the function and kept on programming. Now when I rename it back, the problem does not occur anymore.

@TDK​ It was not an IDE display bug, because the function call caused a hard fault error because it was reading an uninitialized timer.

@Markus GIRDLAND​ But if I remember correctly, it always printed "Download verified successfully" when I ran the debugger.

But now when I think about the flash, I feel like sometimes the program does not get uploaded correctly. I uploaded the same program twice and it showed different behavior. Therefore when I implement something critical I always upload it multiple times, because I want to be sure it uploaded correctly (even though it shows "Download verified successfully" in the console).

I use the ST-Link programmer from the NUCLEO-F446RE to program my custom board. Might I have a problem with the programmer?

[Markus GIRDLAND]

If you want to be sure I would probably recommend the second bullet in my answer above, using the monitor flash mass_erase which shouldn't leave any possibility for old binary being left running on target.

[Pavel A.]

@Markus GIRDLAND​ Where are the commands like "monitor flash mass_erase" documented? How one can discover them?

[Markus GIRDLAND]

Hello @Pavel A.​ ,

The documentation from STM32CubeIDE's perspective is mentioned in the User Guide (UM2609) where the chapter covering the startup tab (chapter 3.2.4) mentions what commands can be used as:

"...any kind of GDB or GDB server monitor commands if there is any special need to send some commands to the GDB server before load commands are sent."

So that leads to the next part of your question, where to find them. We have a "Quick Reference Card" document and a "Debugger - Debugging with GDB" document that's packaged with the installer and available in the Information Center. However, as the User Guide document mentions, any GDB or GDB server monitor commands should work if you have another document in mind.

[Pavel A.]

Thank you

[S.Ma]

If your code starts to act differently between runs comes multiple bugs phase. Stack size, project copied to a new folder but editor keeps opened older source files, startup function and linker file incorrect. As soon as the debug misbehave find the root cause and remedy.