ESP32双核下FreeRTOS任务与WiFi协议栈抢核导致看门狗复位的定位方法

· 行业用户 · 20 浏览

回答(4)

在Core 1上跑业务,Core 0留给WiFi和系统任务,并给看门狗喂狗任务最高优先级,可显著减少抢核问题。
RTOS小刘 · 2026-11-11
用uxTaskGetStackHighWaterMark检查任务栈是否溢出,栈溢出也会触发看门狗,尤其WiFi回调中调用大局部变量时。
ESP32玩家 · 2026-11-11
优先检查WiFi任务优先级是否被用户任务覆盖,WiFi默认优先级较高,若用户任务设得更高会饿死协议栈,导致看门狗复位。
嵌入式老张 · 2026-11-11
首先确认复位原因:读取esp_reset_reason(),若为TASK_WDT或INT_WDT则锁定看门狗。接着在menuconfig中开启FreeRTOS运行统计(CONFIG_FREERTOS_GENERATE_RUN_TIME_STATS)和任务列表(CONFIG_FREERTOS_USE_TRACE_FACILITY),在疑似卡死任务中周期性调用vTaskGetRunTimeStats()和uxTaskGetSystemState(),观察哪个任务长期占用CPU或处于就绪态但未运行。重点检查WiFi任务(wifi、tiT、pp)与用户任务的优先级和核心绑定:用xTaskCreatePinnedToCore将用户高负载任务固定到Core 0或Core 1,避免与WiFi协议栈(默认Core 0)争抢;确保看门狗喂狗任务优先级高于所有业务任务,且不被阻塞。若怀疑中断风暴,用gpio_set_direction和定时器统计中断频率。最后在可疑任务中插入esp_task_wdt_reset()并缩短超时时间以快速复现,结合JTAG或core dump定位具体阻塞点。
mcuku 阿沐 · 2026-11-11