cancel
Showing results for 
Search instead for 
Did you mean: 

Watchdog reset not working correctly, silicon bug?

mark9
Associate II
Posted on March 22, 2008 at 20:17

Watchdog reset not working correctly, silicon bug?

2 REPLIES 2
mark9
Associate II
Posted on May 17, 2011 at 09:51

It appears that a watchdog reset does NOT clear the watchdog registers reliably. I find that if I force a watchdog reset with a statement such as while(1); in my high priority task, the STR912 resets once, and then shortly thereafter (about 1 second) it resets again, *BEFORE* it is initialized again.

On a normal power-on reset, the WDG registers are read out as:

CR:0000 PR:00FF VR:FFFF CNT:FFFF SR:0000 MR:0000

The state of the WDG registers after initializing the watchdog are

CR:0005 PR:00FF VR:007D CNT:007C SR:0000 MR:0000

Then I force a watchdog reset with ''while(1);''

On the first reset, the values are

CR:0005 PR:00FF VR:007D CNT:0034 SR:0000 MR:0000 !!!!!

(you can see that CR=5 means that the watchdog is enabled, even though it hasn't been enabled explicitly!)

After the second reset, the values are

CR:0000 PR:00FF VR:FFFF CNT:FFFF SR:0000 MR:0000

(which looks correct)

We have a silicon bug in one of our peripheral chips that is hopefully going to be resolved, but until then, we need to rely on the watchdog reset to get us out of a wedged state, and also to perform a software reset.

mark9
Associate II
Posted on May 17, 2011 at 09:51

Update. I was using the RTC as the clock source (CR=0x0005). The VR register was set to 0x007D and the prescalar was 0xFF, resulting in a watchdog period of 1024 ms.

I changed to the APB clock as WDG source (CR=0x0001), with VR set to 0xFFFF and prescalar set to 0xFF (with APB clock at 48MHz) which is a watchdog period of 350 ms.

I do not see the problem any more, with the double watchdog resets.

My gut feeling is that there is a hardware issue with the RTC as the WDG source.