-->
Page 1 of 1

watchdog timer tests

PostPosted: Thu Sep 22, 2016 12:59 am
by DaveEvans
In case this might be of value to someone...I did some tests of the watchdog timer and ESP.wdtDisable(), ESP.wdtEnable(0), ESP.wdtEnable(time), and ESP.wdtFeed()

Adafruit Huzzah ESP8266

Summary of results:

Test 1. If the software watchdog timer (SW wdt) is not disabled, the 1.5 s test works but the SW wdt resets during the 2.5 s test.

Test 2. if the SW wdt is disabled, the 7 s test works but the hardware watchdog timer resets during the 10 s test.

Test 3. if the SW wdt is disabled but wdtFeed() is done every 100 ms, the 20 s test works

Test 4. if the SW wdt is enabled with a 15s timeout, the 2.5 s test works, but the SW wdt resets during the 5 s test (a comment in ESP.h says the timeout is not implemented yet)

Oddly, although tests 1 and 4 fail with "soft WDT reset," cause "2" is issued, which is "reset pin," not "watchdog reset"

Code: Select all/* September 2016

   this is a test of the ESP8266 watchdog timer
    and
   ESP.wdtDisable(), ESP.wdtEnable(0), ESP.wdtEnable(time), and ESP.wdtFeed()
   which were added to ESP.h April 2015
 
 references:
   https://github.com/esp8266/Arduino/blob/master/doc/reference.md#timing-and-delays  = basic ref
   https://github.com/esp8266/Arduino/blob/master/cores/esp8266/Esp.h  = note line 89 comment that timeout value is not implemented
   http://bbs.espressif.com/viewtopic.php?f=7&t=203 = says watchdog timeout is about 1 s...but see next reference!
   http://bbs.espressif.com/viewtopic.php?t=836 = implies software WDT resets after 3.2 s, and hardware WDT resets after 6 s
       in the example, not sure why it is necessary to feed the soft WDT after it is stopped (maybe that keeps the HW WDT from timing out?)
   http://internetofhomethings.com/homethings/?p=396 = suggests that timeout is about 5 s   
   https://github.com/esp8266/Arduino/issues/34  = May 5 test not valid since delay(10000) kicks WDT?
   https://github.com/esp8266/Arduino/issues/1532  = note Jan 29 comment re SPIFFS"
       igrr said "The only concern is that there are a few APIs in the core and libraries which are blocking.
                  I.e. you have blocking reads and writes with WiFi client and SPIFFS.
                  These may take unpredictable amount of time,
                  without giving the sketch a chance to feed the watchdog."         
   
   https://github.com/esp8266/Arduino/blob/master/doc/boards.md#boot-messages-and-modes

    rst cause:2, boot mode:(3,6)
   
    cause:
      0    unknown
      1    normal boot
      2    reset pin
      3    software reset
      4    watchdog reset
     
    boot mode:(x,y)

    "the first value respects the pin setup of the Pins 0, 2 and 15"    <- is not standard English
   
    DAE's note: although the above is not entirely clear, the "first" value (i.e., x)
    appears to be the boot mode (based on GPIO pin states):
    1=UART bootloader (if 15=0v, 0=0v, 2=3.3v)
    2=boot sketch i.e. SPI flash (if 15=0v, 0=3.3v, 2=3.3v)
    3=SDIO mode not used for Arduino (15=3.3v, others = don't care)
   
    number = ((GPIO15 << 2) | (GPIO0 << 1) | GPIO2), where 0 v = 0, and 3.3v = 1
   
    Number    GPIO15    GPIO0    GPIO2    Mode
      0      0V        0V        0V        Not valid
      1      0V        0V        3.3V      Uart
      2      0V        3.3V      0V        Not valid
      3      0V        3.3V      3.3V      Flash
      4      3.3V      0V        0V        SDIO
      5      3.3V      0V        3.3V      SDIO
      6      3.3V      3.3V      0V        SDIO
      7      3.3V      3.3V      3.3V      SDIO
   
   DAE's note: "number" appears to be the "second" value (i.e., y)
   
*/

#include <ESP.h>;

void setup(){

  Serial.begin(115200);
   Serial.println("wdt");

   test3(500);
   test3(1000);
   test3(1500);   
   test3(2500); // test1 fails here with "soft WDT reset" cause:2, boot mode:(1,6) <- cause 2 = reset pin (??)
   test3(5000); // test4 fails here with "soft WDT reset" cause:2, boot mode:(1,6) <- cause 2 = reset pin (??)
   test3(7000);   
   test3(10000); // test2 fails here with "wdt reset" cause:4, boot mode:(1,6)
   test3(20000);
// test3(20000) executes without reset

}

void loop() {

}

//  test1();
// should trigger SW WDT reset
// if the while loop duration is long enough

void test1(unsigned long testDuration){
 
  Serial.print("test1 "); Serial.print(testDuration); Serial.print(" ");
 
  unsigned long prevTime=millis();
  while (millis()-prevTime<testDuration) {}
 
  Serial.println(" end");

}

// test2();
// since SW WDT is disabled
// should NOT trigger SW WDT reset
// provided that duration is short enough
// but if duration is too long, HW WDT will reset

void test2(unsigned long testDuration){

  Serial.print("test2 "); Serial.print(testDuration); Serial.print(" ");
 
  ESP.wdtDisable();
  unsigned long prevTime=millis();
  while (millis()-prevTime<testDuration) {}
  ESP.wdtEnable(0);
 
  Serial.println(" end");
}


// test3();
// same as test2(), but test to see
// if feeding the WDT prevents
// the HW WDT from timing out (as implied by above ref)

void test3(unsigned long testDuration){

  Serial.print("test3 "); Serial.print(testDuration); Serial.print(" ");
 
  ESP.wdtDisable();
  unsigned long prevTime=millis();
  unsigned long prevTime2=prevTime;
  while (millis()-prevTime<testDuration) {   
    if (millis()-prevTime2>100){ // feed every 100 ms
       prevTime2=millis();
       ESP.wdtFeed();
    }   
  }
  ESP.wdtEnable(0);
 
  Serial.println(" end");
}


// test4();
// since timeout value not implemented (per Github comment)
// if duration is long enough,
// should trigger WDT SW reset

void test4(unsigned long testDuration){

  Serial.print("test4 "); Serial.print(testDuration); Serial.print(" ");
 
  ESP.wdtDisable();
  ESP.wdtEnable(15000);
  unsigned long prevTime=millis();
  while (millis()-prevTime<testDuration) {}
 
  Serial.println(" end");
}


Re: watchdog timer tests

PostPosted: Wed Nov 09, 2016 9:45 am
by RexBrown
Thanks very much for this post and the time you took to run these tests. This was very helpful information, especially since there is not much in the way of documentation of the watch dog operation. I was also able to take advantage of the yield() call to help with processes that were taking a while to complete. In fact the yield() call actually made the handling of WiFi connections work much smoother.

Re: watchdog timer tests

PostPosted: Sun May 07, 2017 8:44 am
by teddyz
I am trying to minimize chores in the ESP to make my code run as fast as possible. disabling watchdog
Code: Select allESP.wdtDisable();
still give a reset every 8.3907s @160MHz. Every loop will take about 1us longer if I let it go through the main loop instead of a eternal while-loop.
Do anyone have an idea how to turn off wdt completely? I am not using wifi.