引言

在单核 FreeRTOS 中，优先级反转的经典场景是：低优先级任务持有互斥量，高优先级任务等待，而中优先级任务抢占 CPU，导致高优先级任务被无限期阻塞。但在 ESP32 双核环境下，情况变得复杂：两个核心独立调度，任务可以绑定到特定核心，共享资源（如外设、全局变量）的访问需要跨核同步。此时，优先级反转可能以更隐蔽的方式出现——例如，高优先级任务在 Core 0 上等待一个由 Core 1 上低优先级任务持有的锁，而 Core 1 上的中优先级任务不断抢占低优先级任务，但高优先级任务却无法通过普通优先级继承机制获得帮助，因为调度器是每核独立的。

双核调度的特殊性

ESP32 使用 Xtensa 双核处理器，FreeRTOS 为每个核心维护独立的就绪列表和调度器。任务可以通过 xTaskCreatePinnedToCore 指定运行核心，或使用 xTaskCreate 让调度器自动分配（通常固定到 Core 0）。关键点：

  • 每个核心的调度器只考虑本核心的就绪任务，优先级是局部的。
  • 互斥量（Mutex）的优先级继承机制在跨核场景下可能失效，因为持有者可能不在等待者的核心上。
  • 中断服务程序（ISR）可以在任意核心触发，但 FreeRTOS 的同步原语（如信号量）在 ISR 中只能使用 FromISR 版本，且可能唤醒其他核心的任务。

隐蔽触发场景：跨核互斥量 + 核间中断

场景描述

假设系统中有三个任务：

  • 任务 A（优先级 10，绑定 Core 0）：高优先级，处理传感器数据。
  • 任务 B（优先级 5，绑定 Core 1）：低优先级，负责写日志到 SD 卡，使用互斥量保护 SD 卡驱动。
  • 任务 C（优先级 7，绑定 Core 1）：中优先级，执行网络协议栈，频繁占用 CPU。

任务 A 和任务 B 共享一个互斥量 sd_mutex，用于访问 SD 卡。正常流程：任务 A 偶尔需要读取 SD 卡上的配置，因此尝试获取 sd_mutex。如果任务 B 正在写日志，任务 A 会阻塞等待。

触发过程

  1. 任务 B 在 Core 1 上获取 sd_mutex，开始写日志。
  2. 任务 A 在 Core 0 上尝试获取 sd_mutex，失败，进入阻塞状态。FreeRTOS 的互斥量优先级继承机制会尝试提升任务 B 的优先级到 10（与任务 A 相同）。
  3. 但是，任务 B 运行在 Core 1 上，而 Core 1 的调度器此时正在运行任务 C（优先级 7）。由于任务 B 的优先级被提升到 10，理论上 Core 1 应该立即切换到任务 B。然而，如果任务 C 正在执行一个长临界区（例如，通过 taskENTER_CRITICAL 关闭了 Core 1 的中断），或者任务 C 持有另一个自旋锁，那么任务 B 无法被调度。
  4. 更隐蔽的是，如果任务 C 在临界区内调用了 vTaskDelay 或等待某个事件，而该事件由 Core 0 上的任务 A 产生（但任务 A 已阻塞在 sd_mutex 上），则形成死锁环：任务 A 等任务 B，任务 B 等任务 C，任务 C 等任务 A。

在这个场景中，优先级继承看似生效（任务 B 的优先级被提升），但实际调度被核间临界区或自旋锁阻塞，导致高优先级任务 A 长时间无法运行。这种问题在单核中不会出现，因为单核上临界区不会阻塞其他核心的调度。

调试手法

1. 使用 Tracealyzer 可视化调度

Tracealyzer 是 FreeRTOS 的官方可视化工具，可以记录任务状态、互斥量操作和调度事件。在 ESP32 上，可以通过以下步骤集成：

  • 在 FreeRTOSConfig.h 中启用 configUSE_TRACE_FACILITY 和 configUSE_STATS_FORMATTING_FUNCTIONS。
  • 使用 Tracealyzer 的库（如 trcKernelPort.h）并初始化。
  • 运行系统后，导出跟踪文件，在 PC 上分析。

在 Tracealyzer 的时间线中，可以清晰地看到任务 A 的阻塞状态、任务 B 的优先级变化以及任务 C 的临界区占用。重点观察：

  • 任务 A 的阻塞时间是否异常长。
  • 任务 B 的优先级是否被提升，但实际运行时间很少。
  • 任务 C 的临界区是否跨越了任务 A 的等待周期。

2. 内核钩子函数

FreeRTOS 提供了多个钩子函数，可以自定义调试逻辑。例如，在 vApplicationMutexTake 和 vApplicationMutexGive 钩子中记录互斥量操作：

void vApplicationMutexTake( Mutex_t *pxMutex ) {
    // 记录当前任务、核心、时间戳
    printf("Mutex take: %s on core %d, time %d\n",
           pcTaskGetName(NULL), xPortGetCoreID(), xTaskGetTickCount());
}

void vApplicationMutexGive( Mutex_t *pxMutex ) {
    printf("Mutex give: %s on core %d, time %d\n",
           pcTaskGetName(NULL), xPortGetCoreID(), xTaskGetTickCount());
}

同时，可以启用 configUSE_TRACE_HOOKS 并实现 vTraceTaskSwitch 来记录任务切换：

void vTraceTaskSwitch( void ) {
    TaskHandle_t xCurrent = xTaskGetCurrentTaskHandle();
    printf("Switch to %s on core %d\n", pcTaskGetName(xCurrent), xPortGetCoreID());
}

通过日志，可以观察到任务 B 被提升优先级后，是否立即获得 CPU，以及任务 C 的临界区何时退出。

3. 使用 uxTaskGetSystemState 和 vTaskList

在运行时，可以周期性地调用 vTaskList 打印所有任务的状态，包括优先级、状态和栈高水位。结合核心 ID，可以判断任务是否被错误地阻塞：

char buffer[512];
vTaskList(buffer);
printf("Task List:\n%s\n", buffer);

注意，vTaskList 会挂起调度器，可能影响实时性，建议在调试时使用。

解决方案

针对上述场景，推荐以下措施：

  • 使用带超时的互斥量获取：xSemaphoreTake(sd_mutex, pdMS_TO_TICKS(100))，避免无限期阻塞。
  • 避免在临界区中调用阻塞 API：确保任务 C 的临界区尽量短，且不包含 vTaskDelay 或信号量等待。
  • 使用递归互斥量或队列：如果共享资源需要跨核访问，考虑使用队列或流缓冲区，它们内部实现了更健壮的同步。
  • 绑定任务到同一核心：如果可能，将共享资源的任务绑定到同一核心，以利用单核的优先级继承。

完整代码示例

以下是一个简化的演示代码，模拟上述场景（省略 SD 卡驱动，用全局变量代替）：

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

SemaphoreHandle_t sd_mutex;

void taskA(void *arg) {
    while (1) {
        // 尝试获取互斥量，超时 100ms
        if (xSemaphoreTake(sd_mutex, pdMS_TO_TICKS(100)) == pdTRUE) {
            printf("Task A: got mutex\n");
            // 模拟读取配置
            vTaskDelay(pdMS_TO_TICKS(50));
            xSemaphoreGive(sd_mutex);
        } else {
            printf("Task A: timeout waiting for mutex\n");
        }
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

void taskB(void *arg) {
    while (1) {
        xSemaphoreTake(sd_mutex, portMAX_DELAY);
        printf("Task B: writing log\n");
        // 模拟长时间写操作
        vTaskDelay(pdMS_TO_TICKS(200));
        xSemaphoreGive(sd_mutex);
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

void taskC(void *arg) {
    while (1) {
        // 进入临界区，模拟长时间占用 CPU
        taskENTER_CRITICAL();
        // 模拟网络处理，不调用阻塞 API
        for (volatile int i = 0; i < 100000; i++);
        taskEXIT_CRITICAL();
        vTaskDelay(pdMS_TO_TICKS(5));
    }
}

void app_main() {
    sd_mutex = xSemaphoreCreateMutex();
    xTaskCreatePinnedToCore(taskA, "TaskA", 2048, NULL, 10, NULL, 0);
    xTaskCreatePinnedToCore(taskB, "TaskB", 2048, NULL, 5, NULL, 1);
    xTaskCreatePinnedToCore(taskC, "TaskC", 2048, NULL, 7, NULL, 1);
}

在运行此代码时，任务 A 可能会频繁超时，因为任务 C 的临界区阻塞了 Core 1 的调度，导致任务 B 无法及时释放互斥量。通过添加钩子函数，可以观察到任务 B 的优先级被提升，但实际运行时间很少。

注意事项

  • 临界区与互斥量的区别：taskENTER_CRITICAL 会关闭当前核心的中断，但不会影响其他核心。在双核中，跨核共享资源应使用自旋锁或互斥量，而不是临界区。
  • 优先级继承的局限性：FreeRTOS 的互斥量优先级继承只提升持有者的优先级，但如果持有者被其他核心的任务阻塞，则继承可能无效。
  • 调试工具的开销：Tracealyzer 和钩子函数会引入额外开销，可能改变时序，建议在调试版本中启用，发布版本关闭。
  • 使用 xPortGetCoreID()：在 ESP32 中，可以通过该函数获取当前核心 ID，用于日志分析。

总结

ESP32 双核环境下的优先级反转问题比单核更隐蔽，往往涉及跨核调度、临界区和中断交互。通过理解双核调度的独立性，结合 Tracealyzer 和内核钩子，可以快速定位问题。实际开发中，应尽量避免跨核共享资源，或使用更高级的同步机制，并始终为互斥量获取设置超时，以增强系统的健壮性。