Hard to debug sporadic TG1WDT_SYS_RESET after esp_deep_sleep call.
Posted: Sun May 19, 2024 12:34 pm
Hardware: ESP32-WROVER-E module on a LilyGo T5 e-Paper dev board.
Software: PlatformIO with ESP-IDF 5.2.1 (PlatformIO's espressif32 6.7.0)
This project connects to WiFi, grabs some data and displays it then goes to sleep for 15 minutes by calling esp_deep_sleep(...).
PSRAM is used to hold the frame buffer for the display.
Most of the time this works fine but sometimes (once every 10-20 cycles) the ESP32 appears to go to sleep but then immediately resets with a TG1WDT_SYS_RESET reason and the 2nd stage bootloader contains these lines:
Symbol info for those addresses:
There's no backtrace/panic output anywhere, the only thing that gives away something was going on is the reset reason and the lines printed by the 2nd stage bootloader.
The code then runs fine (although it wasn't supposed to for another 15 minutes...) and eventually attempts to go to sleep again, usually that succeeds but I've also seen this cycle of TG1WDT_SYS_RESET resets happen 3 times before it finally works.
Any help on how to approach debugging this hard to (reliably) reproduce problem?
Software: PlatformIO with ESP-IDF 5.2.1 (PlatformIO's espressif32 6.7.0)
This project connects to WiFi, grabs some data and displays it then goes to sleep for 15 minutes by calling esp_deep_sleep(...).
PSRAM is used to hold the frame buffer for the display.
Most of the time this works fine but sometimes (once every 10-20 cycles) the ESP32 appears to go to sleep but then immediately resets with a TG1WDT_SYS_RESET reason and the 2nd stage bootloader contains these lines:
Code: Select all
W (84) boot.esp32: PRO CPU has been reset by WDT.
W (89) boot.esp32: WDT reset info: PRO CPU PC=0x40084110
W (95) boot.esp32: WDT reset info: APP CPU PC=0x4008bbc0Code: Select all
(gdb) info symbol 0x40084110
handle_livelock_int + 57 in section .iram0.text
(gdb) info symbol 0x4008bbc0
esp_ipc_isr_waiting_for_finish_cmd + 3 in section .iram0.textThe code then runs fine (although it wasn't supposed to for another 15 minutes...) and eventually attempts to go to sleep again, usually that succeeds but I've also seen this cycle of TG1WDT_SYS_RESET resets happen 3 times before it finally works.
Any help on how to approach debugging this hard to (reliably) reproduce problem?