简介：面向STM32F407嵌入式学习者与FreeRTOS入门开发者，这套资料围绕FreeRTOS 1.4.0在Cortex-M4平台上的移植展开，覆盖工程配置、FreeRTOSConfig裁剪、SysTick时基与中断适配、GPIO驱动及LED流水灯任务创建等关键环节，可作为从裸机走向实时操作系统的实操参考。压缩包共511个文件，约11.53MB，以h头文件、c源文件及d、o等工程编译中间文件为主，并含少量汇编、启动与说明文档，保留了完整Keil工程结构，便于对照移植步骤和排查编译链接问题。已有629人学习下载，适合需要理解任务调度、延时控制与中断处理，并希望搭建可运行LED流水灯示例的读者参考。

1. STM32F407 移植 FreeRTOS 1.4.0：先把容易失败的地方指出来

把 STM32F407 移植 FreeRTOS 1.4.0 这件事，第一次做的人有不少会卡在同一个地方：工程编译零错误零警告，下载进去灯不闪，调试器一暂停就停在HardFault_Handler里，连个串口打印都没有。裸机跑得好好的板子，加进来一个内核就变成了黑匣子，这就是移植环节最典型的翻车现场。它常见到什么程度，凡是要在 F407 上做多任务采集、通信、显示的工程，基本都得走这一遍；装不好轻则任务不调度，重则中断随机丢失、跑几个小时就死机，回头查的时候连现场都没留下。下面按装前清点、往工程里加源码、配宏、排查问题、验证五段走，适合刚拿到源码包、想一次把环境配通的人。

2. 装前清点：F407 跑 FreeRTOS 1.4.0 要备齐的四样东西

移植失败的人里，有一半不是不会写代码，而是东西没备齐就开工。F407 这颗料本身资源够用（1MB Flash、128KB 主 SRAM、64KB CCM、带 FPU 的 Cortex-M4F 内核，主频跑到 168MHz），FreeRTOS 内核编译出来也就十几 KB，真正决定成败的是四样东西：源码包里到底要哪几个文件、端口层选哪个目录、工具链是哪一套、底层工程有没有先跑通。这四样任何一样搞错，后面配宏配得再漂亮也白搭。

我一般会把这四样东西先写在一张纸上，对着勾一遍再动手。勾不齐就先去补，不要指望编译报错来提醒你——移植阶段的报错往往指向的是表象，比如“找不到头文件”背后其实是路径加错了分组，改起来反而绕远。

2.1 Source 目录里哪几个 .c 必须进工程

FreeRTOS 1.4.0 的压缩包解出来，根目录下有个Source，这是内核本体，剩下那些 Demo、Example 目录一律不看，看多了只会干扰判断。Source下面的文件不是全加，按你实际用到的组件挑，加多了浪费 Flash，加少了链接报未定义符号。

堆管理那五个文件heap_1.c到heap_5.c只能选一个进工程，这是新手最容易犯的错：有人图省事把五个全加进去，链接时直接一堆重复符号；有人一个都没加，pvPortMalloc未定义。F407 这种要反复创建删除任务的场景，常见做法是选heap_4.c，它带相邻空闲块合并，长期跑不容易把内存碎成渣。

提示：版本号写法各家不一样，拿到包先打开Source/tasks.c看文件头注释，确认内核版本和你的资料对得上，再往下走。

2.2 端口层怎么选：ARM_CM4F 还是 ARM_CM3

端口目录是移植里第一个分水岭。F407 是 Cortex-M4F，带单精度硬件浮点，端口层理论上应该选带 F 的那个，也就是ARM_CM4F；但“带 F”不等于“能用 F”，关键看你的工程有没有真的把 FPU 打开。

如果工程编译选项里开了硬件浮点（MDK 里是 Options → Target → Floating Point Hardware 选 Single Precision，GCC 里是-mfpu=fpv4-sp-d16 -mfloat-abi=hard），那就用ARM_CM4F，它会在上下文切换时额外保存 S0-S15 和 FPSCR，浮点任务切来切去不会算错数。如果工程压根没用浮点、编译选项也是软浮点，却硬塞了 CM4F 的端口，后果是进调度器第一次切任务就进 HardFault——因为端口层按有 FPU 的前提去压栈，而实际编译出来的代码不认这套。

反过来，用ARM_CM3的端口配硬件浮点工程也能编过，单任务时看不出毛病，一旦两个浮点任务交替跑，结果就开始飘。这种问题最难查，因为它不是必现，跑几百次才错一次。我一般的判断标准很干脆：工程里只要出现float、double参与实时运算，就老老实实开 FPU 并用 CM4F 端口，别图省事。

端口目录下还有编译器分支，RVDS对应 MDK 的 ARMCC，GCC对应 arm-none-eabi-gcc，IAR对应 IAR。选错编译器的后果不是报几个警告，而是port.c里的内联汇编整段编不过，报一堆看不懂的寄存器名错误。

2.3 工具链与工程底座：先有一份能点灯的裸机工程

这一步最容易被跳过。很多人拿到 FreeRTOS 源码就直接新建空工程往里塞，塞完发现连SystemInit都没调，时钟还停在内部 16MHz，configCPU_CLOCK_HZ写 168000000 完全是自欺欺人。

正确的顺序是先把裸机底座跑通：时钟树配到 168MHz（外部 8MHz 晶振经 PLL 倍频，PLL_M=8、PLL_N=336、PLL_P=2、PLL_Q=7），一个 LED 能闪，一个串口能打印，中断向量表正常。底座跑通了，把它另存一份当模板，以后再移植别的内核都从这个模板起，省得每次重配时钟。

工具链上，MDK5 加 ARMCC 和 arm-none-eabi-gcc 都行，两者的差别主要在端口目录和启动文件上。MDK 用的是startup_stm32f407xx.s加分散加载文件，GCC 用的是startup_stm32f407xx.s加.ld链接脚本，堆栈大小在链接脚本里定义而不是在启动文件里。同一份FreeRTOSConfig.h两边可以共用，但configTOTAL_HEAP_SIZE要结合链接脚本剩下的 RAM 空间来定，不能照抄别人的数字。

还有一条硬件前提得提前想清楚：F407 的 64KB CCM RAM 挂在0x10000000，CPU 能访问，DMA 访问不了。FreeRTOS 的堆默认落在主 SRAM 里，也就是那 128KB 连续区，别指望改个宏就能把堆挪到 CCM，那需要改分散加载文件或者自己实现pvPortMalloc。

3. 往工程里加源码：把 FreeRTOS 1.4.0 的源码放进工程

底座有了，接下来是体力活，但体力活里也有讲究。分组怎么建、路径怎么加、宏怎么定义，顺序错了会陷入“改一个报错冒出三个新报错”的循环。我的习惯是按依赖倒着来：先让编译器找得到头文件，再让它找得到源文件，最后才处理符号冲突。

3.1 建四个分组，按依赖顺序加文件

在 MDK 的工程树里新建四个组，不要把所有文件都堆在Application/User下面。分组的意义在于后面出问题时一眼能看出是哪一层的问题。

# 目录规划（假设工程根目录为 F407_FreeRTOS） F407_FreeRTOS/ ├── Core/ # 裸机底座：main.c、时钟、GPIO、串口 ├── Drivers/ # 外设库或 HAL ├── FreeRTOS/ │ ├── Source/ # 内核源码，整包拷进来 │ └── Config/ │ └── FreeRTOSConfig.h # 配置头文件，单独放 └── User/

四个分组分别是FreeRTOS_CORE（tasks.c、list.c、queue.c，用到定时器再加 timers.c）、FreeRTOS_PORT（port.c）、FreeRTOS_HEAP（heap_4.c）、FreeRTOS_CONFIG（FreeRTOSConfig.h，有些工程习惯把它放User组，只要路径对就行）。

加文件时注意port.c和heap_4.c的路径层级比较深，MDK 里添加时不要用“相对于工程”的相对路径，尽量用绝对路径或者把整个FreeRTOS目录拷进工程目录再相对引用。我见过工程换台机器就编不过的，九成是因为绝对路径指向了别人电脑上的D:\盘。

FreeRTOSConfig.h不要用源码包自带的示例去改。示例里的configCPU_CLOCK_HZ是给别的开发板写的，configTOTAL_HEAP_SIZE也可能只有 10KB。新建一个空白文件从头写，长度控制在 100 行以内，每个宏后面写清楚为什么是这个值。

3.2 头文件路径与预处理宏，少一个都编不过

路径要加三条：FreeRTOS/Source/include、FreeRTOS/Source/portable/RVDS/ARM_CM4F（或者 GCC 对应目录）、FreeRTOS/Config。少第一条报找不到FreeRTOS.h，少第二条报找不到portmacro.h，少第三条报找不到FreeRTOSConfig.h。

预处理宏这块，MDK 里在 Options → C/C++ → Define 填：

USE_HAL_DRIVER,STM32F407xx

用标准外设库的工程就只填STM32F407xx，用 HAL 的加上USE_HAL_DRIVER。这两个宏不是 FreeRTOS 要的，是底层库要的，写错了会在stm32f4xx.h里报一堆外设未定义的错，跟内核一点关系没有。

还有一条编译选项容易漏：--c99或者-std=gnu11。FreeRTOS 1.4.0 的部分头文件里用了 C99 的写法，比如在for循环里定义变量，ARMCC5 默认按 C90 编就会报语法错误。

注意：MDK 的 ARMCC6（armclang）不能直接编译RVDS目录下的port.c，因为那段内联汇编是 ARMCC5 的嵌入式汇编语法。要么把编译器切回 AC5，要么改用GCC/ARM_CM4F端口目录，两者选一，别混着来。

3.3 第一份 FreeRTOSConfig.h：先能编过，再谈功能

第一次写这个文件，目标不是功能全，而是能编过、能进调度器。下面这份是我常用的起点，宏数量不多，但每一个都决定能不能跑起来。

/* FreeRTOSConfig.h —— 第一版只保留必要项，功能后面按需加 */ #ifndef FREERTOS_CONFIG_H #define FREERTOS_CONFIG_H /* 调度方式：抢占式 + 同优先级时间片轮转 */ #define configUSE_PREEMPTION 1 #define configUSE_TIME_SLICING 1 #define configUSE_PORT_OPTIMISED_TASK_SELECTION 1 /* CM4 有 CLZ 指令，可开 */ #define configUSE_TICKLESS_IDLE 0 /* 低功耗场景再开 */ /* 时钟与节拍：这两个值必须和实际主频一致，不能想当然 */ #define configCPU_CLOCK_HZ ( 168000000UL ) /* HCLK，不是晶振频率 */ #define configTICK_RATE_HZ ( 1000 ) /* 1ms 一个节拍 */ #define configSYSTICK_CLOCK_HZ configCPU_CLOCK_HZ /* 优先级与栈：栈的单位是“字”，4 字节 */ #define configMAX_PRIORITIES ( 7 ) #define configMINIMAL_STACK_SIZE ( 128 ) /* 128 字 = 512 字节 */ /* 堆：先用 30KB，跑起来再按 map 文件调 */ #define configTOTAL_HEAP_SIZE ( 30 * 1024 ) #define configAPPLICATION_ALLOCATED_HEAP 0 /* 中断优先级：这四行是 F407 上最容易写错的地方 */ #define configPRIO_BITS 4 #define configLIBRARY_LOWEST_INTERRUPT_PRIORITY 15 #define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5 #define configKERNEL_INTERRUPT_PRIORITY \ ( configLIBRARY_LOWEST_INTERRUPT_PRIORITY << ( 8 - configPRIO_BITS ) ) #define configMAX_SYSCALL_INTERRUPT_PRIORITY \ ( configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << ( 8 - configPRIO_BITS ) ) /* 中断向量映射：不加这三行，调度器起不来 */ #define vPortSVCHandler SVC_Handler #define xPortPendSVHandler PendSV_Handler #define xPortSysTickHandler SysTick_Handler /* 断言与钩子：调试期全开，量产再关 */ extern void vAssertCalled( const char *pcFile, int ulLine ); #define configASSERT( x ) \ if( ( x ) == 0 ) { vAssertCalled( __FILE__, __LINE__ ); } #define configCHECK_FOR_STACK_OVERFLOW 2 #define configUSE_MALLOC_FAILED_HOOK 1 #define configUSE_IDLE_HOOK 0 #define configUSE_TICK_HOOK 0 /* 组件裁剪与 API 开关 */ #define configUSE_TIMERS 1 #define configUSE_MUTEXES 1 #define configUSE_RECURSIVE_MUTEXES 1 #define configUSE_COUNTING_SEMAPHORES 1 #define INCLUDE_vTaskDelay 1 #define INCLUDE_vTaskDelete 1 #define INCLUDE_vTaskSuspend 1 #define INCLUDE_uxTaskGetStackHighWaterMark 1 #define INCLUDE_xTaskGetSchedulerState 1 #endif /* FREERTOS_CONFIG_H */

逐段说一下为什么这么写。前四行是调度模型，configUSE_PREEMPTION为 1 表示高优先级任务就绪就立刻抢占，这是大部分人想要的；configUSE_PORT_OPTIMISED_TASK_SELECTION打开后用CLZ指令找最高优先级任务，比查表快，但要求configMAX_PRIORITIES不超过 32，写 7 完全够用。

时钟那三行是血泪经验。configCPU_CLOCK_HZ填的是 HCLK，也就是 168000000，不是外部晶振的 8000000，也不是 HSE 倍频前的值。填错的后果是节拍周期整体偏移，vTaskDelay(1000)实际延时不是 1 秒，用示波器一量就能看出来。configSYSTICK_CLOCK_HZ在 F407 上通常等于 CPU 频率，因为 SysTick 的时钟源选的是 HCLK 而不是 HCLK/8。

中断优先级那四行后面单独讲，这里只要知道 15 和 5 是两个“库级”数值，真正写进寄存器的是左移 4 位之后的 0xF0 和 0x50。

最后那三行向量映射是最容易漏的。FreeRTOS 的上下文切换全靠 SVC、PendSV、SysTick 三个异常，端口层里函数的真名是vPortSVCHandler、xPortPendSVHandler、xPortSysTickHandler，而启动文件里的向量表认的是SVC_Handler、PendSV_Handler、SysTick_Handler。不加这三行宏，链接阶段会报SysTick_Handler未定义，或者更糟——链接过了但中断进的是空函数，调度器永远起不来。

3.4 编译期报错清障：四类 error 的处理顺序

第一次编译，报十几条错是正常的。不要一条条改，按类型批量处理，顺序如下。

第一类是“找不到头文件”，全是路径问题，回 3.2 检查三条 Include Paths 是否都加了，注意 MDK 的路径是分“编译器可见”和“汇编器可见”的，port.c里有汇编，两条路径都要加。

第二类是“重复定义”，典型的是L6200E: Symbol SysTick_Handler multiply defined。原因是stm32f4xx_it.c里已经写了SysTick_Handler，端口层里也有一个，两个撞了。解决办法是把stm32f4xx_it.c里这三个函数用#if 0 ... #endif包起来或者直接删掉：SVC_Handler、PendSV_Handler、SysTick_Handler。删完记得把它们在向量表里的位置留给内核，别顺手把整个中断文件清空。

第三类是“未定义符号”，比如undefined symbol pvPortMalloc，说明heap_4.c没加进工程，或者加进去了但分组里勾了“Exclude from build”。MDK 里被排除的文件图标上有个小叉，很多人没注意。

第四类是语法错误，多数出在port.c，且基本都是编译器与端口目录不匹配导致的，回 2.2 换目录即可，不要在port.c里改汇编。

四类清完，编译应该能过。这时候别急着下载，先看 map 文件里的 RAM 占用，确认.bss加上configTOTAL_HEAP_SIZE没超过 128KB，超了在链接阶段可能不报错，跑起来直接进 HardFault。

4. 配置核心参数：FreeRTOSConfig.h 里三处必须自己算的宏

配置这一章是整篇的重点。前面那些宏抄一抄能过，这三处必须自己算，因为它们的值取决于你的板子、你的时钟、你的中断用法，抄别人的数字迟早出问题。

4.1 节拍与时钟：configCPU_CLOCK_HZ 必须等于 HCLK

SysTick 是内核的节拍源，FreeRTOS 靠它做时间片和延时。端口层初始化时会往SysTick->LOAD写一个重装载值，公式是：

/* port.c 里的实际动作，理解这两行就理解了节拍 */ portNVIC_SYSTICK_LOAD_REG = ( configSYSTICK_CLOCK_HZ / configTICK_RATE_HZ ) - 1UL; /* 168000000 / 1000 - 1 = 167999 */

168MHz 主频、1000Hz 节拍，算出来 167999，正好在 SysTick 的 24 位重装载范围内（最大 16777215）。如果你把configTICK_RATE_HZ提到 10000，算出来 16799，也没问题；但如果主频填成了 16800000（少了一个零），延时就会变成实际的十分之一，节拍也不准。

那怎么确认自己填的 HCLK 是对的？两个办法。一是在SystemClock_Config()之后读一下SystemCoreClock变量，调试器里看它的值是不是 168000000；二是翻时钟树配置，确认 PLL 的PLL_N、PLL_P和 AHB 分频系数，HCLK = SYSCLK / AHB_Prescaler，F407 上 AHB 不分频，所以HCLK = SYSCLK = 168MHz。

注意：HAL_Init()默认把 SysTick 配成 1ms 中断给HAL_Delay用，一旦 FreeRTOS 接管 SysTick，HAL_Delay就会失效或者跟内核抢中断。常见做法是把 HAL 的时基改到某个 TIM 上（HAL_InitTick里换成 TIM6），或者干脆在任务里只用vTaskDelay，别调HAL_Delay。

4.2 中断优先级：configMAX_SYSCALL_INTERRUPT_PRIORITY 与 NVIC 分组

这是 F407 移植 FreeRTOS 最容易翻车的一处，没有之一。Cortex-M4 的 NVIC 有 4 位优先级（F407 上就是 4 位），数值越小优先级越高。FreeRTOS 需要一个“边界”：优先级数值大于等于这个边界的中断，才允许调用FromISR结尾的 API；小于这个边界的中断，优先级比内核的临界区还高，绝对不能调任何内核函数。

/* 左移 4 位是因为 NVIC 寄存器只用了高 4 位 */ #define configKERNEL_INTERRUPT_PRIORITY \ ( 15 << ( 8 - 4 ) ) /* = 0xF0，内核自己用的最低优先级 */ #define configMAX_SYSCALL_INTERRUPT_PRIORITY \ ( 5 << ( 8 - 4 ) ) /* = 0x50，能调 API 的最低门槛 */

配好这两个宏只是第一步，还得做两件事。

第一件，把 NVIC 优先级分组设成组 4，也就是 4 位全给抢占优先级、0 位给子优先级。HAL 库里在HAL_Init()里会调HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4)，用标准库的话自己调一次NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4)。分组不是组 4 的时候，你填的“5”可能被拆成抢占 0、子优先级 5，实际抢占级别比内核还高，调用xQueueSendFromISR必然触发断言。

第二件，给每个外设中断定优先级时，凡是要调 FreeRTOS API 的，优先级数值必须大于等于 5，比如串口接收中断、定时器中断、外部中断都设成 5 到 15 之间；而那些绝对不能被打断的（比如看门狗喂狗、电机换相），设成 0 到 4，但这类中断里一行内核 API 都不能写。

我一般把常用外设的优先级固定下来，写在表里贴到工程 README 里，省得后来加中断时随手写个 0 就出事：

4.3 堆：configTOTAL_HEAP_SIZE 和 heap_4 的取舍

heap_4.c从一块静态数组里切内存，这块数组大小就是configTOTAL_HEAP_SIZE。它不占用启动文件里那个Heap_Size（那个是给 C 库malloc用的，FreeRTOS 不用它）。F407 主 SRAM 128KB，减去全局变量、任务栈、外设缓冲区，一般能匀出 30KB 到 50KB 给内核堆。

给多少合适？算一笔账：每个任务的控制块（TCB）几十字节，xTaskCreate里的栈深度参数单位是字，一个中等复杂度的任务给 256 字就是 1KB；队列的存储区按“消息大小 × 队列长度”算，一条 32 字节的消息、长度 10 的队列就是 320 字节；互斥量、信号量各几十字节。四个任务加两个队列，10KB 左右能撑住，留 30KB 是给运行期动态创建删除留余量。

堆给太小的现象很有辨识度：xTaskCreate返回errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY，或者pvPortMalloc返回 NULL。如果你开了configUSE_MALLOC_FAILED_HOOK，会直接进vApplicationMallocFailedHook。堆给太大的现象更隐蔽：编译链接都过，一运行就 HardFault，因为堆数组把主 SRAM 撑爆了，越界写到了栈区。

查实际用了多少，调这两个函数就行：

/* 放在一个低优先级任务里，每秒打印一次 */ printf( "free heap: %u bytes\r\n", ( unsigned )xPortGetFreeHeapSize() ); printf( "min ever free: %u bytes\r\n", ( unsigned )xPortGetMinimumEverFreeHeapSize() );

xPortGetMinimumEverFreeHeapSize返回的是历史最低水位，跑一段时间看这个值，如果只剩几百字节，说明堆该加了；如果一直是 30KB 纹丝不动，说明堆给多了，可以匀一部分给任务栈。

4.4 把 configASSERT 与栈溢出检查打开

调试期这两个检查必须开，它们能把“跑几小时才死机”变成“跑几秒就停在出问题的那一行”。

/* 断言失败时停在这里，调试器能直接看到文件和行号 */ void vAssertCalled( const char *pcFile, int ulLine ) { taskENTER_CRITICAL(); /* 关中断，防止打印被打断 */ printf( "ASSERT FAIL: %s:%d\r\n", pcFile, ( int )ulLine ); ( void )pcFile; ( void )ulLine; while( 1 ) { /* 停住，让调试器接住，别让它复位继续跑 */ } } /* 栈溢出钩子：configCHECK_FOR_STACK_OVERFLOW 为 2 时会被调用 */ void vApplicationStackOverflowHook( TaskHandle_t xTask, char *pcTaskName ) { ( void )xTask; printf( "STACK OVERFLOW: %s\r\n", pcTaskName ); while( 1 ) { } } /* 堆分配失败钩子 */ void vApplicationMallocFailedHook( void ) { printf( "MALLOC FAILED\r\n" ); while( 1 ) { } }

这三个钩子函数名字是固定的，不能改，FreeRTOS 内核在对应位置弱符号引用了它们。configCHECK_FOR_STACK_OVERFLOW设成 2 是最严格的一档，任务切换时检查栈指针附近有没有被写花的魔数，开销略大但调试期值得。

configASSERT里的taskENTER_CRITICAL()有个前提：断言发生时调度器已经启动。如果断言在vTaskStartScheduler()之前触发，taskENTER_CRITICAL里访问的uxCriticalNesting还没初始化，行为不可预期。所以第一次上电调试时，我习惯把断言里的临界区先注释掉，等系统跑起来再打开。

5. 排查清单：F407 移植 FreeRTOS 1.4.0 最常见的五个坑

下面这五个坑是我自己踩过、也帮别人看过很多次的，按出现阶段从编译到运行排列。每一条都写成现象、原因、解决三段，遇到问题时可以直接对号入座。

5.1 编译链接阶段：端口文件和中断向量

坑一：port.c编不过，报一堆寄存器名错误。

现象：port.c里__asm那几段报expected ')'、unknown register name 'r0'，错误行号集中在vPortStartFirstTask和xPortPendSVHandler附近。

原因：编译器与端口目录不匹配。用 ARMCC6 编RVDS/ARM_CM4F会这样，用 GCC 编RVDS目录也会这样，因为RVDS目录里的内联汇编是 ARMCC5 的嵌入式汇编语法，armclang 和 GCC 都不认。

解决：编译器是 AC5 就用RVDS，是 AC6 或 arm-none-eabi-gcc 就用GCC目录。换目录后记得同步改头文件路径，否则会变成找不到portmacro.h。换完不要保留旧目录的文件引用，MDK 里把旧的从分组里移除，不然链接阶段会报重复符号。

坑二：链接报SysTick_Handler重复定义。

现象：L6200E: Symbol SysTick_Handler multiply defined (by port.o and stm32f4xx_it.o)。

原因：启动文件里的向量表已经把这个名字占用了，stm32f4xx_it.c里又实现了一份，端口层通过宏映射也指过来了，三份撞在一起。

解决：把stm32f4xx_it.c里SVC_Handler、PendSV_Handler、SysTick_Handler三个函数体删掉或注释掉，只保留向量表里的名字，具体实现交给端口层。这三个函数在中文件里通常是空的while(1)，删掉不影响别的外设中断。

5.2 调度器起不来：优先级与堆

坑三：程序停在vTaskStartScheduler里出不来，或者第一次任务切换直接 HardFault。

现象：调试器单步能走到vTaskStartScheduler()，再往下跑就停在HardFault_Handler的while(1)里，栈里能看到xPortPendSVHandler。

原因：多数是中断优先级的问题。要么 NVIC 分组不是组 4，导致configMAX_SYSCALL_INTERRUPT_PRIORITY那个值算出来对不上实际寄存器；要么某个外设中断优先级设成了 0 到 4，而它的中断处理函数里调了xQueueSendFromISR，内核在临界区里被更高优先级的中断打断，再回来时现场已经乱了。

解决：先确认HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4)确实被调用过，把它放在HAL_Init()之后、任何外设初始化之前。然后逐个检查中断优先级，把所有调用FromISRAPI 的中断降到 5 以下（数值上大于等于 5）。查不出来的时候，临时把所有外设中断优先级都设成 15，能跑起来再一个个往回加，二分法定位最快。

还有一种可能：configASSERT里定义了taskENTER_CRITICAL，但调度器还没启动就触发了断言，一样会 HardFault。调试初期先把断言里的临界区去掉。

坑四：xTaskCreate返回失败，任务创建不出来。

现象：xTaskCreate返回值是errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY，或者进了vApplicationMallocFailedHook，串口打印MALLOC FAILED。

原因：configTOTAL_HEAP_SIZE太小，或者heap_4.c压根没加进工程（但那会是未定义符号，编译期就报）。还有一种隐蔽情况：堆数组定义在.bss里，而链接脚本或分散加载文件给 RAM 分配的空间不够，堆数组和栈区重叠，链接器不一定报错。

解决：先看 map 文件里ucHeap这个符号占多大、地址在哪，确认它没和栈区（Stack_Mem、__initial_sp）重叠。然后把configTOTAL_HEAP_SIZE往下调一档试，比如从 30KB 降到 20KB，如果反而能跑，说明就是空间不够。用xPortGetFreeHeapSize()看创建完任务后的余量，余量小于 2KB 就该扩容或者精简任务栈。

5.3 跑起来才翻车：栈和打印

坑五：跑几分钟后死机，或者某个任务的行为莫名其妙。

现象：系统能跑，灯也闪，但跑几分钟到几十分钟后死机，复位又能跑；或者某个任务里的局部变量值突然变了，串口打印乱码。

原因：任务栈溢出。F407 的栈向低地址增长，任务栈给 128 字（512 字节）看着不少，但一个函数里定义个 256 字节的局部数组、再调两层带浮点参数的函数，就顶到边界了。溢出后写花的是相邻任务的控制块，表现就是“别的任务出问题”，查起来毫无头绪。

解决：把configCHECK_FOR_STACK_OVERFLOW设成 2，溢出时进钩子函数，直接打印任务名。平时在每个任务里周期性调uxTaskGetStackHighWaterMark(NULL)，返回值是历史最小剩余栈（单位字），小于 32 就该加栈。上面那个坑的根因，八成是一个 200 字节的局部缓冲区，改成静态数组或者从堆上分配就没事了。

还有一条不算坑但经常被当成坑：串口打印在中断里用阻塞方式发，一旦发送缓冲满，中断就卡在那儿等，整个系统像死机一样。解决是把打印挪到任务里，中断只往队列里丢数据，或者用 DMA 发送。这个习惯从移植第一天就该养成，等出了问题再改，要翻的地方太多。

6. 装完怎么验证：四步把一个会跑的内核验到底

移植完最怕的不是跑不起来，是“看起来跑起来了”。灯在闪，但节拍可能差 10%，任务栈可能只剩 20 字，堆可能再创建两个队列就崩。所以装完必须做验证，我一般按四步走，每步都有明确的通过标准，不通过就不往下走。

6.1 四步验证法：从编译到队列

第一步，编译零错误零警告，看 map 文件。通过标准是ucHeap的结束地址不超过 RAM 末尾，.bss加堆加栈的总和留出至少 10% 余量。不通过就先调configTOTAL_HEAP_SIZE，别急着下载。

第二步，单任务点灯，用逻辑分析仪量周期。

static void vLedTask( void *pvParameters ) { ( void )pvParameters; for( ;; ) { HAL_GPIO_TogglePin( GPIOA, GPIO_PIN_6 ); /* 按自己的板子改引脚 */ vTaskDelay( pdMS_TO_TICKS( 500 ) ); /* 500ms，理论周期 1s */ } } int main( void ) { HAL_Init(); SystemClock_Config(); /* 必须先配到 168MHz，再启动调度器 */ MX_GPIO_Init(); MX_USART1_UART_Init(); /* 返回值一定要判断，堆不够时这里会失败 */ if( xTaskCreate( vLedTask, "led", 256, NULL, 3, NULL ) != pdPASS ) { printf( "task create failed\r\n" ); while( 1 ) { } } vTaskStartScheduler(); /* 正常情况不返回 */ for( ;; ) { } /* 走到这里说明堆已经不够 */ }

通过标准是实测周期在 1s 上下 1% 以内。量出来是 1.2s，八成是configCPU_CLOCK_HZ填错了；量出来抖动很大，去看有没有高优先级中断频繁打断。

第三步，打印栈水位和堆余量，让系统空跑十分钟。通过标准是uxTaskGetStackHighWaterMark返回值大于 64 字、xPortGetMinimumEverFreeHeapSize大于 4KB。

第四步，跑一个完整链路：中断收数据 →xQueueSendFromISR→ 任务里xQueueReceive→ 处理 → 再发回串口。这一步能跑通，说明中断优先级、队列、任务切换三样都对了。

最后说一个具体技巧：验证阶段把configASSERT、栈溢出检查、configUSE_MALLOC_FAILED_HOOK全打开，等这套东西在板子上连续跑够一天再关。关的时候不要图省事直接删代码，用宏包

本文还有配套的精品资源，点击获取