Funky source code stepping in debug mode

[temp2010]

I know about optimizers and I've been debugging MCUs for many decades. But this behavior is just too weird and difficult to deal with...

I'm using Atollic TrueSTUDIO 9.3.0. When I debug my code and single step through the C source code, the highlighted green line (aka "green cursor") steps in all kinds of crazy order. Consider a block of assignment statements followed by a function call, and then another block and call. The green cursor jumps around in random order through the block of assignments, and then finally gets to the function call. Then I can step over or into/out of the function and go to the next block of assignment statements. However, it's not that clear cut. The green cursor will be on the function call, and I'll click the toolbar button to step into the function. Instead of stepping into the function, the green cursor jumps back to an earlier assignment statement. The some of the assignment statement appear to get executed multiple times, and the green cursor is on the function call multiple times, before the step into actually steps into the function.

All this makes it very difficult to debug things. I can't be sure of what's going on. The green cursor even goes through BOTH clauses of an if/else structure, LOL.

Is there a way to prevent this crazy behavior?

Thanks!

[Pavel A.]

So you wrote you know about optimizers, eh? Tried to disable the optimization (-O0) ? Or, try -Og option (optimize for debugging). TL;DR.

-- pa

[Tesla DeLorean]

To get linear code turn optimization off. The C-to-ASM relationship with optimization can be more scattered but there is only one pointer (not one to many dispersed)

The CM0(+) can be harder to single-step, lacking some debug hw in higher functioning cores.

The earlier CM7 also have issues, but F72x/F73x and H7 devices use a newer core. As I recall the F76x/F77x don't have the original core.

[temp2010]

Thanks, Pavel & Mr. Avogadro. Indeed, when I turn off optimization, the problem clears up. I thought it might be due to optimization, but I've NEVER before seen that extreme a mixup of sequencing, which is why I asked. Thinking further, there must be minor assembly code happening near the curly braces of C source code for if/else blocks, that cause the GUI to show the green cursor alternately in BOTH blocks. Were it an assy listing, it probably would not behave so apparently weird. Similar for function calls.

BTW, Mr. Avogadro, in confirming your suspected identity, I ran into something interesting. Wikipedia and Brittanica give you different values! I'm surprised to see that.

https://en.wikipedia.org/wiki/Avogadro_constant

https://www.britannica.com/science/Avogadros-number

[Tesla DeLorean]

I just copied and pasted from an interwebs source, Jan and I (Clive) were getting a bit annoyed at ST's use of User157.. as a default user name and our inability to easily differentiate one user from the next.

What STM32 part are you having issues with?

[temp2010]

STM32F105R8T6.

[waclawek.jan]

The Avogadro constant had been defined as number of atoms in 0.012 kilogram of carbon 12 (the most common, non-radioactive isotope). The trouble with this definition was, that nobody knew, how much that is, and experiments throughout the years resulted in different values (although the differences were for all practical purposes negligible).

Now this year was a major revamp of SI (the system of units used throughout the known world, except USA), and that included also a redefinition of the Avogadro number (more precisely, redefinition of the unit mol), which was simply established as a finite number, once for all https://en.wikipedia.org/wiki/Avogadro_constant#SI_redefinition_of_2019 (on that note above, like the fact that wikipedia gives lb/mol and oz/mol too).

Britannica uses probably one of the many past values.

I almost always single-step in disasm (more precisely, in the mixed C/disasm) - it's usually not that difficult to decipher what's going on, the optimizers are not *that* smart, they just attempt to mix code to benefit from estimated impact of pipelines, buffers, etc. - and usually it's faster to identify the problem when seing the raw values to fly around. I consider the practice of debug/production optimization to be a principally flawed aproach, I always debug what I produce. Some may see this as extreme.

JW