企业官网建设流程全解析

项目最怕的不是功能没写出来，而是跑着跑着忽然卡死，复位后一切正常，再跑几个小时又卡。我遇到这种情况十次里有六七次，最后都指到同一个地方——某个任务的栈被写爆了。FreeRTOS 的任务堆栈（Task Stack）就是这么个东西：它是xTaskCreate五个参数里最不起眼、最容易被随手填一个数、也最容易在项目后期给你致命一击的那个。它不像队列、信号量那样有 API 可调，出问题的时候通常表现为 HardFault、变量莫名其妙被改、任务再也不进入就绪态，现象千奇百怪，就是不像"栈"的问题。

这篇内容我打算把任务堆栈从内存布局、容量换算、溢出检测、实测调优到几个典型踩坑场景，完整地捋一遍。适合正在用 STM32 + FreeRTOS 做项目的人，也适合准备把裸机程序改成 RTOS 架构、还没意识到栈需要重新规划的人。不管你是刚点亮第一个 LED 任务，还是已经在调 20KB RAM 里塞五个任务，这里面的账都值得算清楚。

1. 任务栈到底放在哪：先搞清 Cortex-M 的双栈结构与 FreeRTOS 的布局

讨论栈之前必须先破除一个很常见的误解：很多人以为"一个任务一个栈，中断来了用当前任务的栈"。在 Cortex-M 上这是不对的。搞不清这一点，后面所有关于栈容量和溢出位置的推理都会跑偏。

1.1 MSP 与 PSP：任务栈和中断栈根本不是一回事

Cortex-M 内核物理上有两个栈指针：MSP（主栈指针）和PSP（进程栈指针）。复位之后内核默认用 MSP，也就是启动文件startup_stm32f103xb.s里那段：

Stack_Size EQU 0x00000400 AREA STACK, NOINIT, READWRITE, ALIGN=3 Stack_Mem SPACE Stack_Size __initial_sp

这 0x400（1KB）就是 MSP 的地盘。FreeRTOS 在vTaskStartScheduler之前把CONTROL寄存器的 SPSEL 位置 1，让线程模式使用 PSP，于是所有任务代码都在自己的 PSP 上跑；而异常/中断处理模式永远使用 MSP，这个规则是硬件定死的，改不了。

这意味着两件事。第一，你的中断服务函数、PendSV、SysTick 里消耗的栈，全部来自启动文件里那 1KB 的 MSP 区域，跟你给任务分配多大的栈没半点关系。第二，中断嵌套层数越多、ISR 里局部变量越大、在 ISR 里调printf或者做浮点运算，吃的都是 MSP。项目里 HardFault 查半天发现"任务栈明明还有富余"，八成就是 MSP 爆了。我在一个 3 路串口同时收数据的项目上就栽过：三个任务栈各留了 30% 余量，结果中断嵌套一深，MSP 顶穿了__initial_sp上面的区域，直接把相邻的 .data 段某个全局变量改了。

提示： MSP 的大小在启动文件里改，常见做法是从 0x400 提到 0x800 甚至 0x1000。改完记得确认 RAM 总量还够，F103C8T6 只有 20KB RAM，乱加会直接编译报错或者链接失败。

1.2 任务栈数组的内存布局：从 pxStack 到 pxTopOfStack

xTaskCreate内部做的事，简单说就是pvPortMalloc出一块内存当栈，再加一个 TCB（任务控制块）。TCB 里有三个跟栈直接相关的成员：pxStack指向栈内存的低地址端（基地址，创建后不再变），pxTopOfStack指向"当前栈顶"，pxEndOfStack只在开了configRECORD_STACK_HIGH_ADDRESS时才有，记录高地址端。

Cortex-M 的栈是满递减（Full Descending）：压栈时先减指针再写数据，所以栈是"从高地址往低地址长"的。pxTopOfStack初始化时被设成pxStack + depth - 1，然后由pxPortInitialiseStack往上递减填入 16 个字（后面细说）。任务真正跑起来之后，pxTopOfStack随着压栈不断向低地址移动，越接近pxStack就越危险。

这里有个特别容易搞混的点：溢出检测检查的是低地址那一端。因为栈往下长，越过pxStack[0]之后，写进去的数据落在栈数组之前的堆内存里，那块内存可能是另一个任务的栈、可能是队列的存储区、也可能是 TCB。这就是为什么栈溢出这么难查——它没有"越界异常"（除非你开了 MPU），它只是安静地把你邻居的内存改掉。

1.3 为什么向下生长让溢出问题变得格外隐蔽

我举个真实场景。假设你在 heap_4 上按顺序创建了任务 A 和任务 B，heap_4 的分配顺序让 A 的栈正好在 B 的栈下面（或者说 A 的栈数组后面紧邻 B 的 TCB）。A 溢出，越界写的是靠近 A 栈基地址前面的几个字。如果那块内存当时是空闲块，什么现象都没有，直到下次pvPortMalloc从这个块里切内存，你才会看到一个"分配出来的队列数据是乱码"的诡异现象。

更常见的是溢出发生在栈底附近但没跑远，pxTopOfStack稍微越界几个字，写坏的是紧邻的块头（BlockLink_t），xBlockSize被改掉，下一次vPortFree的时候链表直接崩，触发configASSERT死循环。这种故障距离真正的错误点可能已经过了好几分钟、几千次调度。

所以我的习惯是：调试期永远开configCHECK_FOR_STACK_OVERFLOW，并且把configASSERT定义成一个能留下痕迹的钩子（比如记录程序计数器到一块 noinit 内存再复位），而不是空循环。空循环等于把唯一的线索掐断了。

2. xTaskCreate 里的那个数字：单位是字不是字节

把栈放在哪搞清楚了，接下来是那个数字本身。这是新手最容易误判的地方，没有之一。

2.1 usStackDepth 的真实含义与换算

xTaskCreate的第三个参数在 FreeRTOS V10 之后的原型是这样的：

BaseType_t xTaskCreate( TaskFunction_t pxTaskCode, const char * const pcName, const configSTACK_DEPTH_TYPE usStackDepth, void * const pvParameters, UBaseType_t uxPriority, TaskHandle_t * const pxCreatedTask );

注意configSTACK_DEPTH_TYPE，默认被定义成uint16_t。这个参数的单位是StackType_t 的个数，而对 Cortex-M3/M4/M7 的 port，StackType_t是uint32_t。

也就是说：

xTaskCreate( vTask1, "T1", 128, NULL, 2, NULL );

这里的 128 是128 个字（word）= 512 字节，不是 128 字节。我第一次接触时按"字节"理解，给了 512 才反应过来其实是 2KB，白白浪费了 RAM；反过来，有些照着别人例程抄的人看到"128"觉得很小，不敢加，其实已经不小了。

换算关系写成表格更直观：

顺带提一句configSTACK_DEPTH_TYPE默认是uint16_t，最大只能传 65535 个字，约 256KB。如果你在带外部 SDRAM 的板子上想给某个任务开 512KB 栈，得先把configSTACK_DEPTH_TYPE改成uint32_t，否则编译器会默默截断，你会得到一个"明明传了很大的数、high water mark 却一直很低"的错觉——因为栈根本没分配那么大。

2.2 一个任务的栈里到底装了什么

要把栈算准，得知道里面装了什么。一个 Cortex-M3 任务的栈，从创建那一刻起就被分成几块用途：

第一块是初始上下文，固定 16 个字（64 字节）。pxPortInitialiseStack会从pxTopOfStack往下填：xPSR、任务入口地址PC、LR、R12、R3~R0、R11~R4。这是硬件异常入栈格式（8 个字）+ 软件保存的 R4-R11（8 个字）拼出来的。之后每次任务切换，FreeRTOS 都会用这 64 字节保存/恢复一次现场。

第二块是函数调用栈帧。任务函数本身、它调用的每一个函数，局部变量、参数、返回地址、编译器分配的临时寄存器溢出空间都在这里。嵌套一层就多一层。用 AC6（LLVM）编译的时候，栈帧往往比 AC5 大一些，尤其是开了 -O0 调试的时候。

第三块是大型局部变量。char buf[256]这种直接写在任务函数里的数组，就是从任务栈里切的。很多人写任务函数的时候毫无感觉：

void vUartTask(void *pvParameters) { char rxBuf[256]; char logBuf[128]; /* ... */ }

光这两个数组就吃掉 384 字节，再加上snprintf自己内部要用的栈，一个 512 字节的任务瞬间见底。这是最典型的"栈爆了但代码看起来人畜无害"。

第四块是 FPU 上下文（Cortex-M4F/M7 才有）。如果任务里做了浮点运算，port 层在切换时会额外保存 S0-S15 和 FPSCR，共 17 个字，再按 8 字节对齐补齐，最多 18 个字（72 字节）。加上基础 64 字节，一次上下文切换就能吃掉 136 字节。开了 FPU 的板子，任务栈预算要按这个数重新算。

把这几项加起来做个粗略公式：

任务栈需求 ≈ 64B（基础上下文） + FPU 72B（如果用到浮点） + 最深调用链的栈帧总和 + 所有局部大数组之和 + 库函数内部开销（printf 最狠） + 安全余量（30%~50%）

2.3 堆、TCB 与栈的账要一起算：configTOTAL_HEAP_SIZE 估算

xTaskCreate创建的栈是从 FreeRTOS 堆里切的，configTOTAL_HEAP_SIZE不够的时候，创建会失败并返回errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY。这个返回值必须检查，我见过太多次"任务没建起来所以 LED 不闪"的情况，代码里xTaskCreate的返回值被丢掉了，白白查了两小时。

heap_4 的堆账这么算：

举个 F103C8T6 的实例，5 个任务：

• 启动任务：128 字 = 512 B
• 串口收发任务：256 字 = 1024 B
• 传感器采样任务：128 字 = 512 B
• 数据处理任务：192 字 = 768 B
• 空闲任务：configMINIMAL_STACK_SIZE= 128 字 = 512 B

栈合计 3328 B，TCB 5 × 96 = 480 B，块头 5 × 8 = 40 B，再加一个 8 项 × 4 字节的队列（约 32 B + 8 B + 80 B 控制块）。粗算下来约 4KB。configTOTAL_HEAP_SIZE至少要给到 5KB 才踏实，实际我会给 6KB。20KB RAM 的芯片上这是能接受的，但如果你还要跑 LVGL 那种吃内存的库，就必须把栈压到极限，并且逐个用 high water mark 验证。

注意：configTIMER_TASK_STACK_DEPTH的默认值通常是configMINIMAL_STACK_SIZE * 2。如果你在软件定时器回调里做printf或者跑一段稍长的逻辑，这个默认值一定不够，而且它是在vTaskStartScheduler里悄悄创建的，很容易被忽略。

3. 栈溢出检测：两种机制的边界与实测表现

FreeRTOS 提供了configCHECK_FOR_STACK_OVERFLOW，取值 0/1/2（3 是部分版本支持的两个都开）。很多人开了它就觉得万事大吉，其实这两种机制各自都有明确的检测盲区，理解盲区比记住开关重要得多。

3.1 取值 1 与取值 2 到底检查了什么

取值 1（方法一：栈指针越界检查）在每次任务切换的时候，检查当前任务的pxTopOfStack是否已经越过了pxStack的边界。它的成本极低，只是两次指针比较，几乎不影响性能。

缺点也很明显：它只在上下文切换的时刻检查。如果一个任务在两次切换之间把自己的栈顶推到了边界之外，然后立刻返回、又把栈指针恢复了，这个瞬时越界永远不会被发现。更麻烦的是，方法一只能发现"切换那一刻恰好越界"，如果越界之后任务已经跑飞、再也没机会切回来，检测也就失效了。

取值 2（方法二：填充模式检查）在任务创建时把整个栈内存填充成0xa5，然后在每次上下文切出这个任务的时候，检查栈的最低地址端的最后 20 个字节是否仍然是0xa5。如果被改写了，说明栈曾经被写穿过。

方法二的检测能力明显更强，因为它能发现"越界过又退回来"的情况——只要写过，最低那 20 字节的填充就被破坏了，回不去了。代价是任务创建时多一次 memset，切换时多一次 20 字节的比较，对绝大多数项目完全无感。

但方法二也有盲区，而且这个盲区经常被忽略：它只检查最后 20 字节。如果任务只是轻微越界、刚好写坏了pxStack[0]附近但恰好越过了那 20 字节之外的部分——不对，准确说是越界量不够大、没能把最后 20 字节全部覆盖时，才有可能漏检。实际情况下只要越界超过 20 字节就必然被抓到，而小于 20 字节的越界几乎不产生实际危害，所以方法二的实用价值很高。真正的问题是它只在切换时检查，如果一个任务写完越界数据后立刻让出 CPU，检查会立刻发生；但如果它一直在跑（比如一个优先级最高、永不让出的任务），那要等到它让出才会被检查到。

我的实际配置：

#define configCHECK_FOR_STACK_OVERFLOW 2 #define INCLUDE_uxTaskGetStackHighWaterMark 1

调试阶段一律开 2，量产版本如果对创建时间敏感、又已经充分验证过栈用量，可以降到 1 或者 0 来省那点开销。但只要 RAM 还够，我一直保持 2，因为排查一次偶发死机的成本远高于那点 CPU。

3.2 vApplicationStackOverflowHook 里最不该做的事

检测到溢出之后会调用vApplicationStackOverflowHook，签名固定：

void vApplicationStackOverflowHook( TaskHandle_t xTask, char *pcTaskName );

我见过不少工程里这么写：

void vApplicationStackOverflowHook(TaskHandle_t xTask, char *pcTaskName) { printf("Stack overflow in task: %s\r\n", pcTaskName); for(;;); }

这段代码有两个问题。第一，栈已经溢出了，你在这个上下文里再调printf，printf自己要吃几百字节栈，会继续扩大破坏范围，甚至直接触发 HardFault 把pcTaskName这个唯一的线索也丢掉。第二，for(;;);在中断关闭状态下死循环，看门狗不复位（如果没单独喂狗），现场卡死，调试器连上去只能看到一个 PC 值。

我现在的写法是这样的：

/* 放在一块不被初始化的 RAM 里，复位后还能读 */ __attribute__((section(".noinit"))) volatile char g_overflowTaskName[16]; __attribute__((section(".noinit"))) volatile uint32_t g_overflowFlag; void vApplicationStackOverflowHook(TaskHandle_t xTask, char *pcTaskName) { (void)xTask; taskDISABLE_INTERRUPTS(); g_overflowFlag = 0xDEADBEEF; for (int i = 0; i < 15 && pcTaskName[i] != '\0'; i++) { g_overflowTaskName[i] = pcTaskName[i]; } g_overflowTaskName[15] = '\0'; /* 点一个错误指示灯，然后交给看门狗复位 */ GPIO_SetBits(GPIOB, GPIO_Pin_0); for (;;) { } }

复位之后，程序启动时先检查g_overflowFlag，如果非零就把g_overflowTaskName通过串口打出来。这样你既知道是哪个任务溢出了，又不会因为 hook 本身再次把内存搅乱。Keil 里用__attribute__((section(".noinit")))需要配合 scatter file 或者在 AC6 下用__attribute__((section(".noinit"), zero_init))，具体语法看你用的编译器版本。

提示： hook 里只读pcTaskName是安全的，它指向 TCB 内部的字符数组，不依赖已经被破坏的任务栈。别在 hook 里做任何依赖栈深度的操作。

3.3 用硬件观察点和填充模式把溢出定位到具体函数

检测告诉你"哪个任务溢出了"，但不告诉你"哪一行代码溢出的"。要定位到函数，我有两个惯用手段。

第一个是内存填充法。手动在任务函数开头把还没用到的那段栈全部写成一个魔数，跑一段时间后去看统计。不过更省事的做法是直接利用 FreeRTOS 自己的 0xa5 填充：任务创建后立刻让它跑一段稳定逻辑，然后暂停调试器，打开 Memory 窗口跳到pxStack地址，往下翻，看到连续0xA5A5A5A5就是没用过的区域，第一个不是 0xa5 的位置往上就是最深用到的位置。用 Keil 的 Memory 窗口按 4 字节显示，一眼就能数出来用了多少字。这个方法不需要任何额外代码，我调试时几乎每天都用。

第二个是硬件观察点。在调试器里对pxStack[0]这个地址设一个"写访问断点"（Keil 的 Watchpoint，IAR 的 Data Breakpoint）。一旦有代码写到这里，CPU 立刻停下来，调用栈窗口直接告诉你越界那一刻在哪个函数。这个方法对偶发溢出特别有效，缺点是观察点在 Cortex-M3 上只有 2 个，得省着用。我一般只对怀疑最大的那个任务设。

第三个是 MPU 守卫区（进阶）。如果你的芯片有 MPU（F103 没有，F4/F7/H7 有），可以用configENABLE_MPU = 1，把每个任务栈底的一小块区域设成 no-access。栈一越界立刻触发 MemManage Fault，比任何软件检测都硬气，而且能精确指出出错的那条指令。代价是要重新规划 MPU region，工程复杂度上一个台阶，我一般只在产品定型阶段、需要长期稳定运行的场合才上。

4. 把栈调准：从 high water mark 到留余量的工程方法

前面讲的都是原理和检测，真正落到工程上，核心问题是：每个任务应该给多少字？给多了浪费 RAM，给少了半夜崩溃。我的做法是"先给宽裕、再实测收紧"，整个过程分三步。

4.1 uxTaskGetStackHighWaterMark 的正确用法与常见误读

uxTaskGetStackHighWaterMark(handle)返回的是任务运行历史上剩余栈空间的最小值，单位是字（对 Cortex-M 而言）。比如返回 32，意思是在最坏时刻它还剩下 32 个字（128 字节）没用。

这里有几个容易误读的点：

第一，它返回的是"历史最小值"，只能反映"从任务创建到现在"这段时间的情况。如果你的测试用例没覆盖到某条深分支（比如错误处理路径、OTA 升级路径、某个罕见的协议报文分支），high water mark 就会骗你。我踩过这个坑：一个协议解析任务实测 high water mark 有 80 字余量，觉得很安全，结果现场来了一个带长参数的特殊帧，走进了一条测试阶段从没跑过的深度嵌套解析路径，直接爆栈。

第二，它反映的余量包含了那 16 个字的上下文区域之外的部分，但不包含被中断抢占时产生的消耗——中断用的是 MSP，不占任务栈。所以别指望用 high water mark 来估算中断嵌套的影响。

第三，configSTACK_DEPTH_TYPE是 uint16_t 时，uxTaskGetStackHighWaterMark的返回值也是UBaseType_t（通常 uint32_t），如果栈深度超过 65535 字就需要注意，V10 之后还提供了uxTaskGetStackHighWaterMark2，返回configSTACK_DEPTH_TYPE类型的值。用之前先看自己那份 FreeRTOS 的版本。

我的使用方式是在调试期加一个低优先级的"体检任务"：

void vStackMonitorTask(void *pvParameters) { TaskHandle_t targets[] = { hTask1, hTask2, hTask3, hTaskUart }; const char *names[] = { "T1", "T2", "T3", "Uart" }; /* 给其他任务足够的运行时间，覆盖所有分支 */ vTaskDelay(pdMS_TO_TICKS(60000)); while (1) { for (int i = 0; i < 4; i++) { UBaseType_t hw = uxTaskGetStackHighWaterMark(targets[i]); /* 小于 32 字（128 字节）就报警 */ if (hw < 32) { LogWarn("%s stack margin low: %u words", names[i], hw); } } vTaskDelay(pdMS_TO_TICKS(30000)); } }

注意这里用了LogWarn而不是printf，因为体检任务自己的栈也要省着用。日志接口我会做成一个轻量的、内部只用固定缓冲区的实现，避免标准库printf那种"栈黑洞"。

4.2 不同优化等级、printf 与 FPU 对栈消耗的影响

栈消耗不是一个固定值，它随编译选项、库函数实现、编译器版本大幅波动。我实测过同一段代码在不同配置下的差异，差距能到一倍以上：

关于printf我有一条很实际的经验：只要是带串口日志的项目，我一定会单独开一个日志任务，栈给到 512 字（2KB）以上，其他任务通过队列把日志字符串发过去，而不是自己直接 print。队列里传的是指针或者预分配缓冲区的索引，这样其他任务的栈需求就降到了最小值，printf的栈开销被集中隔离在一个专门的地方。这个改动看起来麻烦，但它把"哪里需要多少栈"这件事从"每个任务都要算"变成了"只需要算一个地方"。

另一个容易被忽略的是sprintf系列。有人觉得sprintf就是往缓冲区写数据，应该不吃栈。实际上格式化过程里它内部会用到相当多的临时空间，尤其是格式化浮点数时。我实测过一个sprintf(buf, "%.3f", val)在 AC5 下吃掉了将近 200 字节栈。所以格式化浮点数的代码尽量放在大栈任务里，或者用定点数格式化绕开。

FPU 的坑我再补一句：即使任务本身不做浮点运算，只要系统里任何一个任务用了浮点，切换时的 FPU 上下文处理逻辑就牵涉到了（取决于 port 层的实现和configUSE_TASK_FPU_SUPPORT之类的配置）。稳妥的做法是给所有可能涉及浮点的任务栈统一加 72 字节预算，别去赌编译器会不会把浮点运算优化掉。

4.3 STM32F103C8T6 上的实测配置表

下面这张表来自我一个真实的项目：F103C8T6、20KB RAM、Keil AC5、-O2、无 FPU，跑 4 个业务任务 + 空闲 + 定时器任务。左列是最初拍脑袋给的，右列是跑满 24 小时压力测试、high water mark 稳定之后收紧的结果。

调整后总栈占用约 6016 字节，加上 TCB（7 × 96 = 672 字节）、队列和信号量，configTOTAL_HEAP_SIZE定在 8192 字节，还剩约 1.4KB 余量。20KB RAM 里拿出一半给 FreeRTOS 堆，剩下的给全局变量和 MSP，够用但不宽裕。

关于"留多少余量"，我的经验值分三档：

• 逻辑简单、分支固定的任务（采样、周期控制）：留 25%~30%
• 带协议解析、需要处理异常报文的通信任务：留 40%~50%
• 涉及库函数调用（printf、文件系统、TCP/IP）的任务：不收紧，按实测值原样保留

启动任务用完之后记得vTaskDelete(NULL)把自己删掉，heap_4 会把栈和 TCB 回收，这是榨 RAM 的常规操作。但要注意 heap_1 不支持释放，用了 heap_1 的话删任务不会归还内存，启动任务就等于白占一份。

注意：vTaskDelete(NULL)之后，被删任务的栈会通过空闲任务来释放，所以空闲任务的钩子里不能有阻塞操作，否则内存回收会延迟甚至卡住。

5. 那些看起来无关却把栈写爆的写法

前面几节讲的是"怎么算、怎么测、怎么防"，这一节专门讲几个我在实际项目里反复见到的、看起来跟栈毫无关系但实际上非常致命的写法。这些都是常规文档里不会提的。

5.1 把 main 里的局部变量指针交给任务

这是 RTOS 里最经典的坑之一，而且它的表现形式跟"栈溢出"很像——变量莫名其妙变成乱码。看这段代码：

int main(void) { uint8_t rxBuffer[128]; /* 分配在 main 的 MSP 栈上 */ QueueHandle_t q; Hardware_Init(); q = xQueueCreate(8, sizeof(uint8_t *)); xTaskCreate(vProcTask, "Proc", 256, &rxBuffer, 3, NULL); vTaskStartScheduler(); for (;;); }

vProcTask通过参数拿到了rxBuffer的地址，这在vTaskStartScheduler()之前是没问题的，因为 main 的栈还活着。但调度器启动后，所有任务运行在 PSP 上，main 所在的那块 MSP 空间仍然存在（它就是启动文件里的Stack_Size），所以初看好像没问题。

问题在于：MSP 那块内存不再有"栈"的语义了——任务里的中断处理会往 MSP 上压栈，各种异常处理都往上面写。你交给任务的rxBuffer随时可能被一次中断嵌套覆盖掉。我见过一个项目，主循环里定义的一个 128 字节结构体传给了解析任务，平时没事，只有在串口中断密集的时候数据才会错乱，查了整整一周。

正确的做法永远是：要传的数据要么用pvPortMalloc分配在堆上，要么定义成全局/静态变量。我更倾向于全局静态数组，因为堆上分配会带来碎片和忘记释放的问题，而全局静态区大小是编译期就能确定的。

同理，任务函数里定义的局部变量地址绝对不能通过队列传给别的任务。任务切出去之后它自己那块栈可能被另一个任务复用（如果是共享栈的极端优化场景，正常 FreeRTOS 不会，但栈里的数据在任务重新调度回来之前是不保证不被自己改写的）。这条规则简单粗暴：跨任务共享的数据必须有生命周期长于任务本身的存储位置。

5.2 定时器任务和空闲任务的栈经常被忘掉

vTaskStartScheduler()会创建两个你从来没显式指定过栈大小的任务：空闲任务和软件定时器任务（如果configUSE_TIMERS = 1）。

空闲任务的栈由configMINIMAL_STACK_SIZE决定，常见值是 128 字。它在正常运行时不做什么重活，但如果你在vApplicationIdleHook里加了逻辑——比如进入低功耗模式、跑一个内存回收检查、或者查某个状态——那 128 字可能就不够了。我见过在空闲钩子里调malloc的，malloc内部的堆遍历也会吃栈，直接爆。

软件定时器任务的栈由configTIMER_TASK_STACK_DEPTH决定，默认通常是configMINIMAL_STACK_SIZE * 2。这里有个特性需要知道：所有软件定时器的回调函数都是在定时器任务的上下文里串行执行的，也就是说它们在共用同一个任务栈。所以只要有一个回调里做了稍微重一点的事（发日志、格式化字符串、调用某个协议栈），整个定时器任务就危险了。

我的建议是：定时器回调里只做最简单的事——置标志位、发信号量、投递队列，真正的处理放到专门的任务里。如果非要在回调里做格式化，那就把configTIMER_TASK_STACK_DEPTH显式指定成 384 或者 512 字，别依赖默认值。

5.3 中断嵌套吃的是 MSP，别只盯着任务栈

回到第 1 节那个结论：中断永远用 MSP。这意味着你在优化任务栈的时候，MSP 的大小是一个独立变量，必须单独评估。

评估 MSP 的方法是数最坏情况下的中断嵌套层数和每一层 ISR 的栈用量。每一层中断嵌套，硬件压栈 8 个字（32 字节），如果开了 FPU 且中断里用了浮点，再加上 72 字节。ISR 自身的局部变量、它调用的函数的栈帧，全部叠加在这个基础上。

以 F103 为例：如果三个中断可以同时挂起并且优先级允许嵌套，最坏情况是三层嵌套，光硬件压栈就是 96 字节，加上每个 ISR 里的局部缓冲（假设每个 32 字节）和调用深度，加起来 300~400 字节很常见。启动文件默认的 0x400（1024 字节）刚好够用，但如果你的 ISR 里做了什么"顺手打印一下调试信息"的事，那就危险了。

我的做法是：

• 中断服务函数里只置标志、只投递队列、只触发任务，绝不做串口打印和浮点运算
• 启动文件里的Stack_Size在 F103 上给到 0x600（1.5KB），F4/F7 上给到 0x1000
• 需要打印的调试信息一律通过队列丢给日志任务
• 每个中断优先级分组的设置要清楚，避免意外形成深嵌套

还有一点：SysTick 和 PendSV 也是异常，也用 MSP。每次任务切换都会经过 PendSV，它自身会压栈。虽然 PendSV 处理很短，但它发生得极其频繁，属于"固定开销"，评估 MSP 时要把它算进去。

我遇到过一个非常隐蔽的案例：项目里加了一个 DMA 传输完成中断，ISR 里调用了xQueueSendFromISR。这个函数本身栈开销很小，但它触发的任务切换会在 PendSV 里完成，而 PendSV 恰好和另一个高优先级中断发生了嵌套，MSP 在那一刻被顶到了极限。最后把启动文件的Stack_Size从 0x400 提到 0x600 之后问题消失。整个过程最难的部分是确认"这真的是 MSP 的问题"——因为所有任务栈的 high water mark 看起来都很健康。

判断方法其实有一个很简单的技巧：在 HardFault 处理函数里读 MSP 和 PSP 的值。如果异常发生时 MSP 已经低于__initial_sp - Stack_Size，那基本可以确定是 MSP 溢出。Keil 的调试器里在 HardFault_Handler 打断点，看寄存器窗口的 MSP 值，和你启动文件里算出来的 MSP 下界比较一下，一目了然。

最后分享一个我自己固定用的习惯：每次新增一个任务，先在纸面上（或者注释里）写清楚它的调用链大概有多深、有没有大数组、会不会调用库函数，先按这个估一个值，然后跑满覆盖所有分支的压力测试，用 high water mark 收紧。这个过程听起来啰嗦，但它把"栈"从一个神秘的随机崩溃源，变成了一张可以随时查阅的表格。项目做到后期，当别人在半夜被叫起来查死机的时候，你手里那张表就是最大的底气。