引言

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 已连接。

排查步骤

打印任务状态：使用 vTaskList() 查看各任务状态，发现 app_task 处于 Blocked，而 wifi_event_task 处于 Running 或 Ready。
检查事件组值：通过 xEventGroupGetBits() 发现事件位未置位，但日志显示 WiFi 事件已触发。
分析锁竞争：在 xEventGroupSetBits() 前后添加 GPIO 翻转，用逻辑分析仪测量，发现 wifi_event_task 在设置事件位时被阻塞约 200ms，期间 app_task 无法获得锁。
定位根因：wifi_event_task 在设置事件位前调用了 esp_netif_get_netif_impl_name()，该函数内部获取了全局锁，而该锁被低优先级 TCP/IP 任务持有，导致高优先级任务等待，进而阻塞事件组锁。

解决方案与代码示例

方案一：调整任务优先级

将 app_task 优先级提升至高于 WiFi 协议栈任务（如 24），但可能影响 WiFi 稳定性，不推荐。
更合理：将事件组操作放在独立的高优先级任务中，仅用于同步，实际业务逻辑在低优先级任务处理。

方案二：使用二值信号量替代事件组（简化场景）

若只需单一事件，用 xSemaphoreGiveFromISR() 或 xSemaphoreGive() 替代，减少锁粒度。

方案三：避免在 WiFi 回调中执行复杂操作

在 wifi_event_task 中仅设置事件位，不调用可能阻塞的 API。

完整代码示例

// 事件组句柄
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);
}

改进后的代码（避免优先级反转）

// 使用互斥锁保护事件组操作，但锁内不调用阻塞函数
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 协议栈的高优先级任务与用户任务共享事件组时，容易因锁竞争导致优先级反转。通过理解调度机制、合理设计任务优先级和事件组操作，可有效避免此类问题。建议在开发中遵循“事件组操作最小化”原则，并利用系统跟踪工具快速定位。

ESP32 双核环境下 FreeRTOS 任务与事件组在 WiFi 协议栈抢占下的优先级反转排查实战

引言