Hitting Watchdog Too Often

Status
Not open for further replies.

brianmichalk

Active member
Why does hitting the watchdog too often not reset the watchdog timer? The following code causes a reset on the Teensy 3.2.
Code:
#include <Adafruit_SleepyDog.h>

void setup() {
  Watchdog.enable(5000);
  delay(1000);
  Serial.begin(115200);
  Serial.setTimeout(10);
  delay(100);
  Serial.println("Setup");
}

void loop() {
  Watchdog.reset();
  // comment the following line to cause a reset.
  delay(1000); Serial.println(".");
}
 
Try with:

Code:
#include <Adafruit_SleepyDog.h>

elapsedMillis wdMillis;

void setup() 
{
   Watchdog.enable(5000);  
}

void loop() 
{

  if (wdMillis > 4900)
   {
      wdMillis = 0;
      Watchdog.reset();
   }  
}
 
I understand that the watchdog is typically reset just before the timer expires. I am more interested in why it doesn't work if it is reset too often.
 
The underlying ARM processor implements a windowed watchdog, and will reset on too fast or too slow watchdog service intervals. It looks like the default value for the lower counter is 16 ( which may or may not represent 16 ms. You can test that with your program ).

Edit: Looking further it appears the windowed mode is not enabled in the status register.
 
Last edited:
With nothing else in loop() that reset() is being called at least a couple hundred thousand times per second on a T_3.2.

I put the code in a sketch and without waiting at least/about 970 microseconds with a delay between calls the watchdog would restart the processor as if watchdog was not reset().

Since I had to download the library I glanced at it - the reset() call :: Disables interrupts, writes the needed values to reset the timer, then Enables interrupts. That interrupt toggle could be generally disruptive of normal operation and function.

The watchdog code/implementation seems to deal with millisecond time intervals and calling it every few microseconds … up to that 970 us … is just not how it was designed to be used - or perhaps as @rcarr notes perhaps updates too fast are defined as another way the watchdog defines failure - the processor docs would detail that.
 
This is indeed a strange problem. The watchdog somehow getting into windowed mode does seem like the only plausible explanation, but I can't see how that could be happening.

I am currently at Maker Faire in San Mateo, so writing this from my laptop in a hotel room without access to my workbench & tools. If I miss this when I get back on Tuesday, please ping me with a reminder. I'd really like to dig into why this is happening, when I have access to my tools.
 
Status
Not open for further replies.
Back
Top