Using ICD debugger to locate variables in RAM

[julienm]

Hello,
I'm having a weird issue with a int8 flipping from 0 to 1 without good reason (the code doing that should not be called)
I was wondering if it is cause by an out of bound issue on another variable
In order to do so I was wondering if the debugger can show me the RAM adress of a variable. I have not managed to do so.
I was able to find my int8 in RAM by flipping it and monitoring the RAM but I can't do that for all variable.

Thanks in advance

[julienm]

Ok, sometimes asking the question helps you find the answer.
So the solution is to look at the .sym file for location of all variables. (did I say I was a newbie?)

Bonus question: how does the debugger work with the ICD? Is it really running the same code than without the debugger attached?
I'm cycling my device with a breakpoint set in the infamous function that should never be called.
But I have doubts that the issue will occur when in debug mode

[Ttelmah]

ICD is quite complex.
What happens, is a little extra code is added to the processor. This is the
'debugger kernel'. This kernel intercepts some key parts of the processor's
execution, so you jump 'back' to it when you reach a breakpoint, and it
can execute a single instruction in memory. With this, you are running
your 'real' program, but with some restrictions (watchdog can't work for
example, and timings obviously don't apply in single step mode). Generally,
the code should behave exactly the same, so if you just add a breakpoint
at the start of the piece of code that should not be reached and it arrives
here, you can then see the contents of variables, and where it was called
'from'.
On variable placement, if you are having a problem with a variable being
changed, the key thing normally is to look at what is just 'in front' of this
in memory. So a sym with your problem variable at say address 104, look
at what is at 102 and 103. If something here is perhaps a string, or
is another variable that is accessed using a pointer, then you need to see
if there is any way this could be either counting beyond where it should,
or if it could be writing an incorrect sized value (so writing an int16 or
int32 to a space only allocated to hold an int8 for example).

[julienm]