Forums

Watchdog defeated on LPC1766

Started by Kevin August 26, 2011
Hello,

I have enabled the watchdog on the LPC1766 and its working fine on most occasions. However I have been able to let the controller crash in such a way that the watchdog doesn't reset the controller. I like to know if this is my own fault or just a bad watchdog. Unfortunately I am not able to use a debugger on this, my hardware doesn't have the connector.

An easy way to crash it is by doing a divide by zero.

This is my watchdog init:

void enableWatchdog()
{
WDTC = 0x00FFFFFF;
WDMOD = 3;
WDFEED = 0xAA;
WDFEED = 0x55;
}

The watchdog kick is this one:

void kickWatchdog()
{
WDFEED = 0xAA;
WDFEED = 0x55;
}
--
Kevin

An Engineer's Guide to the LPC2100 Series

Hi:

In the ARM Cortex-M3 core, a division by zero doesn't generate a fault exception (usage fault), unless it is explicitly enable in the NVIC Configuration Control Register.

A division by zero just returns 0.

Most likely, your code just continued working after the division by zero and kept resetting the watchdog timer.

Regards,

Alex
--- In l..., "Kevin" wrote:
>
> Hello,
>
> I have enabled the watchdog on the LPC1766 and its working fine on most occasions. However I have been able to let the controller crash in such a way that the watchdog doesn't reset the controller. I like to know if this is my own fault or just a bad watchdog. Unfortunately I am not able to use a debugger on this, my hardware doesn't have the connector.
>
> An easy way to crash it is by doing a divide by zero.
>
> This is my watchdog init:
>
> void enableWatchdog()
> {
> WDTC = 0x00FFFFFF;
> WDMOD = 3;
> WDFEED = 0xAA;
> WDFEED = 0x55;
> }
>
> The watchdog kick is this one:
>
> void kickWatchdog()
> {
> WDFEED = 0xAA;
> WDFEED = 0x55;
> }
> --
> Kevin
>

How do you confirm that, in the "crashed" state, your watchdog
is _not_ being fed.

Your standard peripherals might not be operating as intended, but
that _could_ be the case if one of your peripheral-initialisation
routines only works if the processor is coming out of a hard
reset, and not if a restart (watchdog event) happens with the
peripheral already running.
One such peripheral is, of course, the watchdog itself!

If you can't hook up a regular debugger, can you hang LEDs off
spare pins and flip them at strategic points in your code?

Hope this helps,
Danish

I now know what went wrong and it is indeed my own fault. When a cpu fault interrupt is entered and the fault handling code doesn't skip the offending code or reboots the chip, then the fault interrupt keeps being fired.
What happened in my case was that I changed the watchdog timeout time in the fault interrupt, changing it requires a feed sequence. However I didn't have an while(1) in the handling routine and therefore it kept feeding the watchdog. This made it seem like the dog was broken.

Thanks for your help, it made me realize my mistake.