Lpc2000

Robert,

Thanks for the reference to the watchdog paper - I hadn't seen it 
before, and it's certainly very good i/p to watchdog design.

I'd agree with the argument that to be really robust, you need to 
consider more than just an on-board watchdog with something giving it 
a feed now and then.

Tom: putting together a system where the background does half the 
watchdig task, and interrupts the other is a good idea in principle. 
However, it does need careful thought as to the detail: I have seen 
such a scheme fail: the watchdog needed to toggle a pin to be fed. 
The main (system) loop put the pin one way and a timer interrupt put 
it another. The problem was the system could get into a state (after 
a very heavy burst of RF noise) where the watchdog was being fed, but 
the system was effectively dead as not much else was running.

Jack Ganssle's paper gives one way out of this (a supervisory task 
monitoring the health of all other tasks). There are alternatives. 
For example, we have a watchdog message passed from one active task 
to the other (if it's in a happy state): if it reaches the watchdog 
task, the watchdog gets set (from one and only one location that's 
not in a loop). A new message is then generated by the watchdog task 
with a one second delay. In other words, for the watchdog to be fed, 
all the system's tasks/components have to be in a "happy" state, task 
scheduling, timers etc. all have to be working. It's really down to 
balance between what gives good coverage to complexity of 
implementation etc.

For what it's worth, my own view is:

- the LPC2000 watchdog is fine for an on-board watchdog (with 
corrected documentation!)

- to detect all failures, you have to go to an off-chip watchdog (or 
at least one that doesn't use ANY shared component - in particular 
the clock)

- you need to put some thought into the software to drive it: simple 
minded implementations will give better than nothing, but can be 
greatly imrpoved on

- try not to feed a watchdog from a software loop: there's a chance a 
wayword processor will end up in that loop

- the AA, 55 (or similar) feed sequence is better than the 
alternative of not having one (but not by much!)

Brendan

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
>
> At 01:09 AM 12/11/05 -0500, Tom Walsh wrote:
> >I've been following this thread with interest as I expected to use 
the
> >watchdog in my application.  The old design used a MAX690 where you
> >would toggle the input to keep the watchdog happy.  This worked 
well for
> >us as the foreground software would set the pin high and the 
interrupt
> >routines would reset it low.  This ensured that both sections of 
the
> >program were operating okay.  Foreground did non-time-critical 
tasks
> >while the background serviced realtime critical tasks & 
communications
> >over RS485.
> >
> >I had expected to do something similar with the LPC2000 parts.  
Feed the
> >watchdog with 0xaa from the interrupt layer and then feed it with 
0x55
> >from the foreground.  It was expected that even if the watchdog 
received
> >something like this, it would still be fine:
> >
> >0xaa, 0xaa, 0xaa, 0x55, 0xaa, 0xaa, 0xaa, 0xaa, 0x55 ....
> >
> >
> >What value is a watchdog that requires you to carefully feed it, it
> >sounds as if the watchdog is very fragile?
> 
> 
> Actually, that is rather the point.  The idea is to prevent being 
able to 
> accidentally satisfy the watchdog with writes from multiple places 
in the 
> program.  Watchdogs are supposed to be somewhat twitchy.  Even so 
an 
> internal watchdog doesn't usually catch events like loss of 
> oscillator.  The Philips watchdog also appears to allow the trip 
time to be 
> reprogrammed during operation which is a big weakness.
> 
> BTW this is not an unusual requirement for microcontroller based 
watchdogs, 
> at least in my experience.
> 
> You may find (if you haven't read it already) Jack Ganssle's 
article on 
> watchdogs interesting.  http://www.ganssle.com/watchdogs.pdf
> 
> 
> 
> >I noticed that Philips
> >Applications people studiously stayed out of this thread about the
> >watchdog!  I suspect that the watchdog is severly broken and they 
did
> >not want to comment on it?
> 
> Actually, from these accounts the watchdog is fine.  The 
documentation 
> needs to be updated though.  The line referring the watchdog 
register space 
> probably needs to be updated to match the wording used for the 
PLLFEED 
> register which explicitly refers to back to back VPB writes being 
> needed.  I expect the two peripherals are using identical logic.
> 
> I wouldn't mind that period hole being fixed though, and maybe even 
seeing 
> a minimum time between feeds enforced.
> 
> 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/
>