Hard to debug sporadic TG1WDT_SYS_RESET after esp_deep_sleep call.

[emp_tamarin]

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:

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=0x4008bbc0

Symbol info for those addresses:

Code: 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.text

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?

[xdraye]

Hi Tamarin,
I have exactly the same issue as the one you describe here. My program does various things on I2C, SPI and UART, closes all devices/streams/ports explicitely, wait 5 seconds and goes into deep sleep (with EXT0 and EXT1 enabled). Sporadically (and I have not been able to provoke it), it reboots with that TG1WD message right after the call to deep sleep.
I was wondering if you had a chance to solve the issue in your case and if you could suggest ways to debug it.
What I am planning to do (as a work around) is to check the nature of the reset and, if TG12WDT, ignore and go back to sleep...
Your help woudl be highly appreciated!
Xavier.