# 引言 ESP32 集成双核 Xtensa LX6 处理器，FreeRTOS 默认将 WiFi 协议栈任务绑定在核心 0（PRO_CPU），用户任务通常运行在核心 1（APP_CPU）。这种异构调度虽然提升了吞吐量，但也引入了复杂的优先级交互。当用户任务通过事件组与 WiFi 事件同步时，若 WiFi 协议栈内部任务优先级高于用户任务，且持有共享资源（如事件组锁），则可能引发优先级反转，导致用户任务长时间无法获得事件组，甚至死锁。 # 双核调度与事件组原理 ## FreeRTOS 双核调度机制 - ESP32 的 FreeRTOS 为每个核心维护独立的就绪列表，但任务优先级是全局的。 - 调度器允许同一优先级任务在不同核心并行运行，但高优先级任务会抢占低优先级任务（无论核心）。 - WiFi 协议栈任务（如 `wifi_task`）通常设置为高优先级（如 23），而用户任务可能设为 10~15。 ## 事件组与内部锁 - 事件组通过 `xEventGroupSetBits()` 和 `xEventGroupWaitBits()` 操作，内部使用临界区或互斥锁保护位图。 - 在双核环境下，事件组操作需要跨核同步，锁的持有时间可能因缓存一致性而变长。 - 若高优先级 WiFi 任务在持有事件组锁时被阻塞（如等待网络缓冲区），低优先级用户任务即使获得 CPU 也无法访问事件组，形成优先级反转。 # 实战案例：WiFi 连接事件同步卡死 ## 场景描述 - 用户任务 `app_task`（优先级 12）等待 WiFi 连接成功事件（`WIFI_CONNECTED_BIT`）。 - WiFi 事件处理任务 `wifi_event_task`（优先级 23）在收到 `SYSTEM_EVENT_STA_GOT_IP` 后设置事件位。 - 现象：`app_task` 偶尔永久阻塞在 `xEventGroupWaitBits()`，即使 WiFi 已连接。 ## 排查步骤 1. **打印任务状态**：使用 `vTaskList()` 查看各任务状态，发现 `app_task` 处于 `Blocked`，而 `wifi_event_task` 处于 `Running` 或 `Ready`。 2. **检查事件组值**：通过 `xEventGroupGetBits()` 发现事件位未置位，但日志显示 WiFi 事件已触发。 3. **分析锁竞争**：在 `xEventGroupSetBits()` 前后添加 GPIO 翻转，用逻辑分析仪测量，发现 `wifi_event_task` 在设置事件位时被阻塞约 200ms，期间 `app_task` 无法获得锁。 4. **定位根因**：`wifi_event_task` 在设置事件位前调用了 `esp_netif_get_netif_impl_name()`，该函数内部获取了全局锁，而该锁被低优先级 TCP/IP 任务持有，导致高优先级任务等待，进而阻塞事件组锁。 # 解决方案与代码示例 ## 方案一：调整任务优先级 - 将 `app_task` 优先级提升至高于 WiFi 协议栈任务（如 24），但可能影响 WiFi 稳定性，不推荐。 - 更合理：将事件组操作放在独立的高优先级任务中，仅用于同步，实际业务逻辑在低优先级任务处理。 ## 方案二：使用二值信号量替代事件组（简化场景） - 若只需单一事件，用 `xSemaphoreGiveFromISR()` 或 `xSemaphoreGive()` 替代，减少锁粒度。 ## 方案三：避免在 WiFi 回调中执行复杂操作 - 在 `wifi_event_task` 中仅设置事件位，不调用可能阻塞的 API。 ## 完整代码示例 ```c // 事件组句柄 EventGroupHandle_t wifi_event_group; #define WIFI_CONNECTED_BIT (1 << 0) // WiFi 事件处理任务（优先级 23） void wifi_event_task(void *arg) { // 注册事件回调（此处简化） while (1) { // 等待事件队列（实际使用 esp_event_loop） if (got_ip) { // 仅设置事件位，不调用其他 API xEventGroupSetBits(wifi_event_group, WIFI_CONNECTED_BIT); } vTaskDelay(pdMS_TO_TICKS(10)); } } // 用户任务（优先级 12） void app_task(void *arg) { EventBits_t bits = xEventGroupWaitBits(wifi_event_group, WIFI_CONNECTED_BIT, pdTRUE, pdTRUE, pdMS_TO_TICKS(5000)); if (bits & WIFI_CONNECTED_BIT) { // 业务逻辑 } else { ESP_LOGE("APP", "Timeout waiting for WiFi"); } } void app_main() { wifi_event_group = xEventGroupCreate(); xTaskCreatePinnedToCore(wifi_event_task, "wifi_evt", 4096, NULL, 23, NULL, 0); xTaskCreatePinnedToCore(app_task, "app", 4096, NULL, 12, NULL, 1); } ``` ## 改进后的代码（避免优先级反转） ```c // 使用互斥锁保护事件组操作，但锁内不调用阻塞函数 static SemaphoreHandle_t event_lock; void safe_set_event(EventGroupHandle_t eg, EventBits_t bits) { xSemaphoreTake(event_lock, portMAX_DELAY); xEventGroupSetBits(eg, bits); xSemaphoreGive(event_lock); } // 在 wifi_event_task 中调用 safe_set_event ``` # 注意事项 - **避免在事件组操作中调用阻塞 API**：如 `vTaskDelay()`、`esp_netif_*` 等，会延长锁持有时间。 - **使用 `xEventGroupSetBitsFromISR()`**：如果事件来自中断，使用 ISR 版本，减少上下文切换。 - **监控任务栈和堆**：事件组操作可能涉及动态内存，确保栈足够。 - **启用 FreeRTOS 跟踪**：使用 `configUSE_TRACE_FACILITY` 和 `vTaskList()` 辅助调试。 - **考虑使用 `xTaskNotify`**：对于简单同步，任务通知更轻量，且支持双核。 # 总结 ESP32 双核环境下，WiFi 协议栈的高优先级任务与用户任务共享事件组时，容易因锁竞争导致优先级反转。通过理解调度机制、合理设计任务优先级和事件组操作，可有效避免此类问题。建议在开发中遵循“事件组操作最小化”原则，并利用系统跟踪工具快速定位。