3、栈(Stack)深度分析：理解栈溢出原理，学习通过栈填充模式计算最大栈深度，掌握栈大小配置技巧。
栈溢出，这应该是嵌入式开发里最常见的“死法”之一了。我刚入行那会儿，就吃过这个亏。一个蓝牙耳机项目，功能都调通了，结果放音乐半小时就死机。查了三天，最后发现是某个中断服务函数里递归调用把自己给撑爆了。嗯，从那以后，我对栈就特别上心。
说白了，栈就是一块内存，专门用来存局部变量、函数调用地址、寄存器现场这些东西。每个任务或者中断都有自己的栈空间。如果函数嵌套太深，或者局部变量太大，栈就会越界，踩到别人的地盘——轻则数据错乱，重则直接 HardFault。
栈溢出是怎么发生的？
你想想看，栈的生长方向通常是向下的。从高地址往低地址长。每次调用函数，就把返回地址、参数、局部变量压进去。返回的时候再弹出来。如果压进去的东西太多，超过了栈底（也就是最低地址），那就溢出了。
我见过最典型的场景：
- 中断嵌套太深：一个中断还没处理完，又来一个更高优先级的。每个中断都要用栈，嵌套个三四层，栈就扛不住了。
- 局部变量太大：有人直接在函数里定义一个 1KB 的数组。你想想，如果栈总共才 512 字节，这不直接炸了吗？
- 递归调用：嵌入式里我一般不建议用递归。除非你能精确算好深度，否则就是给自己埋雷。
如何计算最大栈深度？
这个问题其实挺头疼的。因为栈的使用是动态的，你没法静态分析出 100% 准确的最大深度。但我们可以用工程方法逼近它。
我个人最常用的方法是栈填充模式。说白了，就是初始化时把整个栈区域填上一个固定值，比如 0xDEAD 或者 0xAA。然后跑程序，跑完所有功能后，回头检查栈空间里还有多少填充值没有被覆盖。
具体步骤是这样的：
- 在系统启动时，把每个任务的栈空间全部填充为 0xDEAD。
- 正常运行所有功能——包括最极端的情况，比如所有中断同时触发、最大数据量处理等。
- 运行一段时间后，停下来检查栈空间。从栈底开始往上数，找到第一个不是 0xDEAD 的地址。
- 这个地址到栈顶的距离，就是实际使用的最大栈深度。
代码实现其实很简单：
// 栈填充函数
void StackFill(uint32_t *stack_start, uint32_t stack_size_words) {
for (uint32_t i = 0; i < stack_size_words; i++) {
stack_start[i] = 0xDEADBEEF;
}
}
// 栈使用检查函数
uint32_t StackUsedMax(uint32_t *stack_start, uint32_t stack_size_words) {
uint32_t used = 0;
for (uint32_t i = 0; i < stack_size_words; i++) {
if (stack_start[i] != 0xDEADBEEF) {
used = (stack_size_words - i) * 4; // 每个字4字节
break;
}
}
return used;
}
栈大小配置技巧
拿到最大栈深度之后，怎么配？这里有个经验法则：
| 场景 | 建议余量 | 说明 |
|---|---|---|
| 主任务 | 实际使用 + 30% | 主任务逻辑复杂，预留多一些 |
| 中断服务函数 | 实际使用 + 50% | 中断可能嵌套，风险高 |
| 低优先级任务 | 实际使用 + 20% | 逻辑简单，可以少留 |
| 空闲任务 | 实际使用 + 100% | 反正内存闲着也是闲着 |
为什么留余量？因为你的测试可能没覆盖到所有极端情况。比如某个罕见的中断组合，或者某个特殊的数据包。我一般会在实际测量值上再加 50% 作为安全边界。
实战中的避坑指南
我曾经在一个项目里遇到过这样的问题：用栈填充法测出来最大用了 200 字节，于是配了 300 字节。结果量产之后，有 1% 的设备会死机。查了很久才发现，是某个外设的 DMA 传输完成中断里，调用了 printf 打印调试信息。printf 本身就要用不少栈，再加上中断嵌套，实际栈使用量比测试时多了 100 多字节。
所以这里有几个建议：
- 不要在中断里调用复杂函数——尤其是 printf、malloc 这种。
- 测试时要模拟最坏情况——把所有中断都打开，把数据量拉到最大。
- 留够安全余量——我一般至少留 30%，关键任务留 50%。
- 用 MPU 做硬件保护——如果芯片支持 MPU，可以给栈区域设置访问权限，溢出时直接触发异常，比死机后慢慢查要快得多。
嗯，说到 MPU，其实很多 TWS 芯片是不支持的。那怎么办？我个人的做法是：在栈底放一个“哨兵”变量，初始化为固定值。每次任务切换时检查这个哨兵有没有被踩。如果被踩了，说明栈溢出了，立刻记录现场并复位。这样至少能知道是哪个任务出了问题。
// 哨兵变量
volatile uint32_t stack_guard = 0xDEADBEEF;
// 任务切换时检查
void TaskSwitchCheck(void) {
if (stack_guard != 0xDEADBEEF) {
// 栈溢出！记录现场
LogError("Stack overflow detected!");
// 可以在这里保存寄存器、任务ID等信息
while(1); // 或者复位
}
}
这个方法虽然简单，但很实用。我在好几个项目里都用过，帮我们抓到了不少隐蔽的栈溢出问题。
最后总结一下：栈深度分析不是一次性工作。随着代码迭代，函数调用关系会变，局部变量大小也会变。我建议每个大版本发布前，都重新跑一遍栈填充测试。别嫌麻烦，这比产品上市后出问题再召回要划算得多。