That is what I did to disable the interrupts.

From: l... [mailto:l...] On Behalf Of
Ken Everett
Sent: Monday, September 29, 2008 4:05 PM
To: l...
Subject: RE: [lpc2000] Watchdog problem

How are you disabling interrupts from user mode?

Using a SWI ?

From: l...
[mailto:l... ] On
Behalf
Of m...@governors-america.com
Sent: 26 September 2008 17:00
To: l...
Subject: Re: [lpc2000] Watchdog problem

Here is a little tip that does not seem to be documented anywhere and if

it is not followed the watch dog does not operate correctly. Interrupts
must be disabled before you can feed the watchdog (WDFEED = 0xAA; WDFEED
0x55), if you do not disable interrupts before this feed the watchdog
does
not get reset correctly causing it to trigger and resets the processor.
Just simply disable interrupts, feed the watchdog 0xAA then 0x55,
re-enable the interrupts and continue on.

Goof Luck,
Mike

An Engineer's Guide to the LPC2100 Series

On Mon, 29 Sep 2008 12:19:49 +0200, you wrote:

>How are you disabling interrupts from user mode?

Why would you be in User mode?

>Using a SWI ?
>Here is a little tip that does not seem to be documented anywhere and if

The problem is that in the UM's I've read, the description is wrong - it says that IO accesses
between FEEDs in the WDT area cause a reset, where what it should say is that any access in any IO
areas (Except FIO I think) causes a reset.
As interrupt routines will generally access IO space, this means that you effectively have to either
disable ints when kicking the dog, or synchronise WDT resets with known interrupt timing.

This is clearly an implementation screwup - what they should have done is implement it as it is
described int some of the UMs - only have incorrect accesses within the WDTs address space cause a
reset.
The way they have done it makes no sense and can cause significant problems in systems that need
guaranteed response times to FIQs.

I believe it was because the watchdog did not get the two feeds
sequentially (because an interrupt hit in between) so it flagged it as a
fault and set the watchdog off.

Mike

How are you disabling interrupts from user mode?

Using a SWI ?

From: l... [mailto:l...] On Behalf
Of m...@governors-america.com
Sent: 26 September 2008 17:00
To: l...
Subject: Re: [lpc2000] Watchdog problem

Here is a little tip that does not seem to be documented anywhere and if

it is not followed the watch dog does not operate correctly. Interrupts
must be disabled before you can feed the watchdog (WDFEED = 0xAA; WDFEED
0x55), if you do not disable interrupts before this feed the watchdog
does
not get reset correctly causing it to trigger and resets the processor.
Just simply disable interrupts, feed the watchdog 0xAA then 0x55,
re-enable the interrupts and continue on.

Goof Luck,
Mike

Hi
Thanks,
i moved the feed to an SWI function and that works now.

I still don't understand why it did reset almost immediate regardeless tha fact i did init WDTC to 30 seconds.

Johan

----- Original Message -----
From: Nishant Agrawal
To: l...
Sent: Friday, September 26, 2008 6:10 AM
Subject: RE: [lpc2000] Re: Watchdog problem
The thing with watchdog is that none of the peripherals are to be accessed
in between the feeds of 0xAA and 0x55, not even VIC. If accessed, the system
resets. So better if you do the watchdog feed in supervisor mode, software
interrupt, that way none of the interrupts will be able to disturb the feed

From: l... [mailto:l...] On Behalf Of
tcirobot
Sent: Friday, September 26, 2008 5:30 AM
To: l...
Subject: [lpc2000] Re: Watchdog problem

--- In l... , "Helge
Fabricius-Hansen"
wrote:
>
> Hi!
>
> I tried to use the watchdog, but it looks like I can't set a long
> timeout or it ignores my kicking.
> I am getting a reset right away...
>
>
> WDTC = 7500000L; // Set for ca. 2 seconds at 60 MHz and devide by 4
> WDMOD = 0x03;
>
> while(1)
> {
> WDFEED = 0xAA; WDFEED = 0x55;
> bla.
> bla.
> etc.
>
> // looptime not more then 10 ms
>
> }
>
> Anyone with a clue?
>
> //Helge
>

Last year I tried using the watchdog in the LPC2103. I was unable to
get it to function for the time interval I desired (for unresolved
reasons). However, I did find that it would function at the minimum
value (and reset the LPC2103 as expected).

Here are a few notes from that experiment:

1) there is a hard-wired minimum value of 0xFF
2) this yeilds a minumum N+1 timer value of 0x100
3) there is a fixed pre-scaler that divides Pclk by 4
4) the end result is a 256 * 4 * Pclk_period minimum watchdog

The code basically did the following...

write 0xFF to WDTC
write 0x03 to WDMOD
write 0xAA to WDFEED
write 0x55 to WDFEED

This did work reliably.

TC

--- In l..., mfrazier@... wrote:
>
> Here is a little tip that does not seem to be documented anywhere
and if
> it is not followed the watch dog does not operate correctly.
Interrupts
> must be disabled before you can feed the watchdog (WDFEED = 0xAA;
WDFEED > 0x55

See the NXP application note AN10414 'Handling of Spurious
Interrupts in the LPC2000'.

--
Chris Burrows
Armaide: Oberon-07 for ARM Development System
http://www.armaide.com

Here is a little tip that does not seem to be documented anywhere and if
it is not followed the watch dog does not operate correctly. Interrupts
must be disabled before you can feed the watchdog (WDFEED = 0xAA; WDFEED 0x55), if you do not disable interrupts before this feed the watchdog does
not get reset correctly causing it to trigger and resets the processor.
Just simply disable interrupts, feed the watchdog 0xAA then 0x55,
re-enable the interrupts and continue on.

Goof Luck,
Mike

The thing with watchdog is that none of the peripherals are to be accessed
in between the feeds of 0xAA and 0x55, not even VIC. If accessed, the system
resets. So better if you do the watchdog feed in supervisor mode, software
interrupt, that way none of the interrupts will be able to disturb the feed

From: l... [mailto:l...] On Behalf Of
tcirobot
Sent: Friday, September 26, 2008 5:30 AM
To: l...
Subject: [lpc2000] Re: Watchdog problem

--- In l... , "Helge
Fabricius-Hansen"
wrote:
>
> Hi!
>
> I tried to use the watchdog, but it looks like I can't set a long
> timeout or it ignores my kicking.
> I am getting a reset right away...
> WDTC = 7500000L; // Set for ca. 2 seconds at 60 MHz and devide by 4
> WDMOD = 0x03;
>
> while(1)
> {
> WDFEED = 0xAA; WDFEED = 0x55;
> bla.
> bla.
> etc.
>
> // looptime not more then 10 ms
>
> }
>
> Anyone with a clue?
>
> //Helge
>

Last year I tried using the watchdog in the LPC2103. I was unable to
get it to function for the time interval I desired (for unresolved
reasons). However, I did find that it would function at the minimum
value (and reset the LPC2103 as expected).

Here are a few notes from that experiment:

1) there is a hard-wired minimum value of 0xFF
2) this yeilds a minumum N+1 timer value of 0x100
3) there is a fixed pre-scaler that divides Pclk by 4
4) the end result is a 256 * 4 * Pclk_period minimum watchdog

The code basically did the following...

write 0xFF to WDTC
write 0x03 to WDMOD
write 0xAA to WDFEED
write 0x55 to WDFEED

This did work reliably.

TC

--- In l..., "Helge Fabricius-Hansen"
wrote:
>
> Hi!
>
> I tried to use the watchdog, but it looks like I can't set a long
> timeout or it ignores my kicking.
> I am getting a reset right away...
> WDTC = 7500000L; // Set for ca. 2 seconds at 60 MHz and devide by 4
> WDMOD = 0x03;
>
> while(1)
> {
> WDFEED = 0xAA; WDFEED = 0x55;
> bla.
> bla.
> etc.
>
> // looptime not more then 10 ms
>
> }
>
> Anyone with a clue?
>
> //Helge
>

Last year I tried using the watchdog in the LPC2103. I was unable to
get it to function for the time interval I desired (for unresolved
reasons). However, I did find that it would function at the minimum
value (and reset the LPC2103 as expected).

Here are a few notes from that experiment:

1) there is a hard-wired minimum value of 0xFF
2) this yeilds a minumum N+1 timer value of 0x100
3) there is a fixed pre-scaler that divides Pclk by 4
4) the end result is a 256 * 4 * Pclk_period minimum watchdog

The code basically did the following...

write 0xFF to WDTC
write 0x03 to WDMOD
write 0xAA to WDFEED
write 0x55 to WDFEED

This did work reliably.

TC