4、任务堆栈分析与溢出检测：堆栈生长方向与MPU保护、堆栈使用率统计方法、硬件故障（HardFault）定位与堆栈回溯

堆栈溢出，可以说是RTOS开发中最常见的“隐形杀手”。程序跑着跑着突然死机，或者某个任务莫名其妙地崩溃，十有八九是堆栈惹的祸。我这些年调过的板子里，至少有一半的HardFault最终都指向了堆栈问题。今天咱们就把这块硬骨头啃下来。

4.1 堆栈生长方向与MPU保护

先搞清楚一个基本概念：堆栈是怎么长的？

ARM Cortex-M系列内核的堆栈是向下生长的。也就是说，堆栈指针SP从高地址往低地址移动。每次压栈，SP先减4，再把数据写进去。出栈则相反。

你想想看，如果任务A的堆栈只有256字节，但函数调用嵌套太深，或者局部变量声明了一个大数组，堆栈指针一路往下冲，就会踩到相邻任务的控制块或者全局变量区。这就是溢出。

怎么防？硬件级别的保护最靠谱。Cortex-M3/M4/M7都带了MPU（内存保护单元），可以给每个任务的堆栈区域设置读写权限。

配置MPU保护堆栈的伪代码大致如下：

// 假设任务堆栈起始地址为 task_stack_start，大小为 stack_size
// 红区大小为 RED_ZONE_SIZE

void MPU_ConfigTaskStack(uint32_t task_stack_start, uint32_t stack_size) {
    // 1. 禁用MPU
    MPU->CTRL = 0;

    // 2. 配置红区（堆栈底部，不可访问）
    MPU->RBAR = (task_stack_start) | REGION_0 | MPU_RGN_NO_ACCESS;
    MPU->RASR = (RED_ZONE_SIZE_LOG2 << 1) | MPU_RGN_ENABLE;

    // 3. 配置可用的堆栈区域（读/写，可执行）
    MPU->RBAR = (task_stack_start + RED_ZONE_SIZE) | REGION_1 | MPU_RGN_FULL_ACCESS;
    MPU->RASR = ((stack_size - RED_ZONE_SIZE) << 1) | MPU_RGN_ENABLE;

    // 4. 使能MPU，开启MemManage Fault
    MPU->CTRL = MPU_CTRL_ENABLE_Msk | MPU_CTRL_PRIVDEFENA_Msk;
    SCB->SHCSR |= SCB_SHCSR_MEMFAULTENA_Msk;
}

我在一个工业控制项目里用过这个方案。当时有个任务偶尔会死机，查了两天没头绪。加上MPU红区保护后，第二天就抓到了溢出——一个局部数组在特定分支下越界写了。如果没有MPU，这种偶发问题可能要排查一周。

4.2 堆栈使用率统计方法

光有保护还不够，你得知道每个任务到底用了多少堆栈。这样才能合理分配，既不多占内存，也不留隐患。

统计堆栈使用率，最经典的方法是“水印法”。说白了，就是在任务创建时，把整个堆栈区域填上一个固定模式（比如0xDEADBEEF或0x5A5A5A5A）。任务运行一段时间后，从栈底往上扫描，找到第一个被改写的位置，就能算出最大使用深度。

代码实现也很直接：

#define STACK_FILL_PATTERN  0xDEADBEEF

uint32_t Task_GetStackUsage(TaskHandle_t task) {
    StackType_t *stack_base = (StackType_t *)task->pxStack;  // 栈底（低地址）
    uint32_t stack_size = task->uxStackDepth;
    uint32_t used = 0;

    // 从栈底向上扫描
    for (uint32_t i = 0; i < stack_size; i++) {
        if (stack_base[i] != STACK_FILL_PATTERN) {
            used = (stack_size - i) * sizeof(StackType_t);
            break;
        }
    }

    return used;
}

实际项目中，我一般会在系统空闲任务里定期调用这个函数，把每个任务的堆栈使用率打印出来。调试阶段尤其有用。

任务名称	堆栈大小（字节）	最大使用（字节）	使用率	建议调整
Task_Comm	1024	876	85.5%	偏紧，建议扩到1280
Task_Sensor	512	128	25.0%	浪费，可缩到256
Task_Display	2048	1532	74.8%	合理，保持
Task_Idle	256	64	25.0%	可缩到128

4.3 硬件故障（HardFault）定位与堆栈回溯

堆栈溢出最直接的后果就是HardFault。但HardFault不一定都是堆栈问题，也可能是野指针、数组越界、或者访问了非法地址。

遇到HardFault，第一件事不是重刷固件，而是保存现场。Cortex-M在进入HardFault时，会自动把R0-R3、R12、LR、PC、xPSR压入当前堆栈。我们要做的就是把这些数据读出来，然后反推程序崩溃的位置。

我常用的HardFault处理函数长这样：

void HardFault_Handler(void) {
    // 获取当前堆栈指针（MSP或PSP）
    uint32_t *stack_ptr;
    __asm volatile(
        "TST LR, #4\n\t"
        "ITE EQ\n\t"
        "MRSEQ %0, MSP\n\t"
        "MRSNE %0, PSP\n\t"
        : "=r" (stack_ptr)
    );

    // 从堆栈中提取寄存器
    uint32_t r0  = stack_ptr[0];
    uint32_t r1  = stack_ptr[1];
    uint32_t r2  = stack_ptr[2];
    uint32_t r3  = stack_ptr[3];
    uint32_t r12 = stack_ptr[4];
    uint32_t lr  = stack_ptr[5];
    uint32_t pc  = stack_ptr[6];
    uint32_t xpsr = stack_ptr[7];

    // 打印崩溃信息
    printf("=== HardFault ===\r\n");
    printf("PC: 0x%08X\r\n", pc);
    printf("LR: 0x%08X\r\n", lr);
    printf("R0: 0x%08X\r\n", r0);
    printf("R1: 0x%08X\r\n", r1);
    printf("R2: 0x%08X\r\n", r2);
    printf("R3: 0x%08X\r\n", r3);

    // 根据PC地址反查符号表
    // 可以用addr2line工具或IDE的map文件

    while(1);  // 死循环，等待调试器介入
}

拿到PC值后，怎么定位到具体代码？

方法一：用IDE的map文件。在.map里搜索PC地址，找到对应的函数名和偏移量。方法二：用addr2line工具。命令大概是：arm-none-eabi-addr2line -e firmware.elf 0x08001234。它会直接告诉你文件名和行号。

堆栈回溯（Stack Backtrace）是更高级的定位手段。它通过遍历栈帧，把函数调用链完整还原出来。ARM的栈帧结构是固定的：每个函数入口会压入LR和FP（帧指针），出口恢复。我们顺着FP链就能回溯。

一个简化的回溯实现：

void StackBacktrace(uint32_t *fp) {
    printf("=== Stack Backtrace ===\r\n");
    for (int i = 0; i < 10; i++) {  // 最多回溯10层
        if (fp == NULL || fp == (uint32_t *)0xFFFFFFFF) break;

        uint32_t lr = fp[1];  // 栈帧中LR的位置
        uint32_t pc = fp[2];  // 栈帧中PC的位置（有些编译器不同）

        printf("[%d] LR: 0x%08X, PC: 0x%08X\r\n", i, lr, pc);

        // 移动到上一帧
        fp = (uint32_t *)fp[0];
    }
}

当然，实际项目中我建议直接用调试器的回溯功能。J-Link、ST-Link都支持自动解析调用栈。但如果你在产线测试或者远程升级场景下没法接调试器，那上面的代码就是救命稻草。

下面这张图总结了堆栈分析与故障定位的完整流程：

最后说一句，堆栈问题最好的解决策略是预防。在开发阶段就做好MPU保护和水印统计，别等到产品上线了才去查HardFault。那时候你面对的可能是客户的投诉电话，而不是IDE的调试界面。