Lpc2000

Ake Hedman, eurosource wrote:

>OK Guys,
>
>I can confirm that the WD problem is solved in my case. Thanks a lot 
>all!  (Description of solution below.)
>
>I think this definitely should be mentioned in the err data sheets for 
>the affected processors (or clearly in the UM)  as the resulting 
>symptoms are such that the problem is very hard to debug..
>
>Cheers
>/Ake
>
>
>How I solved it:
>
>I have replaced all dog-feeds with
>
>        mycpsr = disableIRQ();
>        WDFEED = 0xAA; WDFEED = 0x55;
>        restoreIRQ( mycpsr );
>
>where disableIRQ and restoreIRQ is from R O Software
>
>  
>

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


Regards,

TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------