ESP32 双核模式下 FreeRTOS 任务与 WiFi 协议栈争用 CPU 的优先级反转排查实战

1. 背景与问题现象

在 ESP32 开发中，我们常将业务逻辑放在 FreeRTOS 任务中，而 WiFi 协议栈（基于 lwIP）作为后台任务运行。默认情况下，ESP32 的 WiFi 协议栈任务（如 wifi_task）优先级为 23，而用户任务若设置更高优先级（如 24），则可能抢占 WiFi 任务。但若用户任务中调用了阻塞型 WiFi API（如 esp_wifi_connect() 或 lwIP 的 socket 操作），且这些 API 内部依赖低优先级任务完成，则可能引发优先级反转：高优先级任务等待低优先级任务释放资源，而低优先级任务被中优先级任务抢占，导致系统卡死。

2. 双核调度与优先级反转原理

2.1 ESP32 双核调度机制

ESP32 使用 Xtensa 双核，FreeRTOS 支持对称多处理（SMP）。每个核独立运行调度器，任务可指定运行核（通过 xTaskCreatePinnedToCore）。WiFi 协议栈默认运行在 Core 0，用户任务默认在 Core 1。但若任务未绑定核，调度器会动态分配，导致跨核资源竞争。

2.2 优先级反转场景

  • 高优先级任务（H）：优先级 24，处理网络事件。
  • 中优先级任务（M）：优先级 20，执行耗时计算。
  • 低优先级任务（L）：优先级 10，负责 WiFi 连接状态更新。

若 H 任务调用 esp_wifi_connect()，该 API 内部会向 WiFi 协议栈发送消息，并等待协议栈处理完成。协议栈任务（优先级 23）收到消息后，可能需要 L 任务（优先级 10）的配合（如更新状态）。此时若 M 任务（优先级 20）抢占 L 任务，则协议栈无法完成处理，H 任务一直阻塞，形成反转。

3. 实战案例：WiFi 连接超时问题

3.1 问题描述

某项目中，主任务（优先级 24）周期性地调用 esp_wifi_connect() 重连 WiFi，但系统运行一段时间后，重连超时，且主任务卡死。通过 vTaskList 查看任务状态，发现主任务处于阻塞态，而 WiFi 协议栈任务和低优先级状态任务均处于就绪态。

3.2 排查步骤

  1. 打印任务状态：使用 vTaskList 和 vTaskGetRunTimeStats 观察各任务优先级和运行时间。
  2. 定位阻塞点：在 esp_wifi_connect() 前后添加日志，发现阻塞发生在 API 内部。
  3. 分析依赖链：查阅 ESP-IDF 源码，发现 esp_wifi_connect() 会等待 wifi_task 处理事件，而 wifi_task 可能等待 esp_netif 任务（优先级 18）更新状态，该任务又依赖低优先级任务。
  4. 确认优先级反转：通过 uxTaskPriorityGet 确认各任务优先级，发现中优先级任务（优先级 20）频繁抢占低优先级任务。

3.3 解决方案

方案一：调整任务优先级

将低优先级任务提升至高于中优先级任务（如设为 21），确保其不被抢占。但需谨慎，避免影响其他逻辑。

// 将状态更新任务优先级从 10 提升到 21
xTaskCreatePinnedToCore(status_task, "status", 4096, NULL, 21, &status_handle, 1);

方案二：使用互斥锁保护共享资源

若反转源于共享资源（如全局标志），使用互斥锁并设置优先级继承。FreeRTOS 互斥锁支持优先级继承，可临时提升低优先级任务优先级。

SemaphoreHandle_t xMutex = xSemaphoreCreateMutex();

// 在低优先级任务中获取锁
if (xSemaphoreTake(xMutex, portMAX_DELAY) == pdTRUE) {
    // 更新状态
    xSemaphoreGive(xMutex);
}

// 在高优先级任务中获取锁（自动继承优先级）
if (xSemaphoreTake(xMutex, portMAX_DELAY) == pdTRUE) {
    // 处理网络事件
    xSemaphoreGive(xMutex);
}

方案三：绑定任务到指定核心

将 WiFi 协议栈任务绑定到 Core 0，用户高优先级任务绑定到 Core 1，避免跨核竞争。但需注意，若两个核同时访问同一资源，仍需同步。

// 绑定 WiFi 任务到 Core 0（默认）
// 绑定用户任务到 Core 1
xTaskCreatePinnedToCore(user_task, "user", 8192, NULL, 24, &user_handle, 1);

方案四：使用事件组代替阻塞等待

若高优先级任务只是等待连接完成，可改为非阻塞方式，通过事件组通知。

EventGroupHandle_t xEventGroup = xEventGroupCreate();
#define WIFI_CONNECTED_BIT (1 << 0)

// 高优先级任务中
EventBits_t bits = xEventGroupWaitBits(xEventGroup, WIFI_CONNECTED_BIT, pdFALSE, pdTRUE, pdMS_TO_TICKS(5000));
if (bits & WIFI_CONNECTED_BIT) {
    // 连接成功
}

// 低优先级任务中，连接成功后设置事件位
xEventGroupSetBits(xEventGroup, WIFI_CONNECTED_BIT);

3.4 完整代码示例

以下为综合解决方案的代码框架：

#include <stdio.h>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "freertos/semphr.h"
#include "esp_wifi.h"
#include "esp_event.h"

SemaphoreHandle_t xMutex;

// 低优先级任务：更新 WiFi 状态
void status_task(void *arg) {
    while (1) {
        if (xSemaphoreTake(xMutex, portMAX_DELAY)) {
            // 模拟状态更新
            printf("Status updated\n");
            xSemaphoreGive(xMutex);
        }
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

// 中优先级任务：耗时计算
void compute_task(void *arg) {
    while (1) {
        // 模拟计算，不访问共享资源
        for (int i = 0; i < 100000; i++);
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

// 高优先级任务：WiFi 连接
void wifi_task_high(void *arg) {
    while (1) {
        // 获取互斥锁（优先级继承生效）
        if (xSemaphoreTake(xMutex, pdMS_TO_TICKS(1000))) {
            esp_wifi_connect();
            xSemaphoreGive(xMutex);
        }
        vTaskDelay(pdMS_TO_TICKS(5000));
    }
}

void app_main() {
    xMutex = xSemaphoreCreateMutex();

    // 创建任务，绑定核心
    xTaskCreatePinnedToCore(status_task, "status", 2048, NULL, 21, NULL, 1);
    xTaskCreatePinnedToCore(compute_task, "compute", 2048, NULL, 20, NULL, 1);
    xTaskCreatePinnedToCore(wifi_task_high, "wifi_high", 4096, NULL, 24, NULL, 1);
}

4. 注意事项

  • 优先级设置需全局规划：避免出现高、中、低三级任务且中间任务频繁抢占低优先级任务的情况。
  • 互斥锁优先级继承：FreeRTOS 互斥锁默认支持优先级继承，但需确保所有共享资源访问均使用同一把锁。
  • 避免在回调中阻塞：WiFi 事件回调中不要调用阻塞 API，应通过队列或事件组通知任务处理。
  • 使用双核时注意缓存一致性：跨核共享变量需使用 volatile 或原子操作，必要时使用 portMUX_TYPE 自旋锁。
  • 调试工具：利用 vTaskList、vTaskGetRunTimeStats 和 esp_task_wdt 观察任务状态，可快速定位阻塞点。

5. 总结

ESP32 双核模式下，FreeRTOS 任务与 WiFi 协议栈的优先级反转问题隐蔽且影响严重。通过理解调度机制、合理设置优先级、使用互斥锁和事件组，以及绑定核心，可以有效避免此类问题。实战中，建议先打印任务状态，再分析依赖链，最后选择最小侵入的解决方案。希望本文能帮助开发者少走弯路。