Watchdog managed by sketch only

[hallard]

I'm wondering if there is any way to manage watchdog ONLY by the user sketch ?
From my point of view, this kind of "feed the dog" should be done by user and never by any lib or sdk calls (or explicitly indicated). But as today I'm unable to know where and when it's feeded?

Of course we can let it as it, I understand most users don't want to deal with it, but I'm working on sensitive production sites and I need to be able to manage it myself.
Why simply because if any library/sdk routine and whatever is feeding the dog in any kind of loop/for/while/delay..., It can continue to feed it while program is being blocked.
I can't do assumption that it will be fired in all case and cross my fingers on thinking code will do it right. Don't ask me how it can happens (bad call, bad parameters, interference, whatever, ..) but trust me, it happens and I already saw it, sketch blocked needed to be restarted by manual reset, Imagine me calling customer please could you please reset the device I sold ?
And no, I don't feed the dog in my sketch or my lib so it wasn't in my code at all.

Not sure it's possible but knowing where it's done (Lib or SDK) could help us to understand an track.
And last but not least, may be worth adding external WDT chip.

Any ideas are welcome

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Links2004]

if you not want to hack the sdk at Assembler level its not possible.
but you can create a watchdog like functionality for the "arduino loop".
I have running this in all my deployed ESPs to prevent a deadlock like you describe:

#include <Ticker.h>
Ticker tickerOSWatch;

#define OSWATCH_RESET_TIME 30

static unsigned long last_loop;

void ICACHE_RAM_ATTR osWatch(void) {
    unsigned long t = millis();
    unsigned long last_run = abs(t - last_loop);
    if(last_run >= (OSWATCH_RESET_TIME * 1000)) {
      // save the hit here to eeprom or to rtc memory if needed
        ESP.restart();  // normal reboot 
        //ESP.reset();  // hard reset
    }
}

void setup() {
    last_loop = millis();
    tickerOSWatch.attach_ms(((OSWATCH_RESET_TIME / 3) * 1000), osWatch);
}

void loop() {
    last_loop = millis();
   while(1)   delay(1000);  // this will trigger the os watch
}

a full lock of the ESP will be handled by the HW watchdog.
a soft lock of the SDK will trigger the SW watchdog.
a loop lock will be covert by the "OSWatch".

[hallard]

Wohhhh excellent, I will implement this in my sketch, many thanks
and happy I'm not the only one looking for reliable and unlockable devices ;-)

[tuxedo0801]

+1

Maybe one could put the code into a simple libary so that it can be reused more easily.

[asetyde]

Markus not use it when you develop !!! How do you see a deadlock Thanks i hope reuse this function to prevent lock of devices

[Links2004]

@asetyde i use it only in my deployed ESPs,
for development i have a other variant that only give me warnings and i use it to tracks the heap too.

[hallard]

Hummm, for sure this variant would be definitely interesting!

[Links2004]

void ICACHE_RAM_ATTR osWatch(void) {
    unsigned long t = millis();
    unsigned long last_run = abs(t - last_loop);

    os_printf("[osWatch] last_run: %d FreeRam: %d rssi: %d\n", last_run, ESP.getFreeHeap(), WiFi.RSSI());
    if(last_run >= (OSWATCH_RESET_TIME * 1000)) {
        os_printf("[osWatch] WARNING loop Blocked! check for deadlock!\n");
    }
}

Note: it can theoretical crash if the flash is blocked and the used functions are not in cache any more.
but I never have seen this behavior, if it will at some point the stack will show it me ;)

[asetyde]

OOK , good work , i take it , more Watchdog philosophy is better ! :)

[igrr]

Regarding watchdogs already present in the code... We have a hardware timer, controlled via registers, and a software watchdog serviced by on of the hardware timers dedicated to WiFi stack. Both are normally active. Hardware timer is kicked at two points in the SDK code, and some trickery is required to override that behavior (read: replace instructions with nops). Software one is easier to get hold of — we can wrap pp_soft_wdt_feed function at linking step and replace it with a no-op, leaving it to the user to call the real feed function. It's not hard to implement, just a few lines of code.
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. So I'm not sure that exposing the watchdog to user and cutting it from the SDK will be immediately useful. However, comments are welcome. I would definitely love to have at least some wdt APIs exposed.

[asetyde]

update : @Links2004 solution give me a good stability to escape some bugs and particular situations in that esp freeze , no freeze it has seen .

[asetyde]

it can be closed ? this homemade watchdog is perfect for me