摘要：系统运行久了随机重启，或者 HardFault 指向了奇怪的地址？不是内存碎片，而是 任务栈溢出（Stack Overflow）。本文教你如何利用 FreeRTOS 的 Stack Watermark（栈水印）​ 精准定位到底是哪个任务吃掉了栈空间。

---

一、问题描述（现象）

**FreeRTOS 系统，任务跑着跑着就挂了；

调试发现，有时候卡在 HardFault，有时候卡在 vTaskDelay；

加大 configTOTAL_HEAP_SIZE没用，问题依旧。**

很多工程师的直觉是：

1. 堆（Heap）不够大？

2. 任务优先级设高了？

3. 函数里定义了大数组？

---

二、原理分析

1. 物理模型

RTOS 中，每个任务都有自己独立的栈。

Task A Stack (512B) | Task B Stack (256B) | Heap | ...

2. 核心参数

• Stack Depth（栈深度）：创建任务时指定的字数（Words），不是字节。

• Stack Watermark（栈水印）：FreeRTOS 在每个栈位置写入特定的标记（如 0xa5），运行时检查还剩多少标记未被覆盖。

• MSP vs PSP：中断用主栈，任务用进程栈。

3. 反直觉真相

“栈溢出不一定立刻死机。”

• 栈溢出往往是悄无声息地覆盖了其他任务的数据或TCB（任务控制块）。

• 当你调用 xQueueSend或 vTaskDelay时，系统操作被你破坏的数据结构，才会崩溃。

• 这就是为什么 Bug 看起来是随机的。

---

三、工程级解决方案

方案 1：开启栈溢出检测（必做）

在 FreeRTOSConfig.h中开启钩子函数。

#define configCHECK_FOR_STACK_OVERFLOW 2

并实现回调函数：

void vApplicationStackOverflowHook(TaskHandle_t xTask, char *pcTaskName)
{
    printf("Stack Overflow in: %s\n", pcTaskName);
    while(1); // 死机报警
}

方案 2：使用 Watermark 查看剩余量（调试神器）

在调试器中，或者在运行时打印栈剩余情况。

UBaseType_t uxHighWaterMark;

uxHighWaterMark = uxTaskGetStackHighWaterMark(NULL);
printf("Task Stack Left: %d words\n", uxHighWaterMark);

经验值：

• 如果剩余量 < 20 words：非常危险，立刻加大栈。

• 如果剩余量 > 100 words：比较安全。

方案 3：不要递归，不要大数组

栈里最怕两样东西：

1. 递归函数：栈空间成倍增长。

2. 局部大数组：uint8_t buffer[1024];（这会直接干掉 1KB 栈）。

---

四、选型避坑建议

1. 中断栈是独立的：

   • configISR_STACK_SIZE必须足够大，尤其是用了嵌套中断。

2. Idle Task 栈：

   • Idle 任务默认栈很小，如果你在 Idle 钩子里做事，要加栈。

3. 栈的大小单位：

   • xTaskCreate的单位是 字（Word）（4字节）。

   • 填 512实际上是 2048字节。

---

五、总结 Checklist

• [ ] 是否开启了 configCHECK_FOR_STACK_OVERFLOW？

• [ ] 是否通过 uxTaskGetStackHighWaterMark确认了最小剩余栈？

• [ ] 任务里是否有大数组或递归调用？

• [ ] 中断栈（ISR Stack）是否足够大？

---

六、写在最后（关注我，少走弯路）

我是 gqqsherry，一个拒绝调包、专注底层逻辑的嵌入式工程师。

裸机是单打独斗，RTOS 是集团军作战。栈溢出是 RTOS 的头号杀手，学会看 Watermark，你就掌握了系统的生命线。

关注我的专栏《嵌入式底层避坑指南》，下一篇我们将深入解析 《中断里发消息队列，系统直接崩？》。

👉 下一篇预告：《中断里发消息队列，系统直接崩？》

---

原创文章，转载请注明出处。