Repository navigation
machine.reset_cause() should be machine.WDT_RESET after watchdog timeout on ESP32 #5134
Description
Activity
Look closely at the logging of your device -- does the log print out the reset reason? I've seen the IDF do a "double reset," and you end up getting the code for the 2nd reset.
I just tried it out on a completely minimal ESP32 board, and I get what's below.
It looks like a clean abort() and reboot(). On some instances on power-on I get 1(PWRON_RESET) and others I get 3(WDT_RESET). The Control-D on blank line reset (soft-reboot) doesn't change the value. I can confirm that
machine.deepsleep(1000)... [reset ensues]... reset_cause()returns 4(DEEPSLEEP_RESET), which is a good sign that some of this is working as it appears it should.>>> machine.WDT(timeout=1000) <WDT> >>> E (38998) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time: E (38998) task_wdt: - mp_task (CPU 0/1) E (38998) task_wdt: Tasks currently running: E (38998) task_wdt: CPU 0: IDLE0 E (38998) task_wdt: CPU 1: IDLE1 E (38998) task_wdt: Aborting. abort() was called at PC 0x40103dd0 on core 0 ELF file SHA256: 0000000000000000000000000000000000000000000000000000000000000000 Backtrace: 0x4008aa2b:0x3ffb08f0 0x4008ad49:0x3ffb0910 0x40103dd0:0x3ffb0930 0x400844e9:0x3ffb0950 0x4018e6cb:0x3ffbc320 0x40104bbf:0x3ffbc340 0x40090d05:0x3ffbc360 0x4008f5fd:0x3ffbc390 Rebooting... ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:4928 ho 0 tail 12 room 4 load:0x40078000,len:9404 load:0x40080400,len:6228 entry 0x400806ec I (440) cpu_start: Pro cpu up. I (440) cpu_start: Application information: I (440) cpu_start: Compile time: Jul 6 2019 12:34:18 I (444) cpu_start: ELF file SHA256: 0000000000000000... I (450) cpu_start: ESP-IDF: v3.3-beta1-694-g6b3da6b18 I (456) cpu_start: Starting app cpu, entry point is 0x40082b54 I (447) cpu_start: App cpu up. I (467) heap_init: Initializing. RAM available for dynamic allocation: I (474) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM I (480) heap_init: At 3FFB9CA0 len 00026360 (152 KiB): DRAM I (486) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM I (492) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (499) heap_init: At 400921FC len 0000DE04 (55 KiB): IRAM I (505) cpu_start: Pro cpu start user code I (76) cpu_start: Starting scheduler on PRO CPU. I (0) cpu_start: Starting scheduler on APP CPU. MicroPython v1.11-126-g7c2e83324 on 2019-07-06; ESP32 module with ESP32 Type "help()" for more information. >>> import machine >>> machine.reset_cause() 5The WDT on the esp32 has a software implementation (in the IDF), and the reset from this "soft WDT" will be a normal SW_CPU_RESET. I don't know if it's possible to tell that apart from other reset reasons that yield SW_CPU_RESET.
It looks like it's a limitation of the IDF, that it's not possible to tell if the reset was initiated by a WDT.
- added a commit that references this issue
on May 29, 2020 - added a commit that references this issue
on May 23, 2026 - added a commit that references this issue
on Sep 21, 2026
Currently, reset_cause() returns SOFT_RESET after a watchdog timeout, the same as after you call machine.reset().