Lpc2000

At 10:04 AM 1/27/04 -0500, you wrote:
> >>them during worst-case usage testing, if possible. Sometimes I add
> >>to my watchdog-kicking code that checks for pre-RTL-init signature
>
> > Incidentally... I've seen watchdog timer reload code in interrupt
> > handlers, but for the reason I've mentioned above that may not
> > protect against dead application code. Isn't it better to reload the
> > watchdog timer at strategic points in the application? That way, the
>
>The care and feeding of watchdogs is a topic of many PhDs. The "correct"
>approach depends on the application and the hardware's idiosyncrasies.
>However, a couple of things:
>
>1. I didn't actually say above that I was kicking the dog in an ISR,
>though it might have sounded that way :)
>
>2. One method I have used with tolerable success [depends on being able
>to analyze relative task time requirements] is to have a short buffer
>(size depends on number of concurrent tasks) and a timestamp variable. I
>code each task so that at an "appropriate" juncture (i.e. not in an
>inner loop), it acquires a semaphore controlling access to the variables
>aforementioned.  It places the current time in the timestamp variable,
>and adds a task ID byte to the head of the buffer, pushing down the
>remaining contents. It then releases the semaphore.

<snip>
Sounds very similar to a technique I have used in the past.  In my case 
like your the watchdog was serviced in a timer interrupt and that interrupt 
used additional data to watch the health of the system.

I was usually running several control loops and each loop would set an ECC 
protected value when it ran.  This data would contain a timeout period for 
that loop.  The timer interrupt would count down each ECC protected value 
and stop resetting the watchdog if any one of them reached 0.  To allow 
startup to proceed w/o incident the loop data could exist in two states 
-'not started' and 'running' with no mechanism provided to shut them down 
(turning them on was just a matter of performing the normal update on them).

This manages to protect against
         - Timer interrupt failure (rare but I have seen it happen, usually 
because someone created a section of code that left interrupts completely 
disabled)
         - memory overwrites.  These would invalidate the ECC code and 
trigger an immediate reset.
         - loop failures or loops taking too long to complete.

What they didn't provide, however, was the capability to log the failing 
task.  I generally only had a few bytes of non-volatile memory available 
for that error logging anyway and often the time to guarantee a write would 
exceed the watchdog period.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III