FreeRTOS在ESP32 Cortex-M4F启动失败：xPortStartScheduler未清BASEPRI

在ESP32的ARM Cortex-M4F核心上运行FreeRTOS时，xPortStartScheduler内部执行失败，问题出在prvPortStartFirstTask函数的svc 0指令上。

相关代码如下：

static void prvPortStartFirstTask( void )
{
/* Start the first task.  This also clears the bit that indicates the FPU is
 * in use in case the FPU was used before the scheduler was started - which
 * would otherwise result in the unnecessary leaving of space in the SVC stack
 * for lazy saving of FPU registers. */
__asm volatile (
    " ldr r0, =0xE000ED08   \n"/* Use the NVIC offset register to locate the stack. */
    " ldr r0, [r0]          \n"
    " ldr r0, [r0]          \n"
    " msr msp, r0           \n"/* Set the msp back to the start of the stack. */
    " mov r0, #0            \n"
    " msr control, r0       \n"
    " cpsie i               \n"/* Globally enable interrupts. */
    " cpsie f               \n"
    " dsb                   \n"
    " isb                   \n"
    " svc 0                 \n"/* System call to start first task. */
    " nop                   \n"
    ".ltorg                \n"
    );
}

问题原因 #

svc 0调用失败是因为此时BASEPRI寄存器的值不为0——调用xTaskCreate()时，BASEPRI被设置为configMAX_SYSCALL_INTERRUPT_PRIORITY（值为0xA0），且该操作在启动调度器前未被恢复。手动将BASEPRI设为0可解决问题，但此前使用FreeRTOS时无需手动处理。

执行流程 #

Init_stuff..
xTaskCreate(..);  // 设置BASEPRI = 0xA0 (configMAX_SYSCALL_INTERRUPT_PRIORITY)
vTaskStartScheduler();
-> xPortStartScheduler(...)
   -> prvPortStartFirstTask() // 因BASEPRI=0xA0导致svc 0失败

疑惑：BASEPRI应该在何处被恢复为0？

问题分析与解决 #

首先明确：Cortex-M的BASEPRI寄存器只会屏蔽优先级数值≥设定值的中断，不会影响svc这类异常的触发——你的场景中svc 0失败，本质是xTaskCreate执行后BASEPRI没有被正确恢复到0，这不符合FreeRTOS的标准行为。

正常流程下的BASEPRI处理 #

标准FreeRTOS Cortex-M端口中，xTaskCreate内部会通过taskENTER_CRITICAL()进入临界区（设置BASEPRI为configMAX_SYSCALL_INTERRUPT_PRIORITY），操作完成后会调用taskEXIT_CRITICAL()恢复BASEPRI到调用前的值（通常是0）。所以正常情况下，vTaskStartScheduler()执行前BASEPRI应该已经回到0。

问题可能的根源 #

1. 代码中手动调用了taskENTER_CRITICAL()但未配对调用taskEXIT_CRITICAL()，导致BASEPRI被永久设置为0xA0；
2. 使用的ESP32 FreeRTOS端口存在bug，xTaskCreate的临界区退出逻辑异常；
3. 初始化代码中其他地方修改了BASEPRI且未恢复。

正确的恢复位置 #

方案1：修复临界区配对问题

检查初始化代码，确保所有taskENTER_CRITICAL()都有对应的taskEXIT_CRITICAL()，尤其是xTaskCreate前后的自定义代码。

方案2：在启动调度器前强制恢复

如果暂时无法定位临界区问题，可以在调用vTaskStartScheduler()前手动恢复BASEPRI：

// 在vTaskStartScheduler()前添加
taskEXIT_CRITICAL();
// 或者直接操作寄存器
__set_BASEPRI(0);

方案3：修改prvPortStartFirstTask汇编代码

在prvPortStartFirstTask的汇编中，执行svc 0前强制设置BASEPRI为0，确保异常能正常触发：

" mov r0, #0            \n"
" msr control, r0       \n"
" mov r0, #0            \n"  // 添加这两行代码
" msr basepri, r0       \n"
" cpsie i               \n"/* Globally enable interrupts. */

为什么之前使用无需手动处理 #

标准FreeRTOS端口会严格维护临界区的进出逻辑，自动保存和恢复BASEPRI，只有当自定义代码破坏了这个逻辑，或者端口实现有问题时，才会出现BASEPRI未恢复的情况。

内容的提问来源于stack exchange，提问作者JakobJ