Is it possible to protect against excessive deep-sleep delays?

[Neil.Macmullen]

According to the documentation https://docs.espressif.com/projects/esp ... modes.html esp_sleep_enable_timer_wakeup accepts a 64 bit value which is the number of microseconds. The maximum value of this is rather high - hundreds of thousands of years!

Since my application has no external interrupt sources I am paranoid that a programming error could cause the API to be called with a very high value, effectively bricking the unit during deployment.

Is there any way to protect against this? (AFAIK the watchdog timer does not run during deep-sleep?)

Thanks

[chegewara]

You could use uint16 or uint32 value for sleep time and cast it to uint64 in esp_sleep_enable_timer_wakeup.
If you need longer time than uint32 max value you could multiply it by 1000, in this case your sleep time will be uint32 in ms.
Another option is to use uint64 and bitwise AND to not allow timer exceed some value, or use assert to check if timer value is bigger than hour, day, week or so.

[WiFive]

There is an rtc watchdog

[Neil.Macmullen]

@chegewara. That doesn't protect against the kinds of errors I'm talking about where the code is in such an error state (e.g. from a corrupted PC return address on the stack) that it is calling the raw API with a random value.

@WiFive Thanks - that sounds interesting. Is there an API to control this? I tried searching for "watchdog" in the documentation and also had a look through soc\rtc.h and rom\rtc.h but couldn't see anything that looked like it applied?

[chegewara]

It is protecting against such situations. Its just example:

Code: Select all

uint32_t sleep_time; // time in ms
esp_sleep_enable_timer_wakeup((uint64_t)(sleep_time & 0xFFFFFF) * 1000); // max allowed sleep time is about 280 minutes

If you will use bitwise AND like in this example then you dont have to use uint32 variable size and casting to 64 bit.

[Neil.Macmullen]

@chegewara Perhaps I haven't explained clearly enough.... Although it's very unlikely, the CPU program counter can get corrupted. One reason for this is supply brownout though this is protected against on the ESP and most modern CPUs. There are plenty of other reasons though and one of the most likely is overwriting the stack so that the return PC is overwritten. In that case the CPU can start executing anywhere and although unlikely it can jump straight to the entry point for esp_sleep_enable_timer_wakeup (or inside the function) with completely random values for the argument (it will just depend on the contents of the registers at the time). So adding a software guard to truncate the value really doesn't help - you need a hardware mechanism.

[boarchuz]

You could write your own little watchdog using the ULP coprocessor to generate an interrupt if it's not fed for x hours/days/weeks. I suppose that's subject to the same kind of hiccup but what are the odds of it happening twice? (Really, what are the odds of it happening even once?)

[Neil.Macmullen]

Thanks @boarchuz. The ULP is a good idea. I agree it's unlikely but in a previous life we had a significant issue with a similar problem (albeit high unit volumes and exacerbated by lack of brownout protection) and the current product is intended to work for 5-10 years in the field without any manual intervention. We've already seen a couple of instances of devices that "died" but started working again after a full power-cycle. I suspect some other hardware failure mode (perhaps just loose power connector) but would like to be able to rule out a ridiculously long sleep period.

[Moriki]

Hi,

There is an rtc watchdog

Note that for the rtc watchdog to reset the system during deep sleep you have to:
1. Unset the RTC_CNTL_WDT_PAUSE_IN_SLP bit (enabled by default by rtc_wdt_enable())
2. Use the "reset RTC" action. The "reset system" action does not preform any action during deep sleep.