Lpc2000

>>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.

An ISR checks the buffer to make sure that it contains a signature for 
every known task, and no unknown task [which would mean memory 
corruption]. It also checks that the timestamp is "reasonably 
up-to-date", by which I usually mean 10x-20x the operating system's 
scheduler tick. That multiplier might be altered if there are device 
drivers that evilly take long timeslices away from normal tasks. If both 
these conditions are satisfied, the WDT is kicked. If one or both are 
unsatisfied, the ISR writes the event to the device log and returns 
without kicking the dog. This gives the system a second bite at the 
cherry to recover the dead task (but now the WDT is growling). 
Optionally, a supervisory task could see the "task 1234 suspected dead" 
log entry and kill/restart the task. But if the system doesn't normalize 
within the WDT's expiry time, it will reboot.

If one task dies, it will stop putting its ID into the buffer, and that 
ID will soon cycle out as other tasks displace it ->WDT reset. If 
something evil happens and all tasks block on the watchdog buffer 
semaphore, the timestamp freezes and the ISR assumes gross system 
failure and explicitly halts to wait for the dog to bite.

  --
  -- Lewin A.R.W. Edwards (http://www.zws.com/)
Learn how to develop high-end embedded systems on a tight budget!
http://www.amazon.com/exec/obidos/ASIN/0750676094/zws-20