Atmel Studio 6: local variable not shown at Locals Window

I fixed the problem by myself. It is due to optimization. Set the Optimization level to None will fix the problem.

--- Posted via news://freenews.netfront.net/ - Complaints to snipped-for-privacy@netfront.net

Or fix your code. The compiler is optimizing it away because it's unnecessary or unused. Why are you watching the unnecessary variable? Just do something with the variable.

or unused. Why are you watching the unnecessary variable? Just do something with the variable.

Or it was optimized into a register so there is no local storage value to display. Even if it is still in a register when the display attempt is dine the debugger may not be aware of that fact. At times I have had to go through the generated code, figure out which reg the variable was optimized into, and then do a register display to find the value.

The variable may be "unnecessary" insofar as the compiler can generate equivalent code which doesn't directly involve the variable, but that doesn't mean that there's anything wrong with the original code.

E.g. given the code:

for (int i = 0; a[i]; i++) a[i]++;

the compiler could generate equivalent code:

for (int* p = a; *p; p++) (*p)++;

In which case, attempting to view the value of "i" will fail, as it has been optimised away.

op

on

or:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Type

=A0 =A0Error

Normally if you mark the variable as 'volatile' it will not be optimized away.

Note that optimised variables don't necessarily "live" in a particular register - they may migrate between registers. Modern versions of gdb can track such movement and continue "watching" such data, AFAIK, but not simpler debuggers like AVR Studio. And for "manual" tracking like you mentioned, you have to be aware of these possibilities.

No, you didn't fix the problem - you just hid it by making a bigger problem. Don't cripple your compiler by disabling optimisation, and don't do your debugging using different compiler settings from your "real" release code.

The easiest way to watch a particular variable like this is, as another poster suggested, by marking it "volatile". It will affect code generation and optimisation, to make the data visible, but the changes will be minimal.

What I sometimes do is have a global volatile variable and assign to it the variable I wish to inspect. Normally only in early debug phase, when issue is reolved the assignment is removed. Sort of like a debug printf :)

Well yes, you have to figure out that the variable is actually in a reg and which one when you want to view it. If you stop somewhere the variable is not being used it may not be in a register.

As another poster pointed out the variable may not even exist after optimization. There may be problems that only show up at higher optimization levels and disappear at lower optimization levels. This is always fun (in the sense of root canal work without Novocaine) trying to figure out if it is your problem (usually) or a compiler problem.