CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Using ICD debugger to locate variables in RAM

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
julienm



Joined: 28 Jul 2020
Posts: 31

View user's profile Send private message

Using ICD debugger to locate variables in RAM
PostPosted: Tue May 17, 2022 4:14 pm     Reply with quote

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


Last edited by julienm on Wed May 18, 2022 3:08 pm; edited 1 time in total
julienm



Joined: 28 Jul 2020
Posts: 31

View user's profile Send private message

PostPosted: Tue May 17, 2022 4:39 pm     Reply with quote

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


Last edited by julienm on Wed May 18, 2022 11:58 am; edited 1 time in total
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed May 18, 2022 5:51 am     Reply with quote

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



Joined: 28 Jul 2020
Posts: 31

View user's profile Send private message

PostPosted: Wed May 18, 2022 12:13 pm     Reply with quote

Ttelmah wrote:
ICD is quite complex.
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).

Thanks for your reply.
I was not able to reproduce the issue in debug mode unfortunately.
I highly suspect variable corruption, and in the mean time I found this thread: https://www.ccsinfo.com/forum/viewtopic.php?t=58501
My corrupted variable is indeed an int8 and I'm compiling with revision 5.080 for a 18F6722
I also have other int8 near the corrupted one, which are updated inside an interruption.

I have recently removed unused global variable, 3 of them were a the beginning so my corrupted variable was shifted 3 slots upper in RAM.

Should I buy the compiler update that fix int8 corruption in order to solve that issue?
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group