Lpc2000

Interesting...

> Sounds very similar to a technique I have used in the past.  In my case 

I can't claim to have invented it, but I used this method for the first 
time in some code running on a Z-80 system, probably developed in 1989? 
I know I was talking to a lot of my mentors (other teenagers :) at the 
time, it wasn't an independently developed idea.

> 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 

I didn't think of the ECC protection, I should definitely add more 
protection of this sort to the task buffer.

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

I didn't really start to refine my technique until I started working on 
my submarine. In this case it is very interesting to me to know what 
tasks are failing and why. If the system gets launched with buggy 
software, it will only be money being lost, but it's MY money, which 
makes it much more important ;) Anyway, I really need every possible 
byte of health info to be logged.

The board on which this WDT code I've been talking about is running is 
an x86-based SBC (once the design is refined, this board will be 
replaced with something ARM, probably a custom board). This SBC is 
onboard to do "heavy lifting" tasks (machine vision, bulk storage of 
image and audio data, etc) and tasks that are complicated to do on 
microcontrollers (USB camera interface, 802.11b networking). These are 
all tasks that are really hard to prototype quickly, and also hard to 
estimate CPU requirements for. So it's much easier to buy off-the-shelf 
consumer parts, use an overkill CPU, and see how it performs. Then, ONLY 
once you have a good idea of actual cycles-n-bytes system requirements, 
you can build an optimized custom circuit. The problem is, a lot of 
these drivers and support tasks are subject to intermittent failure. 
(802.11b drivers in particular - if the signal fluctuates, you often 
need to unload the driver and reset the hardware).

The sub is actually driven by an ATmega128, which has an RS232 link to 
the above SBC, a second RS232 link to a GPS rxvr, and an SPI link to 
various peripherals (propulsion motor controllers, accelerometer, 
stepper motor controllers, power management module, etc etc; all of 
these have individual AVR microcontrollers - again, this is an 
ease-of-prototyping thing).

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