Watchdog Reset (TG1WDT_SYS_RST)
Posted: Wed Oct 29, 2025 8:48 am
Hi everyone,
I’m encountering a Watchdog Reset on my ESP32-S3 after 10-15 hours of working.
Here is the relevant part of the boot log:
The reason of reboot is rst:0x8 (TG1WDT_SYS_RST) → Timer Group 1 Watchdog Timer triggered a system reset
But I have no backtrace or core dump to uart.
I don't use interrupt directly, and the esp32 is using wifi, uart, BLE, modbus.
Using xtensa-esp32s3-elf-addr2line -pfiaC -e build/gateway-esp32.elf 0x42004bcf I found the last line executed in panic_handler.c line 146.
I can't replicate the error and i can't understand the state of esp32 before the panic handler.
I try :
- stack corruption
- while(1) inside main task
- division by 0
- memcpy to null position
What could cause the TG1WDT_SYS_RST at this early stage?
Could a peripheral (e.g., PSRAM, SPI, or power instability) trigger this WDT reset?
I’m encountering a Watchdog Reset on my ESP32-S3 after 10-15 hours of working.
Here is the relevant part of the boot log:
Code: Select all
rst:0x8 (TG1WDT_SYS_RST),boot:0x9 (SPI_FAST_FLASH_BOOT)
Saved PC:0x42004bcf
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3810,len:0x164c
load:0x403c9700,len:0xbcc
load:0x403cc700,len:0x2e20
entry 0x403c9904
I (25) boot: ESP-IDF v5.0.1-dirty 2nd stage bootloader
I (25) boot: compile time 18:13:36
I (25) boot: chip revision: v0.2
I (27) boot.esp32s3: Boot SPI Speed : 80MHz
I (32) boot.esp32s3: SPI Mode : DIO
I (37) boot.esp32s3: SPI Flash Size : 8MB
W (42) boot.esp32s3: PRO CPU has been reset by WDT.
W (47) boot.esp32s3: APP CPU has been reset by WDT.
I (53) boot: Enabling RNG early entropy source...
I (58) boot: Partition Table:The reason of reboot is rst:0x8 (TG1WDT_SYS_RST) → Timer Group 1 Watchdog Timer triggered a system reset
But I have no backtrace or core dump to uart.
I don't use interrupt directly, and the esp32 is using wifi, uart, BLE, modbus.
Using xtensa-esp32s3-elf-addr2line -pfiaC -e build/gateway-esp32.elf 0x42004bcf I found the last line executed in panic_handler.c line 146.
Code: Select all
static void panic_handler(void *frame, bool pseudo_excause)
{
panic_info_t info = { 0 };
/*
* Setup environment and perform necessary architecture/chip specific
* steps here prior to the system panic handler.
* */
int core_id = esp_cpu_get_core_id();
// If multiple cores arrive at panic handler, save frames for all of them
g_exc_frames[core_id] = frame;
#if !CONFIG_ESP_SYSTEM_SINGLE_CORE_MODE
// These are cases where both CPUs both go into panic handler. The following code ensures
// only one core proceeds to the system panic handler.
if (pseudo_excause) {
#define BUSY_WAIT_IF_TRUE(b) { if (b) while(1); }
// For WDT expiry, pause the non-offending core - offending core handles panic
BUSY_WAIT_IF_TRUE(panic_get_cause(frame) == PANIC_RSN_INTWDT_CPU0 && core_id == 1);
BUSY_WAIT_IF_TRUE(panic_get_cause(frame) == PANIC_RSN_INTWDT_CPU1 && core_id == 0);
// For cache error, pause the non-offending core - offending core handles panic
if (panic_get_cause(frame) == PANIC_RSN_CACHEERR && core_id != esp_cache_err_get_cpuid()) {
// Only print the backtrace for the offending core in case of the cache error
g_exc_frames[core_id] = NULL;
panic_print_str("Guru Cache Error");
while (1) { //line 146!!!!!
;
}
}
}
I can't replicate the error and i can't understand the state of esp32 before the panic handler.
I try :
- stack corruption
- while(1) inside main task
- division by 0
- memcpy to null position
What could cause the TG1WDT_SYS_RST at this early stage?
Could a peripheral (e.g., PSRAM, SPI, or power instability) trigger this WDT reset?