Anyone know how to recover the pre-interrupt values of the PC and SR
after a system reset interrupt caused by expiry of the watchdog timer?

I couldn't find any discussion of this in SLAU049D, so I did some
experimentation with the hope that a system reset interrupt would push
the PC and SR onto the stack, just as the maskable interrupts do. 
What I found is that the system reset interrupt does write the
pre-interrupt PC and SR to -2(SP) and -4(SP), respectively, but only
if the GIE bit is set.  An unset GIE bit earns me precisely nothing,
and leaves me hoping that someone out there knows something that I don't.

Noah

I haven't tried this, or found a need to do    what you want to do,
and 
the following suggestion is a bit kludgy, but, after a quick read of the 
watchdog mechanisms I couldn't immediately think of anything neater.

Instead of using the watchdog timer in watchdog mode, use it in interval 
mode. This gives you an interrupt you can use to save the SP contents 
securely (say in RAM or flash) then simply do an illegal write to WDTCTL 
to force the RESET.

Sorry, couldn't think of anything else for now.

Al

Noah Treuhaft wrote:

> Anyone know how to recover the pre-interrupt
values of the PC and SR
> after a system reset interrupt caused by expiry of the watchdog timer?
> 
> I couldn't find any discussion of this in SLAU049D, so I did some
> experimentation with the hope that a system reset interrupt would push
> the PC and SR onto the stack, just as the maskable interrupts do. 
> What I found is that the system reset interrupt does write the
> pre-interrupt PC and SR to -2(SP) and -4(SP), respectively, but only
> if the GIE bit is set.  An unset GIE bit earns me precisely nothing,
> and leaves me hoping that someone out there knows something that I
don't.
> 
> Noah
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 

Now that's lateral thinking!  Clever.

--Bruce


> Instead of using the watchdog timer in watchdog
mode, use it in interval 
> mode. This gives you an interrupt you can use to save the SP contents 
> securely (say in RAM or flash) then simply do an illegal write to WDTCTL 
> to force the RESET.

> Now that's lateral thinking!  Clever.

Indeed, but sadly the watchdog timer interrupt is maskable.  If the
processor gets wedged with interrupts disabled, it'll never reset.

Couldn't you make a similar crit of any system in which the WDT can be
disabled?

--Bruce


> Indeed, but sadly the watchdog timer interrupt is
maskable.  If the
> processor gets wedged with interrupts disabled, it'll never reset.

> Couldn't you make a similar crit of any system in which the WDT
can be
> disabled?

Not to my mind.  It's one thing to say that the watchdog can be
disabled.  But it's quite another thing to say that my software
definitely will disable it!

Noah

Thank you, the spawn of a truly warped and twisted mind! But seriously 
Noah is right, it has the drawback of failing if the timeout occurs in 
an ISR. I simply haven't been able to quickly think of anything else 
that might do the job. A solution is to make sure ISRs are very short 
and 'trusted', and to keep the watchdog reset interval well below the 
timeout interval during normal operation, since the cause of most WDT 
type failures would probably be 'lost code' or infinite loop
structures.

I'm sure somebody can come up with a better method though.

Al

Bruce Cannon wrote:

> Now that's lateral thinking!  Clever.
> 
> --Bruce
> 
> 
> 
>>Instead of using the watchdog timer in watchdog mode, use it in interval

>>mode. This gives you an interrupt you can use to save the SP contents 
>>securely (say in RAM or flash) then simply do an illegal write to WDTCTL

>>to force the RESET.
> 
> 
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
>