Debugger showing wrong variable values makes debugging nearly impossible

[NRoos.1348]

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

[CBerg]

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.