cancel
Showing results for 
Search instead for 
Did you mean: 

Debugger showing wrong variable values makes debugging nearly impossible

NRoos.1348
Associate II

Hello,

I'm a bit surprised i don't find a previous discussion about this topic, as i am not the only one experiencing it in our company:

  • STM32F765 (Cortex M7) based board, own design
  • connected with ST-Link
  • happens both with OpenOCD and gdb debugger configuration
  • C++

When stepping through the code, variable values are changing to other values randomly, with the result that tracing errors becomes nearly impossible. I tried some workarounds like copying the interesting values to other variables in different scopes, or disabling optimization for the relevant functions (unfortunately i cannot disable optimization globally, as it does not fit in any more), or declaring variables as volatile, but with only little success. Here is an example (displayed variable values in the comments):

Buffer *buf1;

volatile Buffer *buf2;

Object *obj1;

volatile Object *obj2;

void __attribute__((optimize("O0"))) Object::receive(Buffer *packet) {

// this = 0x2005ddd4 (seems this is the correct pointer)

// packet = 0x20035d90

A *a = new A;

// this = 00x200193d4

buf1 = packet;

// buf1 = 0

buf2 = packet;

// buf2 = 0

obj1 = this;

// obj1 = 0

obj2 = this;

// obj2 = 0

Object *obj3 = this;

// obj3 = 0x2005ddd4 (original this)

a->foo();

// obj3 = 0x200193d4

...

}

Are there more people having this problem? Is this a bug, or a result from the compiler reusing the registers and the debugger doesn't notice it?

Is there a way to get rid of this problem (which would be the best), or at least are there techniques how to deal with it and still be able to debug more or less comfortable?

Kind regards

10 REPLIES 10

Not sure the compiler generates that fine grain of detail to the debugger.

Instrument the code so it outputs variables/states of interest, and provides code flow information, so you don't have to step your own code to understand what it does.

Use the SWV or USART, or spill to a buffer you can "Memory View"

The F756 has the same CM7 core as F746, there are known debugging issues with that which were fixed on subsequent cores used in the F767/F777 and F722/F723 ones.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Seem to vaguely recall Segger doing some "fixes" to work around the core issues, you could always flash the ST-LINK with the Segger OB firmware and use that.

The alternative, if that's the issue, would be to use an F777 as a proxy / debug-mule

https://community.st.com/s/question/0D50X0000A4pIcQSQU/stm32f746-cortexm7-silicon-bug-singlestep-lands-in-interrupt-handler

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Hi, thanks for the answer.

Sure i can debug by outputting variables and by narrowing down locations with bugs, but this effectively means i don't use the debugger any more, and putting in trace outputs, recompile, download etc. is much more uncomfortable than simply stepping through the code and look at variables.

And i don't have the problem that was meant in the issue, stepping through is working fine, it's just that the displayed variable content is changing (while the real "on-chip" variables indeed keep their correct values).

If i remember correctly, the same happens with a different controller (a L452). 

Ozone
Lead II

I occasionally had similar issues with cross toolchains when the source code and application did not match.

Especially with Eclipse-based IDEs.

Hm, i am really sursprised this happened only occasionally und certain circumstances. It's not only me who has this problem, it is two more co-workers (this means all) in our company.

Compile - download - start - debug - and this problem comes up, all the time. No out-of-sync of source code and running binary.

Are we all doing something wrong in our company? Strange...

You are talking about CubeIDE ?

It might be a toolchain-related issue.

I recently had some similar issues, with a LPCXpresso board and the MCUXpressoIDE (which is similar to CubeIDE).

As it turned out this was a known bug in the linker, messing up the debug info for unused functions.

I disabled just some of the unused function (#if 0), and the problem was gone.

NRoos.1348
Associate II

Short update on this issue:

We tried a J-Link instead of the ST-Link, and it is going much better with it. So we stay with it.

And i forgot to mention, we are using Cube IDE.

CBerg
Senior

I can confirm ths Bug.

I use CubeIDE 1.14.0, and I am debugging Code on a STM32H723.

I have a struct that I can read out via UART. The Debugger shows wrong values, for this variable during debugging. But if I read out the same variable with UART, the values are correct.

3-Years later and same issue in compiler / linker / debugger. The QA situation here is dire..

Any better with optimization and code rearrangement off?

DMA buffers? Caching?

Use better tools?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..