Lpc2000

Robert,

What you suggest sounds like a good approach: the key thing that it 
achieves is to get as much coverage as possible and minimise the risk 
of false feeds to the watchdog. The challenge, as always, is to 
balance this against complexity and time to implement.

A couple of other key ideas I'd add to the mix:

- Design the system as if there's no watchdog: if you don't do this, 
you can get into the (lazy) mode of always saying "oh, the watchdog 
will sort that out.....". This is one reason I tend to encourage 
implementing the watchdog as the last feature, and not one that the 
system depends on to do its basic function. That is, get your system 
fully functional and reliable, and then add in a watchdog (after 
fully testing it of course).

- I'd strongly agree with Jack Ganssle's paper that to be really 
effective, a watchdog must reset the processor and all its 
peripherals. I haven't come up against it on the LPC2000 series, but 
other MCUs can get some of their peripherals into various locked 
states that can only be removed by an external MCU reset (i.e. the 
CPU can't clear it by resetting the device control registers). In 
other words, a simple "jump to zero", and re-initialise peripherals 
isn't guaranteed to work. It's this kind of stuff you really only 
learn from experience (and forums like this): they don't tend to 
mention it in device data sheets for some reason.

Brendan

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
>
> At 02:57 PM 12/12/05 +0000, brendanmurphy37 wrote:
> >Jack Ganssle's paper gives one way out of this (a supervisory task
> >monitoring the health of all other tasks).
> 
> I first started using that technique about 10 years ago.  My usual 
way is 
> to have the watchdog supervisor in a periodic interrupt (sometimes 
the main 
> clock tick) watching a number of countdown watchdog timers and 
flags, one 
> of each for each task or process being monitored.  Each cycle of 
the 
> supervisor decrements the countdown timers and if none of them have 
overrun 
> feeds the watchdog.  As soon as one is no longer fed the watchdog 
no longer 
> gets fed.
> 
> As additional protection the task countdown timers are hamming 
protected so 
> overwrites are less likely to give valid results.  The flags 
usually are 
> required to have some sort of sequence or specific value (ie just 
setting 
> them to any old value is not sufficient).  As well the task timers 
are not 
> regarded as active until they have first been fed but they cannot 
be turned 
> off.
> 
> They can be made fancier from there but that is sufficient to put 
watchdogs 
> in as many periodic tasks and interrupts as you can afford the 
overhead 
> for.  In my systems that usually only amounts to a small handful 
that you 
> want to watch anyway.
> 
> 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
> http://www.aeolusdevelopment.com/
>