Skip to main content
NRoos.1348
Associate II
March 3, 2021
Question

Debugger showing wrong variable values makes debugging nearly impossible

  • March 3, 2021
  • 4 replies
  • 5616 views

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

4 replies

Tesla DeLorean
Guru
March 3, 2021

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 VenmoUp vote any posts that you find helpful, it shows what's working..
Tesla DeLorean
Guru
March 3, 2021

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 VenmoUp vote any posts that you find helpful, it shows what's working..
Ozone
Principal
March 4, 2021

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

Especially with Eclipse-based IDEs.

NRoos.1348
Associate II
March 4, 2021

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

Ozone
Principal
March 4, 2021

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
March 19, 2021

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 II
May 6, 2024

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.

Tesla DeLorean
Guru
May 6, 2024

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 VenmoUp vote any posts that you find helpful, it shows what's working..
CBerg
Senior II
May 7, 2024

I agree, the software provided by ST has big potential for optimization. There are caveats and pitfalls everywhere. IMHO it's on the edge where it usable for professional projects.

I didn't try any optimization. I am in Debug mode.

This particular variable has no DMA buffers, but it is in cacheable Memory. Luckily, those variables are “debug variables” which only exist in debug mode and I can live without them. They only contain debugging info (e.g. counting successful transmissions and such stuff).

Eventually the reason is that I use one of those China-Clone ST-Links. And the reason why I am still using the cheap China-Clone ST-Links, even though I have various original ST-Links V2 and V3 (‘bout 10 lying arund), is that those Clone Devices have way better usability than the original ones IMHO. BTW: my recommendation to ST would be to make a clone of the China-Clone ST-Link but with the H7 MCU, if they want a good, usable product. The Cloners showed them how to create a product the customers like …

ATM I can live with this flaw – amongst all the other flaws, which remain unanswered here, like the issue with the CMSIS Packages, where the makefiles are not parsed correctly and lead to CMSIS installations with tons of unresolved includes, etc. CMSIS DSP above 5.7 is complete unusable for me, if I try to use it out of the box (via CubeMX).

Better tools: yes, I am constantly thinking about switching to the Keil IDE. But then I see there are no price tags with the “get a quote” label (e.g. at digikey – an official distributor), which means the software is obscene overpriced, and the “software as a service” feature, which is a complete show stopper for me. Besides that, I do not want to switch the toolchain in the middle of a project.

Therefore, ATM I have the choice between using a crappy IDE with a crappy debugger or get ripped of and squeezed down the “SAAS” path. For me SAAS is a serious business threat, I have experienced that two times, so my choice is to live with the crappy tools.

So my mood has changed over the time, beginning with my first experiences with the Atollic Studio and the Bluepill as “hey cool!! Free software, no SAAS sh*t” to “hmm, mah, yea, it’s no good choice, but unluckily the best choice”. And yes, the fact that serious issues reported by the community remain unanswered and unaddressed over years makes me think about evaluating the options I have for the next project. So Far TI has never disappointed me …

ST has a great advantage and this is the availability of their products. Namely if I want I prototype I just could order 5 PCBs from JLCPCB and I get them in 10 days. And their MCUs work good – as far as I am in the position to judge that – but the rest (my my case IDE and CMSIS support) is rather disappointing.

Sorry for the long text, which mostly does not even address the initial issue, but sometimes things need to be said.