📚 课程目录第2章任务状态与栈回溯

任务状态与栈回溯：任务状态机分析、任务栈溢出检测、调用栈回溯技术

调试 RTOS 系统，说白了就是跟任务状态和栈空间打交道。我见过太多工程师，代码逻辑明明没问题，系统就是跑飞。最后查出来，要么是任务状态乱了，要么是栈溢出了。这一章，我们就来啃这两块硬骨头。

任务状态机：别让任务卡在奇怪的地方

每个 RTOS 任务都有生命周期。从创建到删除，任务会在几个状态之间跳来跳去。这个状态跳转，就是任务状态机。

我习惯把任务状态分为四类：就绪、运行、阻塞和挂起。有些 RTOS 还会细分，但核心逻辑不变。

状态	含义	典型触发条件
就绪 (Ready)	任务已准备好，等待调度器分配 CPU	任务创建、阻塞条件解除、被唤醒
运行 (Running)	任务正在占用 CPU 执行	调度器选中该任务
阻塞 (Blocked)	任务等待某个事件或资源	等待信号量、消息队列、延时
挂起 (Suspended)	任务被强制暂停，不参与调度	调用 vTaskSuspend()

调试时，我第一件事就是看任务当前在哪个状态。如果一个任务本该在运行，却一直卡在阻塞状态，那肯定是它等的东西没来。我曾经遇到过一个案例：一个传感器采集任务总是超时，查了半天，发现是它等待的信号量被另一个任务占着没释放。说白了，就是死锁的前兆。

  调试要点： 在 RTOS 的调试接口里，通常有命令可以打印所有任务的状态。比如 FreeRTOS 的 vTaskList() 或 uxTaskGetSystemState()。养成习惯，系统卡顿时先 dump 任务列表。

任务栈溢出：无声的杀手

栈溢出是嵌入式系统里最难查的问题之一。为什么？因为它不会立刻报错。往往是程序跑着跑着，突然跳到一个奇怪的地方，或者某个全局变量莫名其妙被改了。

栈溢出说白了，就是任务用栈空间超过了分配的大小。溢出的数据会覆盖相邻的内存区域。如果相邻区域存的是另一个任务的 TCB（任务控制块）或者全局变量，那后果不堪设想。

我自己的项目里，就吃过这个亏。一个通信任务，平时收发数据都正常。但有一次数据包特别大，栈直接爆了。结果呢？系统调度乱了，所有任务都开始随机崩溃。查了整整两天，最后用栈溢出钩子函数才定位到问题。

栈溢出检测方法

常用的检测手段有三种。我按推荐程度排个序：

硬件边界检测（MPU/MMU）：最可靠，但需要硬件支持。给栈区域设置不可访问的边界页，一旦溢出立刻触发异常。
栈填充标记法：任务创建时，把整个栈空间填充成固定模式（比如 0xDEADBEEF）。运行时定期检查栈顶附近的标记是否被改写。FreeRTOS 的 configCHECK_FOR_STACK_OVERFLOW 就是干这个的。
栈指针监控：在任务切换时，检查当前栈指针是否超出了合法范围。这个方法开销小，但只能检测到严重溢出。

我的习惯： 开发阶段，我会把栈空间翻倍分配，同时开启栈填充标记法。等系统稳定了，再根据实际使用量调整栈大小。别一上来就抠门，省那几十个字节，后面调试的时间成本高得多。

调用栈回溯：从崩溃现场找到真凶

系统崩溃了，CPU 停在某个地址。这时候你手里只有一堆寄存器和内存数据。怎么知道程序是怎么跑到这里来的？调用栈回溯就是干这个的。

调用栈里存的是函数的返回地址。每调用一个函数，返回地址就被压入栈中。回溯时，我们从当前栈指针开始，一路往上找，就能还原出函数调用链。

嗯，这里要注意：不同架构的栈增长方向不同。ARM Cortex-M 是向下增长的，而有些架构是向上增长的。回溯算法必须适配。

手动回溯步骤

假设你手里只有调试器，没有 IDE 的自动回溯功能。你可以这么做：

读取当前栈指针 (SP) 和链接寄存器 (LR)。
如果 LR 的 bit[2] 为 1，说明当前函数使用了 FP（帧指针），从 FP 指向的内存读取返回地址。
如果 LR 的 bit[2] 为 0，说明是叶子函数，返回地址就在 LR 里。
沿着栈帧链，依次读取每个栈帧里保存的返回地址。
把返回地址对照符号表（map 文件），翻译成函数名。

// 伪代码：ARM Cortex-M 调用栈回溯
void stack_trace(uint32_t *sp, uint32_t lr) {
    uint32_t *fp;
    uint32_t pc;

    if (lr & 0x04) {
        // 使用帧指针
        fp = (uint32_t *)*(sp + 1); // 假设 FP 保存在 SP+4 位置
        pc = *(fp - 1);             // 返回地址在 FP-4 位置
    } else {
        pc = lr;
    }

    printf("0x%08X\n", pc);

    while (fp != NULL) {
        pc = *(fp - 1);
        printf("0x%08X\n", pc);
        fp = (uint32_t *)*fp; // 上一帧的 FP
    }
}

避坑指南： 我曾经在调试一个优化等级开到了 -O3 的系统时，发现调用栈回溯出来的函数名完全对不上。原因是编译器优化后，函数调用被内联了，栈帧结构被破坏了。遇到这种情况，先把优化等级降到 -O0 或 -Og，等定位到问题再开优化。

知识体系：任务状态与栈回溯的核心逻辑

下面这张图，把任务状态机、栈溢出检测和调用栈回溯的关系串起来了。你可以把它当作调试时的检查清单。

实战建议：调试三板斧

总结一下，遇到 RTOS 系统异常，我的调试顺序是这样的：

第一板斧： 打印所有任务状态。看有没有任务卡在阻塞状态，或者有任务长时间没被调度。
第二板斧： 检查栈使用情况。用 uxTaskGetStackHighWaterMark() 看每个任务的栈剩余空间。如果某个任务的剩余空间小于 10%，赶紧加大栈。
第三板斧： 如果系统崩溃了，做调用栈回溯。把崩溃时的 PC 值和栈数据导出来，对照 map 文件还原调用链。

小技巧： 在任务切换的钩子函数里，定期检查当前任务的栈指针。如果栈指针接近栈底，就打印一条警告日志。这样可以在溢出发生前就发现问题。

这三板斧用熟了，大部分 RTOS 调试问题都能快速定位。记住，别一上来就怀疑代码逻辑，先看看任务状态和栈空间。很多时候，问题就出在这些基础环节上。