Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

Watch dog funnies again

Watch dog funnies again

2004-09-15 by Owen Mooney

Well - I am still having watch dog problems on the 2106 !!

I implimented the code as below. If I didn't call watchdogfeed I would
get a regular reset every 20 seconds (though I calculated it at about
1/4 seconds with 14Mhz Xtal)

I modified the code to call watchdogfeed ever 20 micro seconds or so (in
my main loop) and the processor started resetting erratically every 10
seconds or so!

Calling watchdogfeed every second has stopped this and the processor
APPEARS to be operating properly. BUT !!! if calling watchdogfeed has a
1 in 1000000 chance of resetting the processor, have I just reduced my
random resets to once per 10 days or so !

Does anyone have any knowlege of this?

Owen Mooney


void watchdogfeed(void){
WDFEED=0xAA;
WDFEED=0x55;
}

int main(void) {

...

WDTC = 0x1000000;
WDMOD= 0x03;
WDFEED=0xAA;
WDFEED=0x55;

...

}

Re: Watch dog funnies again

2004-09-17 by Mark Butcher

Hi Owen

Chance your watchdog routine as follows:

void watchdogfeed(void){
 __disable_interrupt();
 WDFEED=0xAA;
 WDFEED=0x55;
 __enable_interrupt();
}

This will almost certainly cure your problem. The reason is that the
feed sequence should not be interrupted - if you read the data sheet
carefully it is explained that an interrupted feed sequence will be
interpreted as an error and the processor resets.

If you call the watchdog without protection more frequently the chance
of an interrupt arriving between the two instructions increases and
would explain your observations.

If this works you can buy me a beer one day.

Cheers

Mark Butcher

www.mjbc.ch




--- In lpc2000@yahoogroups.com, Owen Mooney <ojm@s...> wrote:
Show quoted textHide quoted text
> Well - I am still having watch dog problems on the 2106 !!
> 
> I implimented the code as below. If I didn't call watchdogfeed I would
> get a regular reset every 20 seconds (though I calculated it at about
> 1/4 seconds with 14Mhz Xtal)
> 
> I modified the code to call watchdogfeed ever 20 micro seconds or so (in
> my main loop) and the processor started resetting erratically every 10
> seconds or so!
> 
> Calling watchdogfeed every second has stopped this and the processor
> APPEARS to be operating properly. BUT !!! if calling watchdogfeed has a
> 1 in 1000000 chance of resetting the processor, have I just reduced my
> random resets to once per 10 days or so !
> 
> Does anyone have any knowlege of this?
> 
> Owen Mooney
> 
> 
> void watchdogfeed(void){
> WDFEED=0xAA;
> WDFEED=0x55;
> }
> 
> int main(void) {
> 
> ...
> 
> WDTC = 0x1000000;
> WDMOD= 0x03;
> WDFEED=0xAA;
> WDFEED=0x55;
> 
> ...
> 
> }

Re: Watch dog funnies again

2004-09-18 by lpc2100

This solution will cure problem only if an ISR is doing a write to 
the WD register space.

Tom

excerpt from the UM

Watchdog Feed Register (WDFEED - 0xE0000008)

Writing 0xAA followed by 0x55 to this register will reload the 
Watchdog timer to the WDTC value. This operation will also start
the Watchdog if it is enabled via the WDMOD register. Setting the 
WDEN bit in the WDMOD register is not sufficient to
enable the Watchdog. A valid feed sequence must first be completed 
before the Watchdog is capable of generating an interrupt/
reset. Until then, the Watchdog will ignore feed errors. Once 0xAA is 
written to the WDFEED register the next operation in the
Watchdog register space should be a WRITE (0x55) to the WDFFED 
register otherwise the Watchdog is triggered. The interrupt/
reset will be generated during the second pclk following an incorrect 
access to a watchdog timer register during a feed sequence.


--- In lpc2000@yahoogroups.com, "Mark Butcher" <mjbcswitzerland@y...> 
wrote:
> Hi Owen
> 
> Chance your watchdog routine as follows:
> 
> void watchdogfeed(void){
>  __disable_interrupt();
>  WDFEED=0xAA;
>  WDFEED=0x55;
>  __enable_interrupt();
> }
> 
> This will almost certainly cure your problem. The reason is that the
> feed sequence should not be interrupted - if you read the data sheet
> carefully it is explained that an interrupted feed sequence will be
> interpreted as an error and the processor resets.
> 
> If you call the watchdog without protection more frequently the 
chance
> of an interrupt arriving between the two instructions increases and
> would explain your observations.
> 
> If this works you can buy me a beer one day.
> 
> Cheers
> 
> Mark Butcher
> 
> www.mjbc.ch
> 
> 
> 
> 
> --- In lpc2000@yahoogroups.com, Owen Mooney <ojm@s...> wrote:
> > Well - I am still having watch dog problems on the 2106 !!
> > 
> > I implimented the code as below. If I didn't call watchdogfeed I 
would
> > get a regular reset every 20 seconds (though I calculated it at 
about
> > 1/4 seconds with 14Mhz Xtal)
> > 
> > I modified the code to call watchdogfeed ever 20 micro seconds or 
so (in
> > my main loop) and the processor started resetting erratically 
every 10
> > seconds or so!
> > 
> > Calling watchdogfeed every second has stopped this and the 
processor
> > APPEARS to be operating properly. BUT !!! if calling watchdogfeed 
has a
> > 1 in 1000000 chance of resetting the processor, have I just 
reduced my
Show quoted textHide quoted text
> > random resets to once per 10 days or so !
> > 
> > Does anyone have any knowlege of this?
> > 
> > Owen Mooney
> > 
> > 
> > void watchdogfeed(void){
> > WDFEED=0xAA;
> > WDFEED=0x55;
> > }
> > 
> > int main(void) {
> > 
> > ...
> > 
> > WDTC = 0x1000000;
> > WDMOD= 0x03;
> > WDFEED=0xAA;
> > WDFEED=0x55;
> > 
> > ...
> > 
> > }

Re: [lpc2000] Re: Watch dog funnies again

2004-09-18 by Robert Adsett

At 12:39 AM 9/18/04 +0000, you wrote:
>This solution will cure problem only if an ISR is doing a write to
>the WD register space.

On the other hand the PLL, which uses the same feed sequence,  explicitly 
states in its documentation that the two write must be on consecutive VPB 
bus cycles.  Perhaps the Watchdog documentation is wrong?

It might be worth a quick try to see if it had any effect.  If it did then 
it would be time to beg for clarification from Philips.

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

Re: Watch dog funnies again

2004-09-20 by Mark Butcher

I also had a problem with the watchdog. When I was sending large 
amounts of data over the serial port (lots of character interrupts) 
the card would sporadically crash and the watchdog register 
indicated it due to the watchdog.

Checking the data sheet I noted that the watchdog feed sequence was 
important but didn't notice that it was only a restriction in 
Watchdog register space accesses (0xE0000000 .. 0xE000000C).

In any case I protected the feed sequence from interrupts and have 
never had a reset since.

Have just checked the serial interrupt routine to be sure there is 
no watchdog code and there isn't - only accesses to serial registers.

Therefore it worked for me. If it works for others please a note 
because it would indicate more restrictions than just Watchdog 
register space.

Cheers

Mark Butcher

Re: [lpc2000] Re: Watch dog funnies again

2004-09-20 by Robert Adsett

At 06:23 PM 9/20/04 +0000, you wrote:
<snip>
>In any case I protected the feed sequence from interrupts and have
>never had a reset since.

<snip>

>Therefore it worked for me. If it works for others please a note
>because it would indicate more restrictions than just Watchdog
>register space.

Looks like a case could be made here for someone from Philips to check to 
see if there is a documentation error.  It would not surprise me if the 
feed logic used for the PLL and the Watchdog were copies of one another.

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

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.