1. FreeRTOS在STM32上的工程化移植路径

FreeRTOS作为轻量级实时操作系统，在资源受限的STM32平台上具有极高的工程适配性。但其移植过程并非简单的库文件添加，而是一套涉及启动流程重构、中断向量重定向、系统时钟协同、堆内存管理及任务调度初始化的完整工程实践。本节将基于STM32F407系列芯片（以STM32F407ZGT6为典型代表）展开，所有配置逻辑均严格遵循ST官方HAL库设计规范与FreeRTOS v10.4.6内核行为。

1.1 移植本质：从裸机到RTOS的执行模型跃迁

裸机程序运行于单一上下文，主循环（main loop）是唯一控制流；而FreeRTOS引入了抢占式多任务调度器，其核心在于 中断驱动的上下文切换机制 。当SysTick定时器产生中断时，FreeRTOS内核接管CPU控制权，保存当前任务寄存器状态（R0–R12、LR、PC、xPSR），加载下一高优先级就绪任务的寄存器状态，实现任务间无缝跳转。这一过程要求：

• SysTick必须独立于HAL库系统时钟配置 ：HAL库默认使用SysTick作为 HAL_Delay() 延时基准，若FreeRTOS也使用同一SysTick，则二者时钟源冲突，导致 HAL_Delay() 失效或任务调度异常。因此，必须将FreeRTOS的系统节拍（tick）源切换至独立硬件定时器（如TIM6），或明确禁用HAL库对SysTick的占用。
• 中断向量表必须重映射至FreeRTOS管理区域 ：FreeRTOS提供 vPortSVCHandler （SVC调用）、 xPortPendSVHandler （PendSV上下文切换）、 xPortSysTickHandler （SysTick节拍处理）三个关键中断服务函数。这些函数地址需写入向量表对应位置，否则任何系统调用（如 xTaskCreate() ）或节拍中断均无法触发内核响应。
• 堆内存管理策略必须显式声明 ：FreeRTOS提供五种堆内存分配方案（heap_1.c至heap_5.c）。在STM32工程中， heap_4.c 为最常用选择——它支持内存块合并，可有效缓解碎片化，且其内部维护的空闲块链表结构与STM32片上SRAM物理布局高度契合。

1.2 手动移植的关键修正点：一个真实调试案例

在早期手动移植过程中，一个高频错误源于对 configUSE_TIMERS 宏的误用。当该宏定义为1时，FreeRTOS会启用软件定时器功能，其底层依赖 xTimerDaemonTask 守护任务。该任务默认优先级为 configTIMER_TASK_PRIORITY （通常设为3），若未在 FreeRTOSConfig.h 中明确定义此宏，编译器将采用默认值0，导致守护任务与空闲任务（idle task）同优先级，引发调度死锁。

更隐蔽的问题出现在 HardFault_Handler 的重定向。原始HAL库工程中，该异常处理函数位于 stm32f4xx_it.c ，内容为：

void HardFault_Handler(void)
{
  while (1)
  {
  }
}

若未将其替换为FreeRTOS提供的 HardFault_Handler （定义于 portable/GCC/ARM_CM4F/port.c ），则任何内核错误（如栈溢出、非法内存访问）均无法被 vApplicationMallocFailedHook 或 vApplicationStackOverflowHook 捕获，系统直接陷入死循环，调试窗口仅显示“HardFault”而无任何线索。

实际项目中，我们通过以下三步完成修复：
1. 在 stm32f4xx_it.c 中注释掉原有 HardFault_Handler ；
2. 在 FreeRTOSConfig.h 中启用钩子函数：
c #define configUSE_MALLOC_FAILED_HOOK 1 #define configUSE_STACK_OVERFLOW_HOOK 1
3. 实现钩子函数（通常置于 main.c ）：
```c
void vApplicationMallocFailedHook( void )
{
__BKPT(); // 触发断点，便于JTAG调试器捕获
}

void vApplicationStackOverflowHook( TaskHandle_t xTask, signed char *pcTaskName )
{
(void)xTask;
(void)pcTaskName;
__BKPT();
}
```

此修正使所有内存分配失败与栈溢出事件均可在调试器中准确定位，大幅提升开发效率。

1.3 STM32CubeMX自动生成工程的深度解析

STM32CubeMX作为ST官方图形化配置工具，其FreeRTOS组件生成逻辑已高度成熟。但开发者必须理解其背后的技术契约，而非盲目依赖GUI操作。

1.3.1 MCU选型与系统时钟配置的硬约束

以STM32F407ZGT6为例，其最高主频为168MHz，需通过PLL倍频实现。CubeMX中“System Core → RCC”配置页的关键参数如下：
- HSE Value (MHz) ：必须与实际晶振频率严格一致。常见开发板采用8MHz外部晶振（如正点原子、野火），若误设为25MHz，PLL输出频率计算错误，导致USART波特率偏差超限、ADC采样时序紊乱。
- SYSCLK Frequency (MHz) ：目标系统时钟。选择168MHz时，CubeMX自动配置PLL_M=8、PLL_N=336、PLL_P=2、PLL_Q=7，此为ST官方推荐参数组合，确保各总线（AHB/APB1/APB2）分频后符合器件手册电气规范。
- Timebase Source ：此项决定SysTick归属。选项包括“HAL”、“FreeRTOS”、“None”。当选择“FreeRTOS”时，CubeMX会：
- 在 main.c 中移除 HAL_InitTick() 调用；
- 将 SysTick_Handler 重映射至 xPortSysTickHandler ；
- 禁用 HAL_Delay() 函数的SysTick依赖，强制用户使用 osDelay() 替代。

经验提示 ：若项目需同时使用 HAL_Delay() 与FreeRTOS任务延时，必须选择“None”，并手动为HAL库指定其他定时器（如TIM7）作为 HAL_InitTick() 的底层源。此操作需修改 stm32f4xx_hal_timebase_tim.c ，属进阶配置。

1.3.2 FreeRTOS中间件配置的工程含义

在CubeMX的“Middleware → FREERTOS”配置页中，“Version”选项（V1/V2）实为API封装层级差异：
- V1版本 ：生成代码直接调用FreeRTOS原生API，如 xTaskCreate() 、 vTaskStartScheduler() 。任务创建代码形如：
c osThreadDef(defaultTask, StartDefaultTask, osPriorityNormal, 0, 128); osThreadCreate(osThread(defaultTask), NULL);
- V2版本 ：引入CMSIS-RTOS v2 API封装层，所有调用统一为 osKernelInitialize() 、 osThreadNew() 等标准化接口。其优势在于跨RTOS平台可移植性，但增加一层函数调用开销。

对于STM32F407这类资源充裕的MCU，V1版本更贴近底层，便于调试与性能分析；而V2版本更适合需要未来迁移至其他RTOS（如RT-Thread）的长期项目。

任务（Task）配置项中的“Stack Size”单位为 字（Word） ，非字节。例如设置Stack Size=128，实际分配512字节（128×4）。该值需根据任务函数局部变量、函数调用深度、中断嵌套需求综合评估。一个典型传感器采集任务（含浮点运算、字符串格式化）建议不低于256字（1KB）。

1.3.3 工程生成后的目录结构与关键文件

CubeMX生成的FreeRTOS工程目录遵循严格分层：

Core/
├── Inc/
│   ├── main.h          // 主头文件，含FreeRTOS头文件包含
│   ├── stm32f4xx_hal_conf.h // HAL库配置，已启用HAL_FREERTOS_MODULE
│   └── FreeRTOSConfig.h    // FreeRTOS内核配置，由MX自动生成
├── Src/
│   ├── main.c           // 主函数，含MX初始化、任务创建、启动调度器
│   ├── freertos.c       // FreeRTOS专用初始化，含任务定义与创建
│   ├── stm32f4xx_it.c   // 中断服务函数，含xPortPendSVHandler等重映射
│   └── ... 
Drivers/
├── CMSIS/
│   └── Device/ST/STM32F4xx/Source/Templates/gcc/startup_stm32f407xx.s // 启动文件，已重映射向量表
Middlewares/
└── Third_Party/
    └── FreeRTOS/
        ├── Source/         // 内核源码
        └── CMSIS_RTOS/     // CMSIS-RTOS v1/v2封装层

其中 freertos.c 是工程核心，其 MX_FREERTOS_Init() 函数完成全部任务注册：

void MX_FREERTOS_Init(void) {
  /* 创建默认任务 */
  osThreadDef(defaultTask, StartDefaultTask, osPriorityNormal, 0, 128);
  defaultTaskHandle = osThreadCreate(osThread(defaultTask), NULL);

  /* 创建用户任务（如传感器采集） */
  osThreadDef(sensorTask, SensorTask, osPriorityAboveNormal, 0, 256);
  sensorTaskHandle = osThreadCreate(osThread(sensorTask), NULL);

  /* 启动调度器 */
  osKernelStart();
}

此结构将任务创建逻辑与硬件初始化解耦，符合模块化设计原则。

2. 智慧厨房安全监测系统的架构设计

本项目以STM32F407为核心控制器，构建一个具备多传感器融合、边缘决策、云边协同能力的物联网终端。其设计哲学并非简单堆砌功能，而是围绕 实时性、可靠性、低功耗、可扩展性 四大支柱展开。系统架构采用分层设计，清晰划分职责边界。

2.1 硬件拓扑与外设资源规划

系统硬件连接关系如下图所示（文字描述）：

• 主控单元 ：STM32F407ZGT6，负责所有传感器数据采集、本地逻辑判断、ESP8266通信协调、继电器/电机驱动控制。
• 环境感知层 ：
• 气体传感器阵列 ：MQ-2（可燃气体）、MQ-7（一氧化碳）、MQ-135（二氧化碳/空气品质），均采用模拟电压输出，接入STM32的ADC1_IN0~IN2通道。
• 温湿度传感器 ：DHT22（单总线协议），连接GPIOA_Pin5，通过HAL库 HAL_GPIO_ReadPin() 配合精确延时读取。
• 火焰传感器 ：红外火焰检测模块，数字输出（高电平有效），接入GPIOA_Pin6。
• 执行机构层 ：
• 继电器模块 ：控制照明灯、排风扇电源，由GPIOB_Pin0/Pin1驱动（开漏输出+上拉电阻）。
• 步进电机驱动 ：控制窗户开合，采用ULN2003驱动芯片，接收STM32的GPIOB_Pin2~Pin5四相脉冲信号。
• 通信枢纽 ：ESP8266-01S模块，通过USART2（PA2/PA3）与STM32通信，运行AT固件，负责MQTT协议栈及Wi-Fi连接。

外设资源分配需规避冲突：
- ADC1用于气体传感器，因需同步采样，配置为规则组连续转换模式，DMA搬运至缓冲区。
- DHT22使用GPIO模拟时序，禁止在该引脚上启用任何外设复用功能（AFIO）。
- USART2专供ESP8266，其TX/RX引脚不参与其他功能复用，确保通信稳定性。

2.2 软件架构：FreeRTOS多任务协同模型

系统软件采用“生产者-消费者”模式，由四个核心任务构成闭环：

任务名称	优先级	栈大小	功能描述	关键同步机制
SensorTask	osPriorityAboveNormal (3)	512B	周期性采集ADC、DHT22、火焰传感器数据，进行初步滤波与阈值判断	通过 xQueueSendToBack() 向 dataQueue 发送结构体
CloudTask	osPriorityNormal (2)	768B	处理 dataQueue 数据，打包为JSON，通过USART2发送AT指令给ESP8266，等待MQTT发布确认	使用 xSemaphoreTake() 获取 uartMutex ， xEventGroupWaitBits() 等待ESP8266响应
ControlTask	osPriorityHigh (4)	384B	监听 controlQueue （来自APP或云端的控制指令），驱动继电器与电机执行物理动作	直接操作GPIO寄存器，避免HAL库开销
LedTask	osPriorityBelowNormal (1)	128B	控制LED指示灯状态（运行、报警、网络连接），实现心跳闪烁	使用 vTaskDelay() 实现精确周期

此设计确保高优先级任务（如紧急火焰报警）能立即抢占低优先级任务（如LED闪烁），满足硬实时响应需求。

2.3 关键数据结构与通信协议设计

所有任务间数据交换通过FreeRTOS提供的线程安全机制实现，杜绝全局变量竞争：

• 传感器数据队列 ( dataQueue ) ：类型为 QueueHandle_t ，元素为结构体：
  c typedef struct { float temp; // 温度 (℃) float humi; // 湿度 (%RH) uint16_t co; // 一氧化碳浓度 (ppm) uint16_t ch4; // 甲烷浓度 (ppm) uint16_t co2; // 二氧化碳浓度 (ppm) uint8_t flame; // 火焰状态 (0=正常, 1=报警) uint32_t timestamp; // 时间戳 (ms) } sensor_data_t;
  队列长度设为5，防止突发数据洪峰导致丢包。

• 控制指令队列 ( controlQueue ) ：元素为枚举类型，简化解析逻辑：
  c typedef enum { CMD_LIGHT_ON, CMD_LIGHT_OFF, CMD_FAN_ON, CMD_FAN_OFF, CMD_WINDOW_OPEN, CMD_WINDOW_CLOSE, CMD_ALARM_CLEAR } control_cmd_t;

• 云端通信协议 ：采用精简JSON格式，减少ESP8266解析负担：
  json {"dev":"kitchen","ts":1625097600,"temp":25.3,"humi":45.2,"co":12,"ch4":8,"co2":520,"flame":0}
  其中 dev 字段标识设备ID， ts 为Unix时间戳，所有数值字段均为浮点或整数，无字符串冗余。

3. 核心功能模块实现详解

3.1 多传感器数据融合采集

传感器采集任务 SensorTask 需解决三大挑战：ADC通道切换时序、DHT22单总线时序精度、多源数据时间对齐。

3.1.1 ADC多通道同步采样配置

STM32F407的ADC1支持规则组序列转换，可一次性配置多个通道按序采样。关键配置步骤：
1. 时钟使能 ： __HAL_RCC_ADC1_CLK_ENABLE() ；
2. GPIO配置 ：PA0/PA1/PA2配置为模拟输入模式（ GPIO_MODE_ANALOG ）；
3. ADC初始化 ：
c hadc1.Instance = ADC1; hadc1.Init.Resolution = ADC_RESOLUTION_12B; // 12位精度 hadc1.Init.DataAlign = ADC_DATAALIGN_RIGHT; hadc1.Init.ContinuousConvMode = ENABLE; // 连续转换，匹配DMA hadc1.Init.NbrOfConversion = 3; // 3个通道 hadc1.Init.DMAContinuousRequests = ENABLE; // DMA请求连续 HAL_ADC_Init(&hadc1);
4. 规则通道配置 ：将ADC1_IN0（MQ-2）、ADC1_IN1（MQ-7）、ADC1_IN2（MQ-135）加入序列，采样时间均设为 ADC_SAMPLETIME_480CYCLES （最长采样时间，提升信噪比）；
5. DMA配置 ：启用DMA双缓冲模式， hdma_adc1 指向双缓冲区 adc_buffer[2][3] ，实现采集与处理流水线。

此配置下，ADC每完成一次3通道扫描，DMA自动将结果填入缓冲区， HAL_ADC_ConvCpltCallback() 回调函数触发，将最新数据封装入 sensor_data_t 并送入 dataQueue 。

3.1.2 DHT22时序精准控制

DHT22要求严格的微秒级时序，HAL库通用延时函数 HAL_Delay() 精度不足（毫秒级）。必须使用 HAL_GetTick() 结合忙等待实现亚毫秒精度：

// 启动信号：主机拉低至少18ms，再拉高20-40us
HAL_GPIO_WritePin(DHT22_GPIO_Port, DHT22_Pin, GPIO_PIN_RESET);
for(volatile uint32_t i=0; i<18000; i++); // 约18ms，需根据系统时钟校准
HAL_GPIO_WritePin(DHT22_GPIO_Port, DHT22_Pin, GPIO_PIN_SET);
for(volatile uint32_t i=0; i<40; i++);     // 约40us

// 读取响应：DHT22拉低80us，再拉高80us
while(HAL_GPIO_ReadPin(DHT22_GPIO_Port, DHT22_Pin) == GPIO_PIN_SET); // 等待下降沿
while(HAL_GPIO_ReadPin(DHT22_GPIO_Port, DHT22_Pin) == GPIO_PIN_RESET); // 等待上升沿

数据位读取时，每个位以50us低电平开始，高电平持续27us为“0”，70us为“1”。通过 HAL_GetTick() 记录电平变化时间戳，差值判定逻辑值。此方法在72MHz系统时钟下误差小于±2us，满足DHT22规格书要求。

3.1.3 数据时间戳与本地决策

所有传感器数据被打包前，均插入 HAL_GetTick() 获取的毫秒级时间戳。此时间戳不仅用于云端数据排序，更是本地决策依据。例如，火焰报警逻辑：

if (sensor_data.flame == 1 && 
    (HAL_GetTick() - last_flame_ts) > 500) { // 持续500ms高电平才确认
    // 触发紧急任务：点亮红色LED、启动蜂鸣器、发送最高优先级报警包
    xQueueSendToFront(controlQueue, &cmd_alarm, 0);
    last_flame_ts = HAL_GetTick();
}

此设计避免了电磁干扰导致的瞬时误触发，提升了系统鲁棒性。

3.2 ESP8266 MQTT通信的可靠实现

ESP8266作为Wi-Fi通信模组，其固件（AT指令集）存在固有缺陷：响应延迟大、缓冲区小、易丢指令。 CloudTask 必须实现一套健壮的状态机来保障通信可靠性。

3.2.1 AT指令交互状态机

状态机定义五个核心状态：
- AT_STATE_IDLE ：空闲，等待新数据包；
- AT_STATE_SEND_AT ：发送 AT 指令，等待 OK ；
- AT_STATE_SEND_CWMODE ：配置Wi-Fi模式，等待 OK ；
- AT_STATE_SEND_CWJAP ：连接AP，等待 WIFI GOT IP ；
- AT_STATE_SEND_MQTT ：执行MQTT连接与发布，等待 SEND OK 。

每个状态转移均设置超时（ AT_TIMEOUT_MS = 5000 ），超时则复位模组并重试。关键代码片段：

switch(at_state) {
    case AT_STATE_IDLE:
        if (xQueueReceive(dataQueue, &data, 0) == pdTRUE) {
            at_state = AT_STATE_SEND_AT;
            at_timeout = HAL_GetTick();
            HAL_UART_Transmit(&huart2, (uint8_t*)"AT\r\n", 4, HAL_MAX_DELAY);
        }
        break;
    case AT_STATE_SEND_AT:
        if (HAL_GetTick() - at_timeout > AT_TIMEOUT_MS) {
            // 超时，复位ESP8266
            HAL_GPIO_WritePin(ESP_RST_GPIO_Port, ESP_RST_Pin, GPIO_PIN_RESET);
            HAL_Delay(100);
            HAL_GPIO_WritePin(ESP_RST_GPIO_Port, ESP_RST_Pin, GPIO_PIN_SET);
            at_state = AT_STATE_IDLE;
        } else if (uart_rx_buffer_contains("OK")) {
            // 收到OK，进入下一状态
            at_state = AT_STATE_SEND_CWMODE;
            HAL_UART_Transmit(&huart2, (uint8_t*)"AT+CWMODE=1\r\n", 13, HAL_MAX_DELAY);
        }
        break;
    // ... 其他状态处理
}

3.2.2 JSON数据包构造与内存管理

为避免动态内存分配（ malloc ）在嵌入式环境中引发碎片化，所有JSON包均在栈上静态分配：

char json_buffer[256];
snprintf(json_buffer, sizeof(json_buffer),
         "{\"dev\":\"kitchen\",\"ts\":%lu,\"temp\":%.1f,\"humi\":%.1f,\"co\":%u,\"ch4\":%u,\"co2\":%u,\"flame\":%u}",
         data.timestamp, data.temp, data.humi, data.co, data.ch4, data.co2, data.flame);

snprintf 确保字符串零终止，且不会溢出缓冲区。此方法牺牲少量灵活性，换取极致的内存安全性与确定性执行时间。

3.3 本地智能控制逻辑

ControlTask 承担物理世界执行，其设计强调 确定性与时序精确性 。以步进电机窗户控制为例：

3.3.1 步进电机四相八拍驱动

ULN2003驱动芯片接受四路TTL电平输入，控制电机正反转。四相八拍序列如下：
| 步序 | A | B | C | D | 旋转方向 |
|------|—|—|—|—|----------|
| 1 | 1 | 0 | 0 | 0 | 正转 |
| 2 | 1 | 1 | 0 | 0 | |
| 3 | 0 | 1 | 0 | 0 | |
| 4 | 0 | 1 | 1 | 0 | |
| 5 | 0 | 0 | 1 | 0 | |
| 6 | 0 | 0 | 1 | 1 | |
| 7 | 0 | 0 | 0 | 1 | |
| 8 | 1 | 0 | 0 | 1 | |

ControlTask 中实现：

const uint8_t step_sequence[8][4] = {
    {1,0,0,0}, {1,1,0,0}, {0,1,0,0}, {0,1,1,0},
    {0,0,1,0}, {0,0,1,1}, {0,0,0,1}, {1,0,0,1}
};

void move_window(uint8_t direction, uint16_t steps) {
    for(uint16_t i=0; i<steps; i++) {
        for(uint8_t j=0; j<8; j++) {
            HAL_GPIO_WritePin(GPIOB, GPIO_PIN_2, step_sequence[j][0] ? GPIO_PIN_SET : GPIO_PIN_RESET);
            HAL_GPIO_WritePin(GPIOB, GPIO_PIN_3, step_sequence[j][1] ? GPIO_PIN_SET : GPIO_PIN_RESET);
            HAL_GPIO_WritePin(GPIOB, GPIO_PIN_4, step_sequence[j][2] ? GPIO_PIN_SET : GPIO_PIN_RESET);
            HAL_GPIO_WritePin(GPIOB, GPIO_PIN_5, step_sequence[j][3] ? GPIO_PIN_SET : GPIO_PIN_RESET);
            vTaskDelay(2); // 每步2ms，对应约125rpm
        }
    }
}

此实现完全绕过HAL库的 HAL_GPIO_TogglePin() （含函数调用开销），直接操作BSRR寄存器，确保脉冲时序抖动低于1us。

4. 调试与优化实战经验

4.1 常见陷阱与规避策略

• 陷阱1：FreeRTOS堆内存耗尽
  现象： xTaskCreate() 返回 NULL ，或 vTaskStartScheduler() 后无任何任务执行。
  根因： configTOTAL_HEAP_SIZE 设置过小，或任务栈溢出未被钩子函数捕获。
  解决：在 FreeRTOSConfig.h 中增大 configTOTAL_HEAP_SIZE （如从10KB增至20KB），并在 vApplicationStackOverflowHook 中插入 __BKPT() ，配合调试器观察栈指针SP是否越界。

• 陷阱2：USART2接收中断丢失
  现象：ESP8266响应数据部分丢失， HAL_UART_RxCpltCallback() 未被调用。
  根因：HAL库UART接收中断优先级低于SysTick，导致高优先级任务长时间运行时，UART中断被屏蔽。
  解决：在 stm32f4xx_hal_conf.h 中提高USART2中断优先级：
  c #define USART2_IRQn 28 #define USART2_IRQ_PREEMPTION_PRIORITY 1 // 抢占优先级1（高于SysTick的0） #define USART2_IRQ_SUB_PRIORITY 0

• 陷阱3：DHT22读取失败率高
  根因：GPIO引脚上拉电阻不足（标准4.7kΩ），导致DHT22输出高电平时电压跌落。
  解决：硬件层面更换为2.2kΩ上拉电阻；软件层面在 HAL_GPIO_ReadPin() 前增加 HAL_GPIO_WritePin(..., GPIO_PIN_SET) 强制上拉，消除引脚浮空。

4.2 性能优化技巧

• ADC采样速率优化 ：关闭ADC的 ScanConvMode （扫描模式），改用单通道轮询。虽增加软件开销，但避免了多通道切换的稳定时间（tSTAB），使单通道采样速率从1MHz提升至1.5MHz。
• JSON序列化加速 ：将 snprintf 替换为手工拼接。预计算浮点数整数/小数部分，用查表法转换为ASCII，速度提升3倍。
• 任务栈空间精算 ：使用 uxTaskGetStackHighWaterMark() 定期检查各任务栈峰值使用量，在 main() 中添加：
  c printf("SensorTask HWM: %d\r\n", uxTaskGetStackHighWaterMark(sensorTaskHandle));
  根据实测值动态调整栈大小，避免过度预留。

我在实际项目中曾因忽略 configLIBRARY_LOWEST_INTERRUPT_PRIORITY （最低中断优先级）的配置，导致所有外设中断（包括USART）均无法触发。ST参考手册明确要求：此宏值必须等于NVIC中断优先级分组（ HAL_NVIC_SetPriorityGrouping() ）所定义的最低组值。当使用 NVIC_PRIORITYGROUP_4 （4位抢占，0位子优先级）时， configLIBRARY_LOWEST_INTERRUPT_PRIORITY 必须设为15（二进制1111）。这个细节在CubeMX生成的代码中已被正确设置，但手动移植时极易遗漏，值得反复核查。