2012-10-09 12:52 AM
Hi,
I'm experiencing a strange problem with IAR EWARM and STM32F4DISCOVERY. I have quite a deep nested 'if' function setup that is misbehaving. I have checked, double and triple checked the brackets and semicolons. I have also auto indented the function and it all matches up and looks fine. However when debugging the code, it seems to unexpectedly jump to lines (when stepping into [F11]), that it shouldnt. The problem seems to be irrelevant to the if statements, as it sometimesskips to a line without processing the proceeding line first
. This is hard to explain, see short example below g = 1; h = 2; if (g==1){ if (h==1){ i=1; j=2; k=3; }else if (h==2){ i=2; j=3; k=4; }else{ i=0; j=0; k=0; } }else{ i=8; j=9; k=10; } Obviously in this case the output should be i=2, j=3 and k=4. But when stepping through the code, the debugger will execute in the order given by the red numbers. In green is what should happen g = 1;1
h = 2;2
if (g==1){3
if (h==1){4
i=1; j=2; k=3; }else if (h==2){5
i=2;6
j=3;7
k=4;8
}else{ i=0; j=0; k=0; } }else{ i=8; j=9;6
k=10;7
} Yes that's right, it even skips i=8!! How can this be? At least the compiler seems to be consistent with where it skips. But how/why? Obviously my code is a lot bigger than this, but essentially this is whats happening. Could i be running out of memory/stack or something? I am using a lot of floats. I also have several timers running interrupts in the background, and this function itself is called via an interrupt. Help!? This is doing my head in... thanks!2012-10-09 03:46 AM
How about your toolchain settings, especially regarding optimization ?
Turn off all optimizations, and declare all variables as volatile - then you might see exactly what you expect.2012-10-09 04:55 AM
gargh ghsgbdjs bhdabhj.....
stupid bloody optimization. turning it off fixed the problem, thanks... but now my code is slowwww :( Is this a problem mainly with IAR? Thanks again, this was doing my head in2012-10-09 05:51 AM
Is this a problem mainly with IAR?
Not really. Most compiler show this ''behavior''. However, this is not actually a bug. You need to recall that C actually comes from the OS corner (say - Unix). The compiler itself has no idea of peripherals, it views everything adressable as ''memory''. And it judges all visible references to this memory to do it's optimizations. If, for instance, your condition in an if clause never changes (as in your example), it optimizes it out ruthlessly. You need to tell the compiler that some accesses are out of his scope, and he should refrain from any optimization.> Thanks again, this was doing my head in
You are not alone. I've seen RTOS'es fail once the optimization was set to > 0.
2012-10-09 09:05 AM
Optimizing is the bane of simple debugging.
Erik