ESP32 Forum

My application on ESP32E, 4MB and IDFv4.4.6 starts 4 tasks. The application has been working fine with WDT manually set up in the code, and idle task monitoring turned off in menuconfig. But now I am getting continual WDT reset as below.

I (2975) wifi:enable tsf
I (2976) wifi:Set ps type: 1

WiFi: client started
ets Jul 29 2019 12:21:46

rst:0x8 (TG1WDT_SYS_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)

...

W (194) boot.esp32: PRO CPU has been reset by WDT.
W (200) boot.esp32: WDT reset info: PRO CPU PC=0x40085bf8
0x40085bf8: _xt_panic at C:/exp/frameworks/esp-idf-v4.4.6/components/esp_system/port/arch/xtensa/panic_handler_asm.S:28

W (206) boot.esp32: WDT reset info: APP CPU PC=0x400d2dd6
0x400d2dd6: panic_handler at C:/exp/frameworks/esp-idf-v4.4.6/components/esp_system/port/panic_handler.c:141 (discriminator 1)

Of my 4 tasks, I manually set up WDT on 3 of them. The 4th task without monitoring is running WebServer. Searching, I came across this discussion:

https://github.com/orgs/micropython/discussions/10377

So as a test, I ran the app without starting the WebServer task, and sure enough, no more WDT.

I backed out to a known good working set of code, and still got the same error, when that version didn't previously exhibit this ever. I don't understand why I'm getting this apparently suddenly. It also doesn't look like the normal WDT resets I got during development of that feature where it usually gives a task name and shows a list of tasks.

Additionally this WDT reset happens immediately, not after the 5 seconds configured in menuconfig. The last event from my WifiEventHandler is SYSTEM_EVENT_STA_START which outputs the "client started" message just before the reset in the above log.

From the looks of it, it's not actually the watchdog causing the reset. Rather, it's the panic handler which just uses the watchdog to force a reset.
So the issue is actually that something in the code is causing an unhandled exception ("panic").

Ah, thanks, I thought it was the other way WDT -> panic handler, which also didn't really make sense since I don't have it configured that way. But seems an odd situation to use WDT, and a red herring that sent me on a wild goose chase.

I had noticed something odd about my main task. After starting my 4 tasks I would just kill it with vTaskDelete(NULL). But when it seemed the WebServer task had a stackoverflow it reported it as the maintask. Which seemed odd. I also try just letting the app_main finish and return rather than explicitly killing it. I thought I read it gets killed then anyway. I couldn't find a definitive answer on how to handle an unused app_main after spawning tasks.

Anyway, the strange symptoms, I decided just to have the main task run the webserver instead. That elliminated the question of what's the best thing to do with the main task, and surprise, it also fixed this weird reset I was getting.

HighVoltage wrote: ↑

Wed Dec 06, 2023 11:22 pm

I couldn't find a definitive answer on how to handle an unused app_main after spawning tasks.

Any way is fine. You can keep it running and do work in app_main (it's just a task anyway), you can vTaskDelete(NULL) it, or just return from it (app_main() is special in that it is allowed to return, and its task will then be deleted automatically).
As with any function or task, you have to make sure that no other task is still referencing something on app_main's stack when it ends.