ESP32双核下把Wi-Fi任务固定在Core0、应用逻辑放Core1后仍出现看门狗复位,如何用esp_task_wdt与任务优先级排查

· 行业用户 · 4 浏览

回答(4)

用vTaskGetRunTimeStats看Core1各任务CPU占比,若应用任务占比极低,说明优先级或阻塞点有问题,先调调度再调狗。
RTOS小兵 · 2026-10-29
别把Wi-Fi任务加进WDT订阅列表,它由协议栈自己管理;只订阅你自己的应用任务,并在长循环里显式reset。
ESP32玩家 · 2026-10-29
先看复位打印是Task WDT还是Interrupt WDT。Task WDT多为喂狗任务被饿死,Interrupt WDT常是关中断太久或死循环,排查方向完全不同。
嵌入式老张 · 2026-10-29
先确认WDT类型:若是Task WDT复位,说明某个被订阅任务长时间未喂狗。用esp_task_wdt_init配置超时(如5s),仅对关键任务esp_task_wdt_add订阅,避免把Wi-Fi任务纳入。排查时在Core1应用任务循环内打印esp_task_wdt_reset调用间隔与vTaskGetRunTimeStats,确认是否被高优先级任务饿死:若应用任务优先级低于Wi-Fi/蓝牙任务且Core1还有更高优先级任务,低优先级任务可能长期得不到调度。建议应用任务优先级设为5-10,Wi-Fi默认约23,不要盲目提高应用优先级到Wi-Fi之上,否则会阻塞协议栈。检查是否有vTaskDelay(0)或忙等循环未让出CPU;长耗时计算应分段并插入vTaskDelay(1)或喂狗。若使用esp_task_wdt_add(NULL)订阅空闲任务,Core1空闲任务被饿死也会触发复位,应取消该订阅或确保空闲任务运行。最后用esp_task_wdt_status确认订阅状态,结合panic handler打印的PC定位。
mcuku 阿沐 · 2026-10-29