Trust me, if I could think of a way to accomplish what I need to without the watchdog reset, I would.
I'm doing a fairly complex design using a pretty cut-rate part (F2012). The USI/I2C hardware pretty much sucks and it gets stuck periodically for various reasons. I use the watchdog to get unstuck. I'm using almost all of my available resources and this has been the most compact and reliable method so far.
I haven't been doing this for 40 years yet, but I'm not really a novice either. Any suggestions?

-Aaron

----- Original Message -----
From: "One Stone"
To: m...
Sent: Thursday, January 10, 2008 11:22:16 AM (GMT-0700) America/Denver
Subject: Re: [msp430] Re: status of RAM after PUC

AS I thought, using the PUC data to cleanly power up, but why on earth
do you feel the need to to reset periodically!! That throws me
completely. I have systems that have been running since 1998 without
ever being reset, powered down or anything else. I've been around this
game for nearly 40 years and can't imagine a non-failure mode that would
make this desirable. I would appreciate enlightenment?

Cheers

Al

Aaron Greer wrote:

>Thanks for all of your replies to my original question.
>
>In my application, I let the watchdog reset the device (PUC) periodically. I was just looking for a convenient (non-Flash) method to retain some state information across PUC events. I have no need to retain information across power cycles or RST conditions. Immediately after reset, my code checks the reset flags to determine the cause and then intelligently initializes (or not) the appropriate globals and SFR bits.
>
>thanks again,
>Aaron
>----- Original Message -----
>From: "tintronic" < m...@elboldo.cl >
>To: m...
>Sent: Thursday, January 10, 2008 10:53:59 AM (GMT-0700) America/Denver
>Subject: [msp430] Re: status of RAM after PUC
>
>__no_init variables retain their values after a PUC. Period.
>Why the PUC happened and the implications on the variables is another
>matter entirely.
>
>"...and since several of the failure modes that generate PUC without
>POR are the result of events which place the contents of RAM at risk
>you cannot rely upon the contents of RAM..."
>Let's see. Events that trigger PUC without POR (extracted from the
>datasheed):
>1) Watchdog timer expiration when in watchdog mode only
>2) Watchdog timer security key violation
>3) A Flash memory security key violation
>
>None of this events put ram contents at risk. If the PUC was generated
>by a bad programming that's a different story. Then you can't trust
>the contents of RAM with or without PUC. I've seen treads where peoply
>intently make an illegal write to the watchdog register to generate a PUC.
>
>I'm just answering the question that was asked, without making an
>assumption on why the PUC generates or why he would need to preserve
>the value of a variable after a PUC but not a POR (or else he'd be
>using info-flash or an external EEPROM).
>
>I'm not assuming his program is wrong. He is not asking for help with
>undesired or unplanned PUCs, he just wants to know if __no_init
>variables retain their state after a PUC. Nothing more, nothing less.
>
>Michael Kusch.
>
>--- In m... , One Stone wrote:
>>This is a very stunted view of the process. Since a PUC is generated by
>>a POR you cannot simply divorce them, and since several of the failure
>>modes that generate PUC without POR are the result of events which
>>place the contents of RAM at risk you cannot rely upon the contents of
>>RAM without a full understanding of the failure modes. You have taken a
>>purely C centric view. C is divorced from the hardware, and has nothing
>>to do with POR or PUC.
>>
>>In badly written software the normal course may be to simply blow
>>through the initialisation procedures as if a start up was occurring,
>>but well written software should try to analyse the failure means,
>since
>>no 'normal' event should ever see a PUC or POR occur. Not all systems
>>can afford to simply reset. Down that path dies potential disaster.
>Many
>>systems must, at the very least, try and recover sequencing data, like
>>time, or current machine state, while many systems need to recover from
>>different failure modes in different ways.
>>
>>Al
>>
>>tintronic wrote:
>>
>>>Let's make a long story short: The question was about PUC, not POR.
>>>That's a hardware related question.
>>>After PUC, __no_init variables retain their values. That's the answer.
>>>
>>>
>>>The explanation:
>>>PUC is a hardware signal that does NOT clear RAM. It initializes
>>>various registers, but doesn't touch data RAM.
>>>
>>>Follow up question: What does the software do after a PUC?
>>>After PUC (and therefore POR too) there is normally a software
>>>initialization which clears and sets the memory location for each of
>>>the declared global variables UNLESS the variable is declared as
>>>__no_init. These value will not be changed.
>>>
>>>A useful comment:
>>>POR doesn't clear RAM either. There are only two events who
>>>
>>>
>generate POR:
>>>1) RST pin: Any __no_init variable retains its value.
>>>2a) Device Power Up: RAM is filled with garbage.
>>>2b) If device has BOR(which replaces POR): RAM values are not to be
>>>trustet due to a too low Vcc, below its ability to retain RAM data.
>>>
>>>Best Regards,
>>>Michael Kusch
>>>--- In m... , One Stone wrote:
>>>
>>>
>>>
>>>
>>>>Ok. A PUC is ALWAYS generated by a POR, but a POR is not always
>>>>generated by a PUC. Certain things that cause a PUC will not
>>>>
>>>>
>>>>
>>>>
>>>necessarily
>>>
>>>
>>>
>>>
>>>>alter RAM. A PUC is generated by the following events, as outlined in
>>>>the UG.
>>>>
>>>>1 A POR. In which case I would not trust the contents of RAM. POR
>>>>
>>>>
>>>>
>>>>
>>>can be
>>>
>>>
>>>
>>>
>>>>caused by:-
>>>>a Powering on the device, when RAM is indeterminate.
>>>>b A Low signal on RST if set for reset mode. RAM may be
>>>>indeterminate
>>>>c A low power condition with PORON set. RAM cannot be trusted
>>>>d Unless specifically handled by user ISRs the NMI_ISR will
>>>>usually ultimately result in the system hanging in an
>>>>unknown state. If all the user does is effectively an RETI for the
>>>>
>>>>
>NMI
>>>>then the same will usually occur eventually.
>>>>2 Watchdog timer expiry, if enabled. this will normally leave RAM
>>>>unaltered.
>>>>3 Watchdog Timer security key violation. this si NOT the same as
>>>>
>>>>
>>>>
>>>>
>>>above,
>>>
>>>
>>>
>>>
>>>>Why didi this occur? Typically because the program is bugged and
>>>>
>>>>
>access
>>>>to the watchdog control registers has been attempted
>>>>
>>>>
>>>>
>>>>
>>>unintentionally, as
>>>
>>>
>>>
>>>
>>>>the reslt of a bug. Do not trust RAM.
>>>>4 Flash memory security key violation. Again do not truat the system
>>>>after this has occurred. Your NMI( should try and determine the
>>>>
>>>>
>>>>
>>>>
>>>cause of
>>>
>>>
>>>
>>>
>>>>this, or, if possible log the last few bytes of Stack.
>>>>5 CPU instruction fetch from peripheral memory. Again this only
>>>>
>>>>
>occurs
>>>>if there is a serious bug in the system, or something has become
>>>>corrupted, so don't trust RAM.
>>>>
>>>>Cheers
>>>>
>>>>Al
>>>>Aaron Greer wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Al,
>>>>>I'm not sure I understand your opinion on PUC. I'm not worried
>>>>>
>>>>>
>>>>>
>>>>>
>>>about POR, only PUC.
>>>
>>>
>>>
>>>
>>>>>Neglecting any RAM mods made by C initializing code, does RAM get
>>>>>
>>>>>
>>>>>
>>>>>
>>>modified by PUC?
>>>
>>>
>>>
>>>
>>>>>thanks,
>>>>>Aaron
>>>>>
>>>>>----- Original Message -----
>>>>>From: "One Stone"
>>>>>To: m...
>>>>>Sent: Wednesday, January 9, 2008 5:02:03 PM (GMT-0700)
>>>>>
>>>>>
>America/Denver
>>>>>Subject: Re: [msp430] Re: status of RAM after PUC
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Although PUC itself does NOT change the contents of RAM, you cannot
>>>>>assume that the RAM has NOT changed. You can determine the cause of
>>>>>
>>>>>
>>>>>
>>>>>
>>>the
>>>
>>>
>>>
>>>
>>>>>POR, and make a reasonable guess on the RAM status, based on the
>>>>>likelihood of Vcc dropping. If it is unlikley that the POR was
>>>>>
>>>>>
>>>>>
>>>>>
>>>caused by
>>>
>>>
>>>
>>>
>>>>>or resulted in a drop in Vcc below the RAM maintenance voltage you
>>>>>
>>>>>
>>>>>
>>>>>
>>>could
>>>
>>>
>>>
>>>
>>>>>reasonably assume that RAM remained unchanged. However thereare no
>>>>>guarantees. To do this you MUST handle all ISRs, including false
>>>>>
>>>>>
>ones,
>>>>>and ensure that your ISRs record failure modes, if they are not
>>>>>
>>>>>
>>>>>
>>>>>
>>>recoverable.
>>>
>>>
>>>
>>>
>>>>>Generally speaking I wouldn't rely on the RAm status after POR.
>>>>>
>>>>>Al
>>>>>
>>>>>old_cow_yellow wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>PUC does not change the contents of RAM.
>>>>>>The CPU could change the contents of the RAM afterwards.
>>>>>>If you use c, for example, the c startup code does that.
>>>>>>
>>>>>>--- In m... , Aaron Greer wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Does anyone know what the status of RAM variables should be
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>immediately after a PUC?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Specifically, I'm wondering about absolutely-located global
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>variables declared with __no_init.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Are they supposed to retain their state, are they cleared, or are
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>they indeterminate?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>thanks,
>>>>>>>Aaron
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Start a New Thread

--- In m..., Aaron Greer wrote:
> ...
> I haven't been doing this for 40 years yet, but I'm not really
> a novice either. Any suggestions?
> ...

In 40 years, there is a chance that a cluster of cosmic ray particles
may hit some of the transistors inside the chip simultaneously. And
this may cause the RAM to change or the CPU to crash ;-) Start a New Thread

Look at the studies by Intel, IBM et al, and you will find that the risk
of this increases with the number of devices fielded. So, even on your
figure of once every 40 years I have 40,000 devices deployed I can
expect 3 failures a day. In fact IIRC thereal numbers aremuch worse than
this. However a more common occurrence may be the proximity of high
voltage/current machinery nxt to a battery system that isn't truly
grounded. And yes, I do try to compensate for this in every system I
design, it isn't as trivial as people seem to think.

Al

old_cow_yellow wrote:

>--- In m..., Aaron Greer wrote:
>
>
>>...
>>I haven't been doing this for 40 years yet, but I'm not really
>>a novice either. Any suggestions?
>>...
>>
>>In 40 years, there is a chance that a cluster of cosmic ray particles
>may hit some of the transistors inside the chip simultaneously. And
>this may cause the RAM to change or the CPU to crash ;-)
> Start a New Thread

Well Aaron, without knowing what you are trying to achieve, and you're
welcome to email me directly, I can't really be in a position to advise
other than generally. i can say this though.

I have been using the 2012 and 2013 since pre-release, around 2 years
ago, I use the USI to control a CC1100 via SPI. A fairly complex process
in itself. Although the Cc1100 has plenty of issues I have so far had no
problems whatsoever with the SPI interface. These too are systems
designed to operate for extended periods, and are squeezing every last
ounce of processing capability out of the device.

Al

Aaron Greer wrote:

>Trust me, if I could think of a way to accomplish what I need to without the watchdog reset, I would.
>I'm doing a fairly complex design using a pretty cut-rate part (F2012). The USI/I2C hardware pretty much sucks and it gets stuck periodically for various reasons. I use the watchdog to get unstuck. I'm using almost all of my available resources and this has been the most compact and reliable method so far.
>I haven't been doing this for 40 years yet, but I'm not really a novice either. Any suggestions?
>
>-Aaron
>
>----- Original Message -----
>From: "One Stone"
>To: m...
>Sent: Thursday, January 10, 2008 11:22:16 AM (GMT-0700) America/Denver
>Subject: Re: [msp430] Re: status of RAM after PUC
>
>AS I thought, using the PUC data to cleanly power up, but why on earth
>do you feel the need to to reset periodically!! That throws me
>completely. I have systems that have been running since 1998 without
>ever being reset, powered down or anything else. I've been around this
>game for nearly 40 years and can't imagine a non-failure mode that would
>make this desirable. I would appreciate enlightenment?
>
>Cheers
>
>Al
>
>Aaron Greer wrote:
>
>
>
>>Thanks for all of your replies to my original question.
>>
>>In my application, I let the watchdog reset the device (PUC) periodically. I was just looking for a convenient (non-Flash) method to retain some state information across PUC events. I have no need to retain information across power cycles or RST conditions. Immediately after reset, my code checks the reset flags to determine the cause and then intelligently initializes (or not) the appropriate globals and SFR bits.
>>
>>thanks again,
>>Aaron
>>----- Original Message -----
>>From: "tintronic" < m...@elboldo.cl >
>>To: m...
>>Sent: Thursday, January 10, 2008 10:53:59 AM (GMT-0700) America/Denver
>>Subject: [msp430] Re: status of RAM after PUC
>>
>>__no_init variables retain their values after a PUC. Period.
>>Why the PUC happened and the implications on the variables is another
>>matter entirely.
>>
>>"...and since several of the failure modes that generate PUC without
>>POR are the result of events which place the contents of RAM at risk
>>you cannot rely upon the contents of RAM..."
>>Let's see. Events that trigger PUC without POR (extracted from the
>>datasheed):
>>1) Watchdog timer expiration when in watchdog mode only
>>2) Watchdog timer security key violation
>>3) A Flash memory security key violation
>>
>>None of this events put ram contents at risk. If the PUC was generated
>>by a bad programming that's a different story. Then you can't trust
>>the contents of RAM with or without PUC. I've seen treads where peoply
>>intently make an illegal write to the watchdog register to generate a PUC.
>>
>>I'm just answering the question that was asked, without making an
>>assumption on why the PUC generates or why he would need to preserve
>>the value of a variable after a PUC but not a POR (or else he'd be
>>using info-flash or an external EEPROM).
>>
>>I'm not assuming his program is wrong. He is not asking for help with
>>undesired or unplanned PUCs, he just wants to know if __no_init
>>variables retain their state after a PUC. Nothing more, nothing less.
>>
>>Michael Kusch.
>>
>>--- In m... , One Stone wrote:
>>
>>
>>>This is a very stunted view of the process. Since a PUC is generated by
>>>a POR you cannot simply divorce them, and since several of the failure
>>>modes that generate PUC without POR are the result of events which
>>>place the contents of RAM at risk you cannot rely upon the contents of
>>>RAM without a full understanding of the failure modes. You have taken a
>>>purely C centric view. C is divorced from the hardware, and has nothing
>>>to do with POR or PUC.
>>>
>>>In badly written software the normal course may be to simply blow
>>>through the initialisation procedures as if a start up was occurring,
>>>but well written software should try to analyse the failure means,
>>>
>>>
>>>
>>>
>>since
>>
>>
>>>no 'normal' event should ever see a PUC or POR occur. Not all systems
>>>can afford to simply reset. Down that path dies potential disaster.
>>>
>>>
>>>
>>>
>>Many
>>
>>
>>>systems must, at the very least, try and recover sequencing data, like
>>>time, or current machine state, while many systems need to recover from
>>>different failure modes in different ways.
>>>
>>>Al
>>>
>>>tintronic wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Let's make a long story short: The question was about PUC, not POR.
>>>>That's a hardware related question.
>>>>After PUC, __no_init variables retain their values. That's the answer.
>>>>
>>>>
>>>>The explanation:
>>>>PUC is a hardware signal that does NOT clear RAM. It initializes
>>>>various registers, but doesn't touch data RAM.
>>>>
>>>>Follow up question: What does the software do after a PUC?
>>>>After PUC (and therefore POR too) there is normally a software
>>>>initialization which clears and sets the memory location for each of
>>>>the declared global variables UNLESS the variable is declared as
>>>>__no_init. These value will not be changed.
>>>>
>>>>A useful comment:
>>>>POR doesn't clear RAM either. There are only two events who
>>>>
>>>>
>>>>
>>>>
>>generate POR:
>>
>>
>>>>1) RST pin: Any __no_init variable retains its value.
>>>>2a) Device Power Up: RAM is filled with garbage.
>>>>2b) If device has BOR(which replaces POR): RAM values are not to be
>>>>trustet due to a too low Vcc, below its ability to retain RAM data.
>>>>
>>>>Best Regards,
>>>>Michael Kusch
>>>>--- In m... , One Stone wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Ok. A PUC is ALWAYS generated by a POR, but a POR is not always
>>>>>generated by a PUC. Certain things that cause a PUC will not
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>necessarily
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>alter RAM. A PUC is generated by the following events, as outlined in
>>>>>the UG.
>>>>>
>>>>>1 A POR. In which case I would not trust the contents of RAM. POR
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>can be
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>caused by:-
>>>>>a Powering on the device, when RAM is indeterminate.
>>>>>b A Low signal on RST if set for reset mode. RAM may be
>>>>>indeterminate
>>>>>c A low power condition with PORON set. RAM cannot be trusted
>>>>>d Unless specifically handled by user ISRs the NMI_ISR will
>>>>>usually ultimately result in the system hanging in an
>>>>>unknown state. If all the user does is effectively an RETI for the
>>>>>
>>>>>
>>>>>
>>>>>
>>NMI
>>
>>
>>>>>then the same will usually occur eventually.
>>>>>2 Watchdog timer expiry, if enabled. this will normally leave RAM
>>>>>unaltered.
>>>>>3 Watchdog Timer security key violation. this si NOT the same as
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>above,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Why didi this occur? Typically because the program is bugged and
>>>>>
>>>>>
>>>>>
>>>>>
>>access
>>
>>
>>>>>to the watchdog control registers has been attempted
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>unintentionally, as
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>the reslt of a bug. Do not trust RAM.
>>>>>4 Flash memory security key violation. Again do not truat the system
>>>>>after this has occurred. Your NMI( should try and determine the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>cause of
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>this, or, if possible log the last few bytes of Stack.
>>>>>5 CPU instruction fetch from peripheral memory. Again this only
>>>>>
>>>>>
>>>>>
>>>>>
>>occurs
>>
>>
>>>>>if there is a serious bug in the system, or something has become
>>>>>corrupted, so don't trust RAM.
>>>>>
>>>>>Cheers
>>>>>
>>>>>Al
>>>>>Aaron Greer wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Al,
>>>>>>I'm not sure I understand your opinion on PUC. I'm not worried
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>about POR, only PUC.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>Neglecting any RAM mods made by C initializing code, does RAM get
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>modified by PUC?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>thanks,
>>>>>>Aaron
>>>>>>
>>>>>>----- Original Message -----
>>>>>>From: "One Stone"
>>>>>>To: m...
>>>>>>Sent: Wednesday, January 9, 2008 5:02:03 PM (GMT-0700)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>America/Denver
>>
>>
>>>>>>Subject: Re: [msp430] Re: status of RAM after PUC
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>Although PUC itself does NOT change the contents of RAM, you cannot
>>>>>>assume that the RAM has NOT changed. You can determine the cause of
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>POR, and make a reasonable guess on the RAM status, based on the
>>>>>>likelihood of Vcc dropping. If it is unlikley that the POR was
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>caused by
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>or resulted in a drop in Vcc below the RAM maintenance voltage you
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>could
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>reasonably assume that RAM remained unchanged. However thereare no
>>>>>>guarantees. To do this you MUST handle all ISRs, including false
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>ones,
>>
>>
>>>>>>and ensure that your ISRs record failure modes, if they are not
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>recoverable.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>Generally speaking I wouldn't rely on the RAm status after POR.
>>>>>>
>>>>>>Al
>>>>>>
>>>>>>old_cow_yellow wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>PUC does not change the contents of RAM.
>>>>>>>The CPU could change the contents of the RAM afterwards.
>>>>>>>If you use c, for example, the c startup code does that.
>>>>>>>
>>>>>>>--- In m... , Aaron Greer wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Does anyone know what the status of RAM variables should be
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>immediately after a PUC?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Specifically, I'm wondering about absolutely-located global
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>variables declared with __no_init.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Are they supposed to retain their state, are they cleared, or are
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>they indeterminate?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>thanks,
>>>>>>>>Aaron
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Start a New Thread

Hi Aaron,

> Any suggestions?

Have you looked at using a state machine ?
These can be extremely helpful in situations like yours (error handling in all sorts of
protocols). The advantage is that you can control from a dispatcher, which in turn looks at which
state you're in and then jumps to that state.
The first advantage is that you only need one watchdog clear command (if SW watchdog there should
be as little as possible WDT instructions).
Things like delays can still go through the dispatcher so you don't time out on WDT, and you don't
have WDT instructions littered all over the place.
Once the proper states have been designated, it is very easy to recover from any error with USI
w/o an intentional reset (unless the USI specifically needs a warm MCU reset of course).
Should you still need a 'forced reset' all you need to do is add on an extra state - it doesn't
affect your system design.

Al made a good point too, but I think that it still always pays to consider that C can be as low
level, medium level or as high level as you want. That's what I love about C.

Best Regards,
Kris

-----Original Message-----
From: m... [mailto:m...] On Behalf Of Aaron Greer
Sent: Friday, 11 January 2008 5:31 AM
To: m...
Subject: Re: [msp430] Re: status of RAM after PUC

Trust me, if I could think of a way to accomplish what I need to without the watchdog reset, I
would.
I'm doing a fairly complex design using a pretty cut-rate part (F2012). The USI/I2C hardware
pretty much sucks and it gets stuck periodically for various reasons. I use the watchdog to get
unstuck. I'm using almost all of my available resources and this has been the most compact and
reliable method so far.
I haven't been doing this for 40 years yet, but I'm not really a novice either. Any suggestions?

-Aaron Start a New Thread