Hi everyone,

I'm working on a sensor project which uses
TelosB<http://www.memsic.com/products/wireless-sensor-networks/wireless-modules.html>based
on msp430f1611 running
TinyOS <http://tinyos.net>. My program is reset some time after boot
up. After the PUC reset, IFG1 is found with WDTIFG bit set, indicating the
watchdog timer initiates the reset. This can happen under two cases:
1) Watchdog timer expiration when in watchdog mode only.
But watchdog timer is never started, so this cannot happen.
2) Watchdog timer security key violation.
There is no place that my program explicitly writes WDTCTL (i.e., 0x0120h).
So there must be some memory access bug in my code, which illegally writes
WDTCTL and causes security key violation.
Is there any debug tool to help locate where this happens? Or any any
suggestion on how I should proceed to locate the bug? My program is of
thousands of lines, so manual check is non-trivial.

Please weigh in if you have any suggestion. Thank you very much in advance.

More detailed information of the bug can be found
here<http://www.mail-archive.com/t...@millennium.berkeley.edu/msg42390.html>
.

-Xiaohui Liu






(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

you may not have enabled the watchdog, but most versions of the startup code enable the watchdog timer by default.. even if the first line of your code disabled it, it might not even get to your code before reseting.. this can happen if you have alot of variables that have to be cleared and initialized or data to be copied..
 
In this case you need to modify the startup code (cstart.asm) to not enable the wd timer and recompile..

>________________________________
>From: Xiaohui Liu
>To: msp430
>Sent: Sunday, October 28, 2012 8:10 PM
>Subject: [msp430] how to debug reset caused by WDTCTL security key violation
>
> 
>Hi everyone,
>
>I'm working on a sensor project which uses
>TelosB<http://www.memsic.com/products/wireless-sensor-networks/wireless-modules.html>based
>on msp430f1611 running
>TinyOS <http://tinyos.net/>. My program is reset some time after boot
>up. After the PUC reset, IFG1 is found with WDTIFG bit set, indicating the
>watchdog timer initiates the reset. This can happen under two cases:
>1) Watchdog timer expiration when in watchdog mode only.
>But watchdog timer is never started, so this cannot happen.
>2) Watchdog timer security key violation.
>There is no place that my program explicitly writes WDTCTL (i.e., 0x0120h).
>So there must be some memory access bug in my code, which illegally writes
>WDTCTL and causes security key violation.
>Is there any debug tool to help locate where this happens? Or any any
>suggestion on how I should proceed to locate the bug? My program is of
>thousands of lines, so manual check is non-trivial.
>
>Please weigh in if you have any suggestion. Thank you very much in advance.
>
>More detailed information of the bug can be found
>here<http://www.mail-archive.com/t...@millennium.berkeley.edu/msg42390.html>
>.
>
>-Xiaohui Liu
>
>
>







(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

wRITE AN isr HANDLER FOR THE wdt INTERRUPT, TRAP IT HERE BEFORE THE puc
CAN OCCUR then examine your stack to see where the code was executing
prior to the violation. Then take it from there.

You cannot do this after the PUC as the C start up sequences usually
screw with the evidence.

Al

On 29/10/2012 10:40 AM, Xiaohui Liu wrote:
> Hi everyone,
>
> I'm working on a sensor project which uses
> TelosB<http://www.memsic.com/products/wireless-sensor-networks/wireless-modules.html>based
> on msp430f1611 running
> TinyOS <http://tinyos.net>. My program is reset some time after boot
> up. After the PUC reset, IFG1 is found with WDTIFG bit set, indicating the
> watchdog timer initiates the reset. This can happen under two cases:
> 1) Watchdog timer expiration when in watchdog mode only.
> But watchdog timer is never started, so this cannot happen.
> 2) Watchdog timer security key violation.
> There is no place that my program explicitly writes WDTCTL (i.e., 0x0120h).
> So there must be some memory access bug in my code, which illegally writes
> WDTCTL and causes security key violation.
> Is there any debug tool to help locate where this happens? Or any any
> suggestion on how I should proceed to locate the bug? My program is of
> thousands of lines, so manual check is non-trivial.
>
> Please weigh in if you have any suggestion. Thank you very much in advance.
>
> More detailed information of the bug can be found
> here<http://www.mail-archive.com/t...@millennium.berkeley.edu/msg42390.html>
> .
>
> -Xiaohui Liu
>
>
>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi,

The watchdog is enabled during initialization.

Any suggestion on how to locate this bug? I've been wrestling with this bug for the past few weeks and still not found it. I'd really appreciate if you can help.

--- In m..., Joe Radomski wrote:
>
> you may not have enabled the watchdog, but most versions of the startup code enable the watchdog timer by default.. even if the first line of your code disabled it, it might not even get to your code before reseting.. this can happen if you have alot of variables that have to be cleared and initialized or data to be copied..
>  
> In this case you need to modify the startup code (cstart.asm) to not enable the wd timer and recompile..
>
>
>
> >________________________________
> >From: Xiaohui Liu
> >To: msp430
> >Sent: Sunday, October 28, 2012 8:10 PM
> >Subject: [msp430] how to debug reset caused by WDTCTL security key violation
> >
> > 
> >Hi everyone,
> >
> >I'm working on a sensor project which uses
> >TelosB<http://www.memsic.com/products/wireless-sensor-networks/wireless-modules.html>based
> >on msp430f1611 running
> >TinyOS <http://tinyos.net/>. My program is reset some time after boot
> >up. After the PUC reset, IFG1 is found with WDTIFG bit set, indicating the
> >watchdog timer initiates the reset. This can happen under two cases:
> >1) Watchdog timer expiration when in watchdog mode only.
> >But watchdog timer is never started, so this cannot happen.
> >2) Watchdog timer security key violation.
> >There is no place that my program explicitly writes WDTCTL (i.e., 0x0120h).
> >So there must be some memory access bug in my code, which illegally writes
> >WDTCTL and causes security key violation.
> >Is there any debug tool to help locate where this happens? Or any any
> >suggestion on how I should proceed to locate the bug? My program is of
> >thousands of lines, so manual check is non-trivial.
> >
> >Please weigh in if you have any suggestion. Thank you very much in advance.
> >
> >More detailed information of the bug can be found
> >here<http://www.mail-archive.com/tinyos-help@.../msg42390.html>
> >.
> >
> >-Xiaohui Liu
> >
> >
> >
> >
> >
>
>
>





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

there is a good chance that all the initialization is taking too long.. in that case you have to keep the watchdog disabled in the startup code..
 
>________________________________
>From: sinotrinity
>To: m...
>Sent: Sunday, November 11, 2012 4:15 PM
>Subject: [msp430] Re: how to debug reset caused by WDTCTL security key violation
>
> 
>Hi,
>
>The watchdog is enabled during initialization.
>
>Any suggestion on how to locate this bug? I've been wrestling with this bug for the past few weeks and still not found it. I'd really appreciate if you can help.
>
>--- In mailto:msp430%40yahoogroups.com, Joe Radomski wrote:
>>
>> you may not have enabled the watchdog, but most versions of the startup code enable the watchdog timer by default.. even if the first line of your code disabled it, it might not even get to your code before reseting.. this can happen if you have alot of variables that have to be cleared and initialized or data to be copied..
>>  
>> In this case you need to modify the startup code (cstart.asm) to not enable the wd timer and recompile..
>>
>>
>>
>> >________________________________
>> >From: Xiaohui Liu
>> >To: msp430
>> >Sent: Sunday, October 28, 2012 8:10 PM
>> >Subject: [msp430] how to debug reset caused by WDTCTL security key violation
>> >
>> > 
>> >Hi everyone,
>> >
>> >I'm working on a sensor project which uses
>> >TelosB<http://www.memsic.com/products/wireless-sensor-networks/wireless-modules.html>based
>> >on msp430f1611 running
>> >TinyOS <http://tinyos.net/>. My program is reset some time after boot
>> >up. After the PUC reset, IFG1 is found with WDTIFG bit set, indicating the
>> >watchdog timer initiates the reset. This can happen under two cases:
>> >1) Watchdog timer expiration when in watchdog mode only.
>> >But watchdog timer is never started, so this cannot happen.
>> >2) Watchdog timer security key violation.
>> >There is no place that my program explicitly writes WDTCTL (i.e., 0x0120h).
>> >So there must be some memory access bug in my code, which illegally writes
>> >WDTCTL and causes security key violation.
>> >Is there any debug tool to help locate where this happens? Or any any
>> >suggestion on how I should proceed to locate the bug? My program is of
>> >thousands of lines, so manual check is non-trivial.
>> >
>> >Please weigh in if you have any suggestion. Thank you very much in advance.
>> >
>> >More detailed information of the bug can be found
>> >here<http://www.mail-archive.com/tinyos-help@.../msg42390.html>
>> >.
>> >
>> >-Xiaohui Liu
>> >
>> >
>> >
>> >
>> >
>>
>>
>






(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi,

But no interrupt will be requested if the watchdog timer is in watchdog mode, which is the setting in my case.
According to the datasheet, "When the WDT is configured to operate in watchdog mode, either writing to WDTCTL with an incorrect password, or expiration of the selected time interval triggers a PUC."

Is there anyway to take a snapshot of the execution status right before PUC removes all the clues so we can trace back?

Thanks.

--- In m..., Onestone wrote:
>
> wRITE AN isr HANDLER FOR THE wdt INTERRUPT, TRAP IT HERE BEFORE THE puc
> CAN OCCUR then examine your stack to see where the code was executing
> prior to the violation. Then take it from there.
>
> You cannot do this after the PUC as the C start up sequences usually
> screw with the evidence.
>
> Al
>
> On 29/10/2012 10:40 AM, Xiaohui Liu wrote:
> > Hi everyone,
> >
> > I'm working on a sensor project which uses
> > TelosB<http://www.memsic.com/products/wireless-sensor-networks/wireless-modules.html>based
> > on msp430f1611 running
> > TinyOS <http://tinyos.net>. My program is reset some time after boot
> > up. After the PUC reset, IFG1 is found with WDTIFG bit set, indicating the
> > watchdog timer initiates the reset. This can happen under two cases:
> > 1) Watchdog timer expiration when in watchdog mode only.
> > But watchdog timer is never started, so this cannot happen.
> > 2) Watchdog timer security key violation.
> > There is no place that my program explicitly writes WDTCTL (i.e., 0x0120h).
> > So there must be some memory access bug in my code, which illegally writes
> > WDTCTL and causes security key violation.
> > Is there any debug tool to help locate where this happens? Or any any
> > suggestion on how I should proceed to locate the bug? My program is of
> > thousands of lines, so manual check is non-trivial.
> >
> > Please weigh in if you have any suggestion. Thank you very much in advance.
> >
> > More detailed information of the bug can be found
> > here<http://www.mail-archive.com/tinyos-help@.../msg42390.html>
> > .
> >
> > -Xiaohui Liu
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Sorry about the confusion, I mean the watchdog is *disabled* during
initialization, not *enabled*. So case (1) of watchdog timer expiration
cannot happen.

On Sun, Nov 11, 2012 at 4:31 PM, Joe Radomski wrote:

> **
> there is a good chance that all the initialization is taking too long.. in
> that case you have to keep the watchdog disabled in the startup code..
> >________________________________
> >From: sinotrinity
> >To: m...
> >Sent: Sunday, November 11, 2012 4:15 PM
> >Subject: [msp430] Re: how to debug reset caused by WDTCTL security key
> violation
>
> >
> >
> >Hi,
> >
> >The watchdog is enabled during initialization.
> >
> >Any suggestion on how to locate this bug? I've been wrestling with this
> bug for the past few weeks and still not found it. I'd really appreciate if
> you can help.
> >
> >--- In mailto:msp430%40yahoogroups.com, Joe Radomski
> wrote:
> >>
> >> you may not have enabled the watchdog, but most versions of the startup
> code enable the watchdog timer by default.. even if the first line of your
> code disabled it, it might not even get to your code before reseting.. this
> can happen if you have alot of variables that have to be cleared and
> initialized or data to be copied..
> >> Â
> >> In this case you need to modify the startup code (cstart.asm) to not
> enable the wd timer and recompile..
> >>
> >>
> >>
> >> >________________________________
> >> >From: Xiaohui Liu
> >> >To: msp430
> >> >Sent: Sunday, October 28, 2012 8:10 PM
> >> >Subject: [msp430] how to debug reset caused by WDTCTL security key
> violation
> >> >
> >> >Â
> >> >Hi everyone,
> >> >
> >> >I'm working on a sensor project which uses
> >> >TelosB<
> http://www.memsic.com/products/wireless-sensor-networks/wireless-modules.html
> >based
> >> >on msp430f1611 running
> >> >TinyOS <http://tinyos.net/>. My program is reset some time after boot
> >> >up. After the PUC reset, IFG1 is found with WDTIFG bit set, indicating
> the
> >> >watchdog timer initiates the reset. This can happen under two cases:
> >> >1) Watchdog timer expiration when in watchdog mode only.
> >> >But watchdog timer is never started, so this cannot happen.
> >> >2) Watchdog timer security key violation.
> >> >There is no place that my program explicitly writes WDTCTL (i.e.,
> 0x0120h).
> >> >So there must be some memory access bug in my code, which illegally
> writes
> >> >WDTCTL and causes security key violation.
> >> >Is there any debug tool to help locate where this happens? Or any any
> >> >suggestion on how I should proceed to locate the bug? My program is of
> >> >thousands of lines, so manual check is non-trivial.
> >> >
> >> >Please weigh in if you have any suggestion. Thank you very much in
> advance.
> >> >
> >> >More detailed information of the bug can be found
> >> >here<http://www.mail-archive.com/tinyos-help@.../msg42390.html>
> >> >.
> >> >
> >> >-Xiaohui Liu
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> >
>
>
>






(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Sun, 11 Nov 2012 17:05:56 -0500, Xiaohui Liu wrote:

>Sorry about the confusion, I mean the watchdog is *disabled* during
>initialization, not *enabled*. So case (1) of watchdog timer expiration
>cannot happen.

You earlier mentioned that you logically believe there must
be a security key violation causing the reset. I followed
your logic and, assuming all of the code was yours, I'd agree
with the conclusion. The fact is, though, that you have other
software in your system and you haven't discussed whether or
not you've gone through all of that code as well to ensure
that your statements about not turning on the WDT are valid.
It's possible it is happening in code you didn't write, given
that you include such code in your application.

Either way, why haven't you halted upon discovery of a
security key violation PUC, stopped immediately, and examined
RAM for the old stack information? It should still be there
(though of course upon reset you won't necessary have the
stack register to examine, you can still go look at where you
know the old stack data to reside.) You can set the stack
information so that it is possible to determine the extent of
the stack at the time of WDT PUC and if you know enough about
the activation frames used, I suspect you can work out where
things were at by dumping out that data and examining it
manually.

Is there a reason you haven't tried this? Do you have access
to the source code for the parts you didn't write, also, so
you can check for direct WDT references? How many places in
your code do you use indirection where it may result in this
problem? Have you "instrumented" that code so you compare
with the WDT address of interest before attempting an access?

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I should add that I don't remember if I ever saw a table
showing the values of each register upon POR and upon PUC,
seperately. They do discuss these values for peripheral
registers. But the CPU registers? I forget if I ever saw
them. In particular, I'm not sure of R1's value on PUC due to
WDT security violation. I suspect R4 through R15 are
unchanged, though. I've no idea about R1. In the case of a
power or brown out though I think the registers are either
random and/or unchanged depending upon exact circumstances.
Still again, not sure about R1 on PUC or POR. But I think you
don't have to have it, though it may be nice.

Can anyone reference a TI document on this exact topic? (I
did check a few Family Guides already.)

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Thanks for your kindly reply. My comments are inline.

On Sun, Nov 11, 2012 at 5:28 PM, Jon Kirwan wrote:

> **
> On Sun, 11 Nov 2012 17:05:56 -0500, Xiaohui Liu wrote:
>
> >Sorry about the confusion, I mean the watchdog is *disabled* during
> >initialization, not *enabled*. So case (1) of watchdog timer expiration
> >cannot happen.
>
> You earlier mentioned that you logically believe there must
> be a security key violation causing the reset. I followed
> your logic and, assuming all of the code was yours, I'd agree
> with the conclusion. The fact is, though, that you have other
> software in your system and you haven't discussed whether or
> not you've gone through all of that code as well to ensure
> that your statements about not turning on the WDT are valid.
> It's possible it is happening in code you didn't write, given
> that you include such code in your application.
>
> Either way, why haven't you halted upon discovery of a
> security key violation PUC, stopped immediately, and examined
> RAM for the old stack information?
>
How to achieve this, namely, "halted upon discovery of a security key
violation PUC"?

> It should still be there
> (though of course upon reset you won't necessary have the
> stack register to examine, you can still go look at where you
> know the old stack data to reside.) You can set the stack
> information so that it is possible to determine the extent of
> the stack at the time of WDT PUC and if you know enough about
> the activation frames used, I suspect you can work out where
> things were at by dumping out that data and examining it
> manually.
>
> Is there a reason you haven't tried this? Do you have access
> to the source code for the parts you didn't write, also, so
> you can check for direct WDT references? How many places in
> your code do you use indirection where it may result in this
> problem? Have you "instrumented" that code so you compare
> with the WDT address of interest before attempting an access?
>
For the reason mentioned above.
Yes, I have access to every line of the code.
The problem is that somewhere WDT address of interest, i.e., WDTCTL
register, is accessed unintentionally because, e.g., array index is out of
bound. And I'm having difficulty locating where this access occurs.

>
> Jon
>
>






(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Sun, 11 Nov 2012 21:40:02 -0500, Xiaohui Liu wrote:

>Thanks for your kindly reply. My comments are inline.
>
>On Sun, Nov 11, 2012 at 5:28 PM, Jon Kirwan wrote:
>
>> **
>> On Sun, 11 Nov 2012 17:05:56 -0500, Xiaohui Liu wrote:
>>
>> >Sorry about the confusion, I mean the watchdog is *disabled* during
>> >initialization, not *enabled*. So case (1) of watchdog timer expiration
>> >cannot happen.
>>
>> You earlier mentioned that you logically believe there must
>> be a security key violation causing the reset. I followed
>> your logic and, assuming all of the code was yours, I'd agree
>> with the conclusion. The fact is, though, that you have other
>> software in your system and you haven't discussed whether or
>> not you've gone through all of that code as well to ensure
>> that your statements about not turning on the WDT are valid.
>> It's possible it is happening in code you didn't write, given
>> that you include such code in your application.
>>
>> Either way, why haven't you halted upon discovery of a
>> security key violation PUC, stopped immediately, and examined
>> RAM for the old stack information?
>>
>How to achieve this, namely, "halted upon discovery of a security key
>violation PUC"?

What will happen is a PUC; you can't avoid that. Who cares?
Make sure that your reset vector points to code you control.
Write an IF statement (assembly code is best here) that
checks to see if this was a PUC reset, or not. If not, go
ahead and do the usual stuff. If not, execute some NOPs.
Place a breakpoint there. The debugger should be able to stop
at that point. That will be a "halt upon discovery of" for
you. At that point, go examine registers and RAM and dump all
of it to the PC for later examination.

>> It should still be there
>> (though of course upon reset you won't necessary have the
>> stack register to examine, you can still go look at where you
>> know the old stack data to reside.) You can set the stack
>> information so that it is possible to determine the extent of
>> the stack at the time of WDT PUC and if you know enough about
>> the activation frames used, I suspect you can work out where
>> things were at by dumping out that data and examining it
>> manually.
>>
>> Is there a reason you haven't tried this? Do you have access
>> to the source code for the parts you didn't write, also, so
>> you can check for direct WDT references? How many places in
>> your code do you use indirection where it may result in this
>> problem? Have you "instrumented" that code so you compare
>> with the WDT address of interest before attempting an access?
>>
>For the reason mentioned above.
>Yes, I have access to every line of the code.
>The problem is that somewhere WDT address of interest, i.e., WDTCTL
>register, is accessed unintentionally because, e.g., array index is out of
>bound. And I'm having difficulty locating where this access occurs.

See above. And why not instrument ever indirect reference as
I mentioned, too, while you are at it?

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Sun, 11 Nov 2012 21:31:31 -0800, I wrote:

>If not, execute some NOPs.

I mean, "If so, execute some NOPs."

Sorry about that.

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

just to be 100% clear.. Did You modify the startup code to not enable the wd timer?
 
By default it is ENABLED by many of the compilers and you must make sure it is disabled by removing the code in the compiler startup code (NOT YOUR CODE).. It is not enough not to just not enable it in your code. This is why many of the code examples start by disabling the WD timer.. When you have alot of variables and data to be copied/initialized the timer can time out before it ever gets to the user code.
 
 
>________________________________
>From: Xiaohui Liu
>To: m...
>Sent: Sunday, November 11, 2012 5:05 PM
>Subject: Re: [msp430] Re: how to debug reset caused by WDTCTL security key violation
>
>Sorry about the confusion, I mean the watchdog is *disabled* during
>initialization, not *enabled*. So case (1) of watchdog timer expiration
>cannot happen.
>
>On Sun, Nov 11, 2012 at 4:31 PM, Joe Radomski wrote:
>
>> **
>> there is a good chance that all the initialization is taking too long.. in
>> that case you have to keep the watchdog disabled in the startup code..
>> >________________________________
>> >From: sinotrinity
>> >To: m...
>> >Sent: Sunday, November 11, 2012 4:15 PM
>> >Subject: [msp430] Re: how to debug reset caused by WDTCTL security key
>> violation
>>
>> >
>> >
>> >Hi,
>> >
>> >The watchdog is enabled during initialization.
>> >
>> >Any suggestion on how to locate this bug? I've been wrestling with this
>> bug for the past few weeks and still not found it. I'd really appreciate if
>> you can help.
>> >
>> >--- In mailto:msp430%40yahoogroups.com, Joe Radomski
>> wrote:
>> >>
>> >> you may not have enabled the watchdog, but most versions of the startup
>> code enable the watchdog timer by default.. even if the first line of your
>> code disabled it, it might not even get to your code before reseting.. this
>> can happen if you have alot of variables that have to be cleared and
>> initialized or data to be copied..
>> >> Â
>> >> In this case you need to modify the startup code (cstart.asm) to not
>> enable the wd timer and recompile..
>> >>
>> >>
>> >>
>> >> >________________________________
>> >> >From: Xiaohui Liu
>> >> >To: msp430
>> >> >Sent: Sunday, October 28, 2012 8:10 PM
>> >> >Subject: [msp430] how to debug reset caused by WDTCTL security key
>> violation
>> >> >
>> >> >Â
>> >> >Hi everyone,
>> >> >
>> >> >I'm working on a sensor project which uses
>> >> >TelosB<
>> http://www.memsic.com/products/wireless-sensor-networks/wireless-modules.html
>> >based
>> >> >on msp430f1611 running
>> >> >TinyOS <http://tinyos.net/>. My program is reset some time after boot
>> >> >up. After the PUC reset, IFG1 is found with WDTIFG bit set, indicating
>> the
>> >> >watchdog timer initiates the reset. This can happen under two cases:
>> >> >1) Watchdog timer expiration when in watchdog mode only.
>> >> >But watchdog timer is never started, so this cannot happen.
>> >> >2) Watchdog timer security key violation.
>> >> >There is no place that my program explicitly writes WDTCTL (i.e.,
>> 0x0120h).
>> >> >So there must be some memory access bug in my code, which illegally
>> writes
>> >> >WDTCTL and causes security key violation.
>> >> >Is there any debug tool to help locate where this happens? Or any any
>> >> >suggestion on how I should proceed to locate the bug? My program is of
>> >> >thousands of lines, so manual check is non-trivial.
>> >> >
>> >> >Please weigh in if you have any suggestion. Thank you very much in
>> advance.
>> >> >
>> >> >More detailed information of the bug can be found
>> >> >here<http://www.mail-archive.com/tinyos-help@.../msg42390.html>
>> >> >.
>> >> >
>> >> >-Xiaohui Liu
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>> >
>>
>>
>>
>> 
>>
>
>
>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

> just to be 100% clear.. Did You modify the startup code to not enable the
> wd timer?
>
> By default it is ENABLED by many of the compilers and you must make sure
> it is disabled by removing the code in the compiler startup code (NOT YOUR
> CODE).. It is not enough not to just not enable it in your code. This is
> why many of the code examples start by disabling the WD timer.. When you
> have alot of variables and data to be copied/initialized the timer can
> time out before it ever gets to the user code.

I think the WD is enabled by the hardware and the runtime system may, or may
not, disable it. And, as has been said before, if the runtime has a lot of
zeroing to do, main() may well not be entered before the WDT expires causing
endless resets.

--
Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

CIL, please.

On Mon, Nov 12, 2012 at 12:31 AM, Jon Kirwan wrote:

> **
> On Sun, 11 Nov 2012 21:40:02 -0500, Xiaohui Liu wrote:
>
> >Thanks for your kindly reply. My comments are inline.
> >
> >On Sun, Nov 11, 2012 at 5:28 PM, Jon Kirwan > >wrote:
> >
> >> **
>
> >>
> >>
> >> On Sun, 11 Nov 2012 17:05:56 -0500, Xiaohui Liu wrote:
> >>
> >> >Sorry about the confusion, I mean the watchdog is *disabled* during
> >> >initialization, not *enabled*. So case (1) of watchdog timer expiration
> >> >cannot happen.
> >>
> >> You earlier mentioned that you logically believe there must
> >> be a security key violation causing the reset. I followed
> >> your logic and, assuming all of the code was yours, I'd agree
> >> with the conclusion. The fact is, though, that you have other
> >> software in your system and you haven't discussed whether or
> >> not you've gone through all of that code as well to ensure
> >> that your statements about not turning on the WDT are valid.
> >> It's possible it is happening in code you didn't write, given
> >> that you include such code in your application.
> >>
> >> Either way, why haven't you halted upon discovery of a
> >> security key violation PUC, stopped immediately, and examined
> >> RAM for the old stack information?
> >>
> >How to achieve this, namely, "halted upon discovery of a security key
> >violation PUC"?
>
> What will happen is a PUC; you can't avoid that. Who cares?
> Make sure that your reset vector points to code you control.
> Write an IF statement (assembly code is best here) that
> checks to see if this was a PUC reset, or not. If not, go
> ahead and do the usual stuff. If not, execute some NOPs.
> Place a breakpoint there. The debugger should be able to stop
> at that point. That will be a "halt upon discovery of" for
> you. At that point, go examine registers and RAM and dump all
> of it to the PC for later examination.
>
I was thinking along the same line. One difficulty is that program counter
(PC) is loaded with address contained at reset vector location (0FFFEh). So
even I point reset vector to code under my control, PC is irreversibly
erased. Ideally, I want to trace back to the instruction or statement
causing the PUC. Any suggestion on how this may be achieved? Thanks again.

>> It should still be there
> >> (though of course upon reset you won't necessary have the
> >> stack register to examine, you can still go look at where you
> >> know the old stack data to reside.) You can set the stack
> >> information so that it is possible to determine the extent of
> >> the stack at the time of WDT PUC and if you know enough about
> >> the activation frames used, I suspect you can work out where
> >> things were at by dumping out that data and examining it
> >> manually.
> >>
> >> Is there a reason you haven't tried this? Do you have access
> >> to the source code for the parts you didn't write, also, so
> >> you can check for direct WDT references? How many places in
> >> your code do you use indirection where it may result in this
> >> problem? Have you "instrumented" that code so you compare
> >> with the WDT address of interest before attempting an access?
> >>
> >For the reason mentioned above.
> >Yes, I have access to every line of the code.
> >The problem is that somewhere WDT address of interest, i.e., WDTCTL
> >register, is accessed unintentionally because, e.g., array index is out of
> >bound. And I'm having difficulty locating where this access occurs.
>
> See above. And why not instrument ever indirect reference as
> I mentioned, too, while you are at it?
>
> Jon
>
>
>






(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Please see in line.

On Mon, Nov 12, 2012 at 9:51 AM, Joe Radomski wrote:

> **
> just to be 100% clear.. Did You modify the startup code to not enable the
> wd timer?
The default startup code disables the watchdog timer. I do NOT change
it. I'm sure the program enters the user code because reset occurs in user
code.

> By default it is ENABLED by many of the compilers and you must make sure
> it is disabled by removing the code in the compiler startup code (NOT YOUR
> CODE).. It is not enough not to just not enable it in your code. This is
> why many of the code examples start by disabling the WD timer.. When you
> have alot of variables and data to be copied/initialized the timer can time
> out before it ever gets to the user code.
>
> >________________________________
> >From: Xiaohui Liu
> >To: m...
> >Sent: Sunday, November 11, 2012 5:05 PM
> >Subject: Re: [msp430] Re: how to debug reset caused by WDTCTL security
> key violation
>
> >
> >Sorry about the confusion, I mean the watchdog is *disabled* during
> >initialization, not *enabled*. So case (1) of watchdog timer expiration
>
> >cannot happen.
> >
> >On Sun, Nov 11, 2012 at 4:31 PM, Joe Radomski
> wrote:
> >
> >> **
>
> >>
> >>
> >> there is a good chance that all the initialization is taking too long..
> in
> >> that case you have to keep the watchdog disabled in the startup code..
> >>
> >>
> >> >________________________________
> >> >From: sinotrinity
> >> >To: m...
> >> >Sent: Sunday, November 11, 2012 4:15 PM
> >> >Subject: [msp430] Re: how to debug reset caused by WDTCTL security key
> >> violation
> >>
> >> >
> >> >
> >> >Hi,
> >> >
> >> >The watchdog is enabled during initialization.
> >> >
> >> >Any suggestion on how to locate this bug? I've been wrestling with this
> >> bug for the past few weeks and still not found it. I'd really
> appreciate if
> >> you can help.
> >> >
> >> >--- In mailto:msp430%40yahoogroups.com, Joe Radomski
> >> wrote:
> >> >>
> >> >> you may not have enabled the watchdog, but most versions of the
> startup
> >> code enable the watchdog timer by default.. even if the first line of
> your
> >> code disabled it, it might not even get to your code before reseting..
> this
> >> can happen if you have alot of variables that have to be cleared and
> >> initialized or data to be copied..
> >> >> Â
> >> >> In this case you need to modify the startup code (cstart.asm) to not
> >> enable the wd timer and recompile..
> >> >>
> >> >>
> >> >>
> >> >> >________________________________
> >> >> >From: Xiaohui Liu
> >> >> >To: msp430
> >> >> >Sent: Sunday, October 28, 2012 8:10 PM
> >> >> >Subject: [msp430] how to debug reset caused by WDTCTL security key
> >> violation
> >> >> >
> >> >> >Â
> >> >> >Hi everyone,
> >> >> >
> >> >> >I'm working on a sensor project which uses
> >> >> >TelosB<
> >>
> http://www.memsic.com/products/wireless-sensor-networks/wireless-modules.html
> >> >based
> >> >> >on msp430f1611 running
> >> >> >TinyOS <http://tinyos.net/>. My program is reset some time after
> boot
> >> >> >up. After the PUC reset, IFG1 is found with WDTIFG bit set,
> indicating
> >> the
> >> >> >watchdog timer initiates the reset. This can happen under two cases:
> >> >> >1) Watchdog timer expiration when in watchdog mode only.
> >> >> >But watchdog timer is never started, so this cannot happen.
> >> >> >2) Watchdog timer security key violation.
> >> >> >There is no place that my program explicitly writes WDTCTL (i.e.,
> >> 0x0120h).
> >> >> >So there must be some memory access bug in my code, which illegally
> >> writes
> >> >> >WDTCTL and causes security key violation.
> >> >> >Is there any debug tool to help locate where this happens? Or any
> any
> >> >> >suggestion on how I should proceed to locate the bug? My program is
> of
> >> >> >thousands of lines, so manual check is non-trivial.
> >> >> >
> >> >> >Please weigh in if you have any suggestion. Thank you very much in
> >> advance.
> >> >> >
> >> >> >More detailed information of the bug can be found
> >> >> >here<http://www.mail-archive.com/tinyos-help@.../msg42390.html>
> >> >> >.
> >> >> >
> >> >> >-Xiaohui Liu
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
> >
>
> >
> >
> >
> >



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Mon, 12 Nov 2012 14:13:13 -0500, you wrote:

>I was thinking along the same line. One difficulty is that program counter
>(PC) is loaded with address contained at reset vector location (0FFFEh). So
>even I point reset vector to code under my control, PC is irreversibly
>erased. Ideally, I want to trace back to the instruction or statement
>causing the PUC. Any suggestion on how this may be achieved? Thanks again.

Yes. Look at the stack activation frames. This will give you
a lot of information. Not EVERYTHING you want. But ALMOST
everything. You just need to use your brain, is all. The
stack will not tell you the last PC address, but it will tell
you everything that happened up until. This excludes a LOT,
making reasonable and probable assumptions. You are looking
for any clues. And this will give you many such clues.

I've done this many times on many processors going back many
years. It's productive.

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Mon, 12 Nov 2012 15:21:34 -0000, Paul wrote:

>I think the WD is enabled by the hardware and the runtime system may, or may
>not, disable it.

It is enabled -- the documentation is quite clear on that
point, both in words and in state machine diagrams. But that
can be quickly disabled in the crt0 (or whatever it is
called) code, if for some reason waiting until main() is
called is a problem. The OP said that it is disabled
somewhere -- and I believe it is a reasonable assumption that
the OP knows it actually is before the next PUC. It's too
easy to check that.

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi Xiaohui,

a litte suggestion:.

Xiaohui Liu :

> 2) Watchdog timer security key violation.

Probably stack overflow. Fill your RAM with a simple pattern (e.g.
0xDeadBeef), put a breakpoint at reset (before the RAM is initialized by the
startupcode) and after the next break after reset take a look in the RAM
space. If there is no 0xDeadBeef anymore you have a problem. :-)

M.





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

--- In m..., Matthias Weingart wrote:
>
> Hi Xiaohui,
>
> a litte suggestion:.
>
> Xiaohui Liu :
>
> > 2) Watchdog timer security key violation.
>
> Probably stack overflow. Fill your RAM with a simple pattern (e.g.
> 0xDeadBeef), put a breakpoint at reset (before the RAM is initialized by the
> startupcode) and after the next break after reset take a look in the RAM
> space. If there is no 0xDeadBeef anymore you have a problem. :-)
>
> M.

Or you could use 0XDecafBad (as seen in some Stellaris Examples) :)





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Wed, 14 Nov 2012 08:17:33 +0000 (UTC), you wrote:

>Hi Xiaohui,
>
>a litte suggestion:.
>
>Xiaohui Liu :
>
>> 2) Watchdog timer security key violation.
>
>Probably stack overflow. Fill your RAM with a simple pattern (e.g.
>0xDeadBeef), put a breakpoint at reset (before the RAM is initialized by the
>startupcode) and after the next break after reset take a look in the RAM
>space. If there is no 0xDeadBeef anymore you have a problem. :-)

I suggested what amounts to that a few days ago, without
meaningful response yet. It's possible it's still a work in
progress.

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Thank all for your help. It IS stack overflow. After I reduce my RAM usage
by ~2 KB, it works like a charm.

-Xiaohui Liu

On Wed, Nov 14, 2012 at 4:48 AM, Jon Kirwan wrote:

> **
> On Wed, 14 Nov 2012 08:17:33 +0000 (UTC), you wrote:
>
> >Hi Xiaohui,
> >
> >a litte suggestion:.
> >
> >Xiaohui Liu :
> >
> >> 2) Watchdog timer security key violation.
> >
> >Probably stack overflow. Fill your RAM with a simple pattern (e.g.
> >0xDeadBeef), put a breakpoint at reset (before the RAM is initialized by
> the
> >startupcode) and after the next break after reset take a look in the RAM
> >space. If there is no 0xDeadBeef anymore you have a problem. :-)
>
> I suggested what amounts to that a few days ago, without
> meaningful response yet. It's possible it's still a work in
> progress.
>
> Jon
>
>
>






(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Yeah.
However it is really a problem that the stack space is not protected in the
MSP's (or almost any other controller). I also do not know a tool that
calculates maximal stack usage (this is possible in case recursion is not
used). It is something like "ok it is running - so stack space seem
sufficient" - some kind of hope based design ;-).

M.

Xiaohui Liu :

> Thank all for your help. It IS stack overflow. After I reduce my RAM
> usage by ~2 KB, it works like a charm.
>
> -Xiaohui Liu
>
> On Wed, Nov 14, 2012 at 4:48 AM, Jon Kirwan
> wrote:
>
>> **
>> On Wed, 14 Nov 2012 08:17:33 +0000 (UTC), you wrote:
>>
>> >Hi Xiaohui,
>> >
>> >a litte suggestion:.
>> >
>> >Xiaohui Liu :
>> >
>> >> 2) Watchdog timer security key violation.
>> >
>> >Probably stack overflow. Fill your RAM with a simple pattern (e.g.
>> >0xDeadBeef), put a breakpoint at reset (before the RAM is initialized
>> >by
>> the
>> >startupcode) and after the next break after reset take a look in the
>> >RAM space. If there is no 0xDeadBeef anymore you have a problem. :-)
>>
>> I suggested what amounts to that a few days ago, without
>> meaningful response yet. It's possible it's still a work in
>> progress.
>>
>> Jon
>>





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Matthias Weingart wrote:
> Yeah.
> However it is really a problem that the stack space is not protected in the
> MSP's (or almost any other controller). I also do not know a tool that
> calculates maximal stack usage (this is possible in case recursion is not
> used). It is something like "ok it is running - so stack space seem
> sufficient" - some kind of hope based design ;-).

I guess it is what our target is. Last I wrote an astronomical clock,
fits inside a 2253 fine. But we lay down an 2453 for a few cents more
and plenty of room for an os that can do this. but then we have a half
of k of ram and never have to worry about an overflow! But why worry
about an overflow if the code is right? I'll use the space for expansion.

The struggle is what you write. If the stack is in question I would
think we are expecting box performance on an embedded, I don't depend on
an os of unknown quality for the likes of the msp. I'll expect handling
on the box side of an app, not the msp.

BTW, I have never use recursive calls; not in going on 40 some years.
Create your own stack inside the call and you don't have to worry about
what the compiler does; you are in control. There is no good reason to
go recursive and create unneeded waste.

Best, Dan.

--
"If they can get you asking the wrong questions, they don’t
have to worry about answers."

-- Thomas Pynchon





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Assembler? Never any problems with stack space.

Al

On 16/11/2012 6:09 PM, Matthias Weingart wrote:
> Yeah.
> However it is really a problem that the stack space is not protected in the
> MSP's (or almost any other controller). I also do not know a tool that
> calculates maximal stack usage (this is possible in case recursion is not
> used). It is something like "ok it is running - so stack space seem
> sufficient" - some kind of hope based design ;-).
>
> M.
>
> Xiaohui Liu :
>
>> Thank all for your help. It IS stack overflow. After I reduce my RAM
>> usage by ~2 KB, it works like a charm.
>>
>> -Xiaohui Liu
>>
>> On Wed, Nov 14, 2012 at 4:48 AM, Jon Kirwan
>> wrote:
>>
>>> **
>>>
>>>
>>> On Wed, 14 Nov 2012 08:17:33 +0000 (UTC), you wrote:
>>>
>>>> Hi Xiaohui,
>>>>
>>>> a litte suggestion:.
>>>>
>>>> Xiaohui Liu :
>>>>
>>>>> 2) Watchdog timer security key violation.
>>>> Probably stack overflow. Fill your RAM with a simple pattern (e.g.
>>>> 0xDeadBeef), put a breakpoint at reset (before the RAM is initialized
>>>> by
>>> the
>>>> startupcode) and after the next break after reset take a look in the
>>>> RAM space. If there is no 0xDeadBeef anymore you have a problem. :-)
>>> I suggested what amounts to that a few days ago, without
>>> meaningful response yet. It's possible it's still a work in
>>> progress.
>>>
>>> Jon
>>>
>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi Matthias,

> However it is really a problem that the stack space is not protected
> in the MSP's (or almost any other controller). I also do not know a
> tool that calculates maximal stack usage (this is possible in case
> recursion is not used). It is something like "ok it is running - so
> stack space seem sufficient" - some kind of hope based design ;-).

IAR can give you that information in the linker output. In the linker options for your project switch to the "List" tab and check the "Static Overlay Map" option. In your output .map file there is a section titled "Call Graph" which shows stack usage for all your function calls. If you go right to the bottom of that section you can see the maximum stack usage.

I guess other compilers might have a similar feature.





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

DeadBeef is better, its 2 - 16 bit words



DecafBad is 20 – 12 bits, not an exact split.







From: m... [mailto:m...] On Behalf Of Jon Kirwan

Sent: Wednesday, November 14, 2012 4:49 AM

To: MSP430 List

Subject: Re: [msp430] Re: how to debug reset caused by WDTCTL security key violation











On Wed, 14 Nov 2012 08:17:33 +0000 (UTC), you wrote:



>Hi Xiaohui,

>

>a litte suggestion:.

>

>Xiaohui Liu >:

>

>> 2) Watchdog timer security key violation.

>

>Probably stack overflow. Fill your RAM with a simple pattern (e.g.

>0xDeadBeef), put a breakpoint at reset (before the RAM is initialized by the

>startupcode) and after the next break after reset take a look in the RAM

>space. If there is no 0xDeadBeef anymore you have a problem. :-)



I suggested what amounts to that a few days ago, without

meaningful response yet. It's possible it's still a work in

progress.



Jon













(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

"david_mcminn" :

> Hi Matthias,
>
>> However it is really a problem that the stack space is not protected
>> in the MSP's (or almost any other controller). I also do not know a
>> tool that calculates maximal stack usage (this is possible in case
>> recursion is not used). It is something like "ok it is running - so
>> stack space seem sufficient" - some kind of hope based design ;-).
>
> IAR can give you that information in the linker output. In the linker
> options for your project switch to the "List" tab and check the "Static
> Overlay Map" option. In your output .map file there is a section titled
> "Call Graph" which shows stack usage for all your function calls. If you
> go right to the bottom of that section you can see the maximum stack
> usage.

Thx. Is there some kind of warning in case the maximum stack usage is
larger than the free RAM?
What is "static overlay map"? Is there a separate RAM space used for the
local variables used in the functions and the stack is used only for return
adresses? (I remember the keil C51 compiler is doing it that way, because
stack space is quite limited in the 8051)

> I guess other compilers might have a similar feature.

It seems my Crossworks compiler/linker does not have this feature. The Map-
File is quite simple...

M.





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi Matthias,

> >> However it is really a problem that the stack space is not
> >> protected in the MSP's (or almost any other controller). I also
> >> do not know a tool that calculates maximal stack usage (this is
> >> possible in case recursion is not used). It is something like
> >> "ok it is running - so stack space seem sufficient" - some kind
> >> of hope based design ;-).
> >
> > IAR can give you that information in the linker output. In the
> > linker options for your project switch to the "List" tab and
> > check the "Static Overlay Map" option. In your output .map file
> > there is a section titled "Call Graph" which shows stack usage
> > for all your function calls. If you go right to the bottom of
> > that section you can see the maximum stack usage.
>
> Thx. Is there some kind of warning in case the maximum stack usage
> is larger than the free RAM?

It does not give you a warning when you exceed the size of the stack you set in the project options, nor when you exceed the size of ram space. So it looks like you would need to manually check.

As I was checking this I noticed lines that said "Recursive system consisting of" when I had used memmove(), so perhaps this still does not give a true picture if you have (perhaps unknowingly) used a recursive library call.

> What is "static overlay map"? Is there a separate RAM space used
> for the local variables used in the functions and the stack is used
> only for return adresses? (I remember the keil C51 compiler is
> doing it that way, because stack space is quite limited in the 8051)

According to the manual, you cannot choose to use static overlay (which is as you describe) with the MSP430 version of IAR, I guess because there is enough RAM. However, you can still turn on the output, the static overlay map, which shows how much RAM would be used by local variables.

I guess (I haven't used IAR compilers for other targets) that the map when using static overlay for real would show you the address in RAM and what local variables it is used for.





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hint:

Put a flag on memmove() at the beginning test to see if it is set, if
not, set it, at the end clear it.

If When you come in, it is set, you are doing it recursively,
unknowingly( I would assume).

From: m... [mailto:m...] On Behalf
Of david_mcminn
Sent: Monday, November 19, 2012 4:17 AM
To: m...
Subject: [msp430] Re: how to debug reset caused by WDTCTL security key
violation

Hi Matthias,

> >> However it is really a problem that the stack space is not
> >> protected in the MSP's (or almost any other controller). I also
> >> do not know a tool that calculates maximal stack usage (this is
> >> possible in case recursion is not used). It is something like
> >> "ok it is running - so stack space seem sufficient" - some kind
> >> of hope based design ;-).
> >
> > IAR can give you that information in the linker output. In the
> > linker options for your project switch to the "List" tab and
> > check the "Static Overlay Map" option. In your output .map file
> > there is a section titled "Call Graph" which shows stack usage
> > for all your function calls. If you go right to the bottom of
> > that section you can see the maximum stack usage.
>
> Thx. Is there some kind of warning in case the maximum stack usage
> is larger than the free RAM?

It does not give you a warning when you exceed the size of the stack you
set in the project options, nor when you exceed the size of ram space.
So it looks like you would need to manually check.

As I was checking this I noticed lines that said "Recursive system
consisting of" when I had used memmove(), so perhaps this still does not
give a true picture if you have (perhaps unknowingly) used a recursive
library call.

> What is "static overlay map"? Is there a separate RAM space used
> for the local variables used in the functions and the stack is used
> only for return adresses? (I remember the keil C51 compiler is
> doing it that way, because stack space is quite limited in the 8051)

According to the manual, you cannot choose to use static overlay (which
is as you describe) with the MSP430 version of IAR, I guess because
there is enough RAM. However, you can still turn on the output, the
static overlay map, which shows how much RAM would be used by local
variables.

I guess (I haven't used IAR compilers for other targets) that the map
when using static overlay for real would show you the address in RAM and
what local variables it is used for.







(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )