EmbeddedRelated.com
Forums
Memfault Beyond the Launch

Mysterious value change

Started by merapcb April 24, 2011
This is generic in nature, kindly humor me.
I have a problem where there is a variable (a U8) that is initialized from the EEPROM to something (in this case 0x05). In the entire code it is never written to, only used as an input to some other function.
I noticed a change in behavior and on debugging saw that suddenly this variable has the value of zero (0x00). Since (as I mentioned) there is nowhere in the code where the variable is written to (other than the first time initialization when it is read from EEPROM), I have no clue as to why it would change it's value. The only thing I can think of is that somehow some other part of the code wrote in the RAM space allocated to it. But how can that be? Since I have never debugged a situation like this, my questions are:
a) Is this a/the plausible explanation
b) If so, how to go about finding the culprit who is overwriting it

Beginning Microcontrollers with the MSP430

OK so although I have to wait hours for the condition to occur (while system running under debug), it does happen. The value gets set to 0x00 which causes a problem. I found this out with a Conditional Breakpoint. Now, is there a way of finding out who changed that specific memory location? (assuming that since there is no line of code every assigning any value to that variable, it is that type of an error).

--- In m..., "merapcb" wrote:
> Sorry my bad, I noticed that through there is no feedback when you select that option, a breakpoint is defined. Now I have the following questions:
>
> 1. How do I set it up to alert me if it is a value either equal to something or anything but something?
>
> 2. Since I am looking for a value, should I set it to "Data" (MDB)?
>
> 2. How can I know what variable uses a particular memory (RAM) location? (i.e. the byte just before the problematic one, to see if it is "overlapping" it)
>
> 3. Do I have to do something to enable the "Enhanced Emulation Module" which seems to be needed?
>
> Thanks, there are all new aspects of debugging/IAR for me
> --- In m..., "merapcb" wrote:
> >
> >
> > Yes OYC, I was looking in to this, but when I right-click on the memory location and select "Set Range Breakpoint" nothing happens. I tried both with code running on target and also paused. How to get this option working?
> >
> > --- In m..., "old_cow_yellow" wrote:
> > >
> > > I think what Harri meant was to set up either a "Range Break-point" or a "Advanced Break-point" at the address of your "volatile" variable (; the variable that changes value by itself ;)
> > >
> > > For example, if that variable is at 0x1234, you can set a Break-point:
> > > Range @0x1234-0x1234 [MAB-W]
> > >
> > > When something tries to access the MAB (Memory Address Bus) with -W (Write cycle), that Break-point will trigger and the Debugger will show you who is trying to do it.
>

I am posting the summary of this issue for the benefit of others (as well as a thanks to those who helped). The cause was a chain reaction, set off by a corrupted input frame from a serial peripheral which occurred extremely rarely but not handled (i.e. expected always to be perfectly formed and not checked for exceptions, very bad). This caused a buffer overrun, which copied on to the memory space of some variables, which caused the issues. The big learning point, for me, was how to set a Conditional Breakpoint in IAR to break at that memory location on a specific value.

Thank you all
--- In m..., "merapcb" wrote:
> OK so although I have to wait hours for the condition to occur (while system running under debug), it does happen. The value gets set to 0x00 which causes a problem. I found this out with a Conditional Breakpoint. Now, is there a way of finding out who changed that specific memory location? (assuming that since there is no line of code every assigning any value to that variable, it is that type of an error).
>
> --- In m..., "merapcb" wrote:
> >
> >
> > Sorry my bad, I noticed that through there is no feedback when you select that option, a breakpoint is defined. Now I have the following questions:
> >
> > 1. How do I set it up to alert me if it is a value either equal to something or anything but something?
> >
> > 2. Since I am looking for a value, should I set it to "Data" (MDB)?
> >
> > 2. How can I know what variable uses a particular memory (RAM) location? (i.e. the byte just before the problematic one, to see if it is "overlapping" it)
> >
> > 3. Do I have to do something to enable the "Enhanced Emulation Module" which seems to be needed?
> >
> > Thanks, there are all new aspects of debugging/IAR for me
> >
> >
> > --- In m..., "merapcb" wrote:
> > >
> > >
> > > Yes OYC, I was looking in to this, but when I right-click on the memory location and select "Set Range Breakpoint" nothing happens. I tried both with code running on target and also paused. How to get this option working?
> > >
> > > --- In m..., "old_cow_yellow" wrote:
> > > >
> > > > I think what Harri meant was to set up either a "Range Break-point" or a "Advanced Break-point" at the address of your "volatile" variable (; the variable that changes value by itself ;)
> > > >
> > > > For example, if that variable is at 0x1234, you can set a Break-point:
> > > > Range @0x1234-0x1234 [MAB-W]
> > > >
> > > > When something tries to access the MAB (Memory Address Bus) with -W (Write cycle), that Break-point will trigger and the Debugger will show you who is trying to do it.
> > >
>

Augusto, all true.
Not that it matters, but it was not me that wrote the code in question... ;-)
--- In m..., Augusto Einsfeldt wrote:
>
>
> I would say the big learning point was to realize that any software
> must be done thinking on everything.
> One could never trust the outside world will behave more perfect
> than its own software.
> Learning how to use a feature in the tool is like learning to drive
> automatic or mechanic gear car. You just learned how to drive most
> cars, not how to win a F1 race.
> This is know how.
> -Augusto

So, you have now to become a teacher ;-)
.
On Ter 26/04/11 14:19 , "merapcb" m...@yahoo.co.in sent:
Augusto, all true.
Not that it matters, but it was not me that wrote the code in
question... ;-)
--- In m..., Augusto Einsfeldt wrote:
>
>
> I would say the big learning point was to realize that any
software
> must be done thinking on everything.
> One could never trust the outside world will behave more perfect
> than its own software.
> Learning how to use a feature in the tool is like learning to
drive
> automatic or mechanic gear car. You just learned how to drive most
> cars, not how to win a F1 race.
> This is know how.
> -Augusto



I would say the big learning point was to realize that any software
must be done thinking on everything.
One could never trust the outside world will behave more perfect
than its own software.
Learning how to use a feature in the tool is like learning to drive
automatic or mechanic gear car. You just learned how to drive most
cars, not how to win a F1 race.
This is know how.
-Augusto
On Ter 26/04/11 13:16 , "merapcb" m...@yahoo.co.in sent:
I am posting the summary of this issue for the benefit of others (as
well as a thanks to those who helped). The cause was a chain reaction,
set off by a corrupted input frame from a serial peripheral which
occurred extremely rarely but not handled (i.e. expected always to be
perfectly formed and not checked for exceptions, very bad). This
caused a buffer overrun, which copied on to the memory space of some
variables, which caused the issues. The big learning point, for me,
was how to set a Conditional Breakpoint in IAR to break at that memory
location on a specific value.
Thank you all
--- In m..., "merapcb" wrote:
>
>
> OK so although I have to wait hours for the condition to occur
(while system running under debug), it does happen. The value gets set
to 0x00 which causes a problem. I found this out with a Conditional
Breakpoint. Now, is there a way of finding out who changed that
specific memory location? (assuming that since there is no line of
code every assigning any value to that variable, it is that type of an
error).
>
>
>
> --- In m..., "merapcb" wrote:
> >
> >
> > Sorry my bad, I noticed that through there is no feedback when
you select that option, a breakpoint is defined. Now I have the
following questions:
> >
> > 1. How do I set it up to alert me if it is a value either equal
to something or anything but something?
> >
> > 2. Since I am looking for a value, should I set it to "Data"
(MDB)?
> >
> > 2. How can I know what variable uses a particular memory (RAM)
location? (i.e. the byte just before the problematic one, to see if it
is "overlapping" it)
> >
> > 3. Do I have to do something to enable the "Enhanced Emulation
Module" which seems to be needed?
> >
> > Thanks, there are all new aspects of debugging/IAR for me
> >
> >
> > --- In m..., "merapcb" wrote:
> > >
> > >
> > > Yes OYC, I was looking in to this, but when I right-click on
the memory location and select "Set Range Breakpoint" nothing happens.
I tried both with code running on target and also paused. How to get
this option working?
> > >
> > > --- In m..., "old_cow_yellow"

wrote:
> > > >
> > > > I think what Harri meant was to set up either a "Range
Break-point" or a "Advanced Break-point" at the address of your
"volatile" variable (; the variable that changes value by itself ;)
> > > >
> > > > For example, if that variable is at 0x1234, you can set a
Break-point:
> > > > Range @0x1234-0x1234 [MAB-W]
> > > >
> > > > When something tries to access the MAB (Memory Address Bus)
with -W (Write cycle), that Break-point will trigger and the Debugger
will show you who is trying to do it.
> > >
> >
>



Hardly... Just a bozo trying to cope with the aftermath of an engineer jumping ship in mid course....
--- In m..., Augusto Einsfeldt wrote:
>
>
> So, you have now to become a teacher ;-)
> .


Memfault Beyond the Launch