ESP32 Forum

My project is experiencing intermittent resets due to the Interrupt WDT Timeout. I have a number of Guru meditation register dumps and backtraces as well as the corresponding core-dumps. Below I have inserted copies of a guru dump and the core dump from a single crash occurrence.

These crashes consistently have calls to the i2c_isr_handler_default in current thread and Core 0 always seems to be in ISR context.
There are 2 ISR functions that get printed, uart_hal_write_txfifo and i2c_isr_handler_default... but the EPCx registers in the guru dump don't exactly match what the core dump produced.

IDF version is 4.2.2.

Ultimately what I would like answered is how to make sense of the guru dump and the core dump... understanding the meaning of the different registers, especially the Exception registers, and the call stacks. Also, how is the stack managed when in ISR context?

The core dump has some issues, which I suspect may be due to heap corruption, or maybe stack overflow, but I've increased the stack sizes and still experience the problem as similar rates. There are 2 threads that tend to get stomped on in the core dump, and the threads info section lists a bunch of "New process nnnnn" messages at the end, which I don't understand.


Guru dump...
Coredump...
-jw

Note that the name "interrupt WDT" may be a bit confusing. As per the docs, the IWDT is "fed" from the FreeRTOS tick ISR and as such only detects if this specific ISR did not run for a certain amount of time.
Hence, the point at which the IWDT triggers may be not directly linked to the problematic code section.
In your case for example, it is unlikely that the I2C ISR runs longer than the IWDT timeout period.

Assuming your own code doesn't spend excessive time in a critical section, I think it is possible that in your application there may be periods with a lot of interrupts happening in quick succession and that this causes execution to basically jump back and forth between critical sections (queue/semaphore operations) and ISRs.

Another thing is the "spin_task"s. Name and stack trace suggest that these tasks may starve the IDLE task of CPU time, which among other things can cause FreeRTOS timer callbacks to not be processed in time.

As to the gaps in the backtrace, this does not necessarily indicate any problem. Not 100% certain about the Xtensa architecture, but on some/many platforms the call stack may fail to be correctly traced back if/when the exact stack layout is not known at build time, which can happen if/when a function allocates a dynamic amount of space from the stack at runtime (e.g. variable length arrays).

Hi MC,
Thank you for your response, it has given me a couple of things to ponder in hopes to get to the bottom of this issue.

It may be quite possible that the I2C handling and the UART handling are consuming quite a bit of time and thus preventing FreeRTOS from "kicking" the IWDT. I think I will try disabling the IWDT in a test and collect some metrics from the FreeRTOS tick handler on just how long it is getting starved. Not quite sure how I to do that off the top of my head though.

As for the spin_tasks, I have enabled the FreeRTOS stats collection, but only allow it to run when for 1.5 seconds via a console command. The 2 spin_tasks sit in the suspended state otherwise.

-jw

collect some metrics from the FreeRTOS tick handler

esp_register_freertos_tick_hook(...)

If you determine that the condition the IWDT detects is only temporary and normal in your application, you can of course always set a longer timeout period.