引言

在 ESP32 开发中，FreeRTOS 运行于双核（PRO_CPU 和 APP_CPU）之上，WiFi 协议栈会创建多个高优先级任务（如 wl2_tcb、ipc0、tiT）。当用户任务使用事件组（Event Group）进行同步时，若未考虑多核调度和优先级反转，可能导致任务永久阻塞或系统响应异常。本文基于一个实际项目中的故障，详细剖析问题根源并给出解决方案。

问题现象

某 IoT 设备使用 ESP32 采集传感器数据，并通过 WiFi 上传。代码中，一个低优先级任务（优先级 1）负责读取传感器，一个高优先级任务（优先级 5）负责处理数据并上传。两者通过事件组同步：传感器任务完成采集后设置事件位，处理任务等待该事件位。

现象：设备运行数小时后，处理任务偶尔卡死，看门狗超时重启。日志显示处理任务在 xEventGroupWaitBits 处阻塞，但传感器任务已设置事件位。

原理分析

1. FreeRTOS 多核调度机制

ESP32 使用对称多处理（SMP）FreeRTOS，两个核独立运行调度器。任务可被固定到某个核（xTaskCreatePinnedToCore），也可由调度器动态分配。默认情况下，WiFi 协议栈任务运行在 PRO_CPU，且优先级较高（通常为 18-25）。

2. 事件组与优先级反转

事件组是 FreeRTOS 提供的同步原语，其内部使用临界区保护。当任务调用 xEventGroupWaitBits 时，若事件位未满足，任务会进入阻塞态，并加入事件组的等待列表。

优先级反转发生在：

低优先级任务持有某个资源（如互斥锁或临界区），而高优先级任务等待该资源。
在事件组场景中，若设置事件位的任务（低优先级）被更高优先级的 WiFi 任务抢占，而等待事件位的任务（高优先级）无法获得 CPU，就会形成间接优先级反转。

3. WiFi 协议栈的抢占行为

WiFi 协议栈任务（如 wl2_tcb）优先级高达 18，且运行时间较长（处理网络包、TCP/IP 栈）。当传感器任务正在执行 xEventGroupSetBits 时，若被 WiFi 任务抢占，且该 WiFi 任务在 PRO_CPU 上运行，而传感器任务被固定到 PRO_CPU，则传感器任务必须等待 WiFi 任务完成才能继续。

更隐蔽的是，事件组操作本身是临界区保护的，但临界区只保护单个操作，不保护整个“设置-唤醒”序列。若传感器任务在设置事件位后、进入阻塞前被抢占，处理任务可能已经醒来但发现事件位未设置（因为设置操作尚未完成），从而再次阻塞，造成死锁。

实战排查步骤

1. 复现与日志

使用 vTaskDelay 模拟传感器采集时间，增加复现概率。
在关键位置添加 ESP_LOGI 打印任务状态和事件组值。
使用 xEventGroupGetBits 读取事件组当前值。

2. 分析任务调度

通过 vTaskList 或 vTaskGetRunTimeStats 查看任务状态和 CPU 占用。发现 wl2_tcb 占用大量 CPU，且传感器任务频繁被抢占。

3. 定位优先级反转

在传感器任务中，在 xEventGroupSetBits 前后添加打印，发现设置操作被延迟（打印时间戳差异大）。进一步使用 tracealyzer 或 SystemView 工具，直观看到抢占序列。

解决方案

方案一：调整任务优先级与核绑定

将传感器任务绑定到 APP_CPU，避免与 WiFi 协议栈（PRO_CPU）竞争。
适当提高传感器任务优先级（如 3），但不要超过 WiFi 任务，以免影响网络稳定性。

// 创建任务时指定核
xTaskCreatePinnedToCore(sensor_task, "sensor", 4096, NULL, 3, &sensor_handle, APP_CPU);

方案二：使用互斥锁保护事件组操作

在设置事件位和等待事件位之间加入互斥锁，确保原子性。但注意，互斥锁本身也可能引发优先级反转，需使用优先级继承。

SemaphoreHandle_t xMutex;

void sensor_task(void *arg) {
    while (1) {
        // 采集数据
        xSemaphoreTake(xMutex, portMAX_DELAY);
        xEventGroupSetBits(xEventGroup, BIT0);
        xSemaphoreGive(xMutex);
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

void process_task(void *arg) {
    while (1) {
        xSemaphoreTake(xMutex, portMAX_DELAY);
        EventBits_t bits = xEventGroupWaitBits(xEventGroup, BIT0, pdTRUE, pdFALSE, portMAX_DELAY);
        xSemaphoreGive(xMutex);
        if (bits & BIT0) {
            // 处理数据
        }
    }
}

方案三：使用队列代替事件组

队列天然具备阻塞和互斥特性，更适合生产者-消费者模型。

QueueHandle_t xQueue;

void sensor_task(void *arg) {
    int data;
    while (1) {
        data = read_sensor();
        xQueueSend(xQueue, &data, portMAX_DELAY);
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

void process_task(void *arg) {
    int data;
    while (1) {
        xQueueReceive(xQueue, &data, portMAX_DELAY);
        // 处理数据
    }
}

方案四：使用任务通知（Task Notification）

任务通知比事件组更轻量，且支持直接唤醒指定任务，减少优先级反转窗口。

TaskHandle_t process_handle;

void sensor_task(void *arg) {
    while (1) {
        // 采集数据
        xTaskNotifyGive(process_handle);
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

void process_task(void *arg) {
    while (1) {
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
        // 处理数据
    }
}

完整代码示例（方案四）

#include <stdio.h>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "esp_log.h"

static const char *TAG = "demo";
static TaskHandle_t process_handle;

static void sensor_task(void *arg) {
    while (1) {
        // 模拟传感器采集
        vTaskDelay(pdMS_TO_TICKS(500));
        ESP_LOGI(TAG, "Sensor data ready");
        // 通知处理任务
        xTaskNotifyGive(process_handle);
    }
}

static void process_task(void *arg) {
    while (1) {
        // 等待通知，超时10秒防止死锁
        if (ulTaskNotifyTake(pdTRUE, pdMS_TO_TICKS(10000)) == pdPASS) {
            ESP_LOGI(TAG, "Processing data...");
            // 模拟处理
            vTaskDelay(pdMS_TO_TICKS(100));
        } else {
            ESP_LOGW(TAG, "Timeout waiting for sensor");
        }
    }
}

void app_main(void) {
    // 创建处理任务，绑定到 APP_CPU，优先级5
    xTaskCreatePinnedToCore(process_task, "process", 4096, NULL, 5, &process_handle, APP_CPU);
    // 创建传感器任务，绑定到 APP_CPU，优先级3
    xTaskCreatePinnedToCore(sensor_task, "sensor", 4096, NULL, 3, NULL, APP_CPU);
}

注意事项

避免在中断中调用事件组操作：ESP32 的 WiFi 中断可能引发优先级反转，建议使用 xEventGroupSetBitsFromISR 并配合定时器。
合理设置超时：所有阻塞调用都应设置超时，防止永久阻塞。
监控任务栈大小：任务通知和事件组使用栈空间，栈溢出可能导致未定义行为。
使用双核时注意数据一致性：跨核访问共享变量需使用原子操作或临界区。
测试覆盖：在压力测试（长时间运行、高网络负载）下验证修复效果。

总结

ESP32 多核环境下，WiFi 协议栈的高优先级任务会显著影响用户任务的调度，导致事件组同步出现优先级反转。通过合理绑定核心、调整优先级、使用队列或任务通知，可以有效避免此类问题。本文提供的排查思路和代码示例，希望能帮助开发者快速定位并解决类似故障。在实际项目中，建议结合调试工具（如 SystemView）进行深入分析，确保系统稳定运行。

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

引言