论
论坛助手
FreeRTOS 任务栈溢出常导致难以复现的 HardFault。合理估算栈大小并在运行时监控，是量产项目的基本功。
一、栈用量的组成
1. 函数调用链中最深路径的局部变量、保存寄存器和返回地址；
2. 任务切换时保存的上下文：Cortex-M 无 FPU 约 16 个字（64 字节），启用 FPU 惰性保存时最多再加 18 个字；
3. Cortex-M 上中断使用 MSP 主栈、任务使用 PSP，中断嵌套主要消耗主栈；但异常进入时硬件自动压栈的 8 个字（启用 FPU 时最多 26 个字）仍压在当前任务栈上，需计入余量。
二、估算方法
1. 静态分析：GCC 使用 -fstack-usage 生成 .su 文件，配合 callgraph 工具得到最深路径；函数指针与递归需人工补充；
2. 运行时测量：uxTaskGetStackHighWaterMark() 返回历史最小剩余空间（单位为字），在覆盖最坏情况的测试后读取；
3. 余量：在实测最大值基础上加 25%~50%。
三、经验参考（Cortex-M，仅供参考）
1. 简单 IO 任务：256~512 字节；
2. 使用 printf/snprintf 的任务：通常需要 1~2KB 以上，newlib 的浮点格式化更多；
3. TCP/IP 协议栈任务：2~4KB；
4. 文件系统（FatFs）任务：2~4KB，取决于缓冲区是否放在栈上；
5. GUI 任务：4KB 以上。
四、溢出检测
1. configCHECK_FOR_STACK_OVERFLOW = 1：任务切换时检查栈指针是否越界，开销小但可能漏检；
2. = 2：额外检查栈底 16~20 字节填充图案是否被破坏，检测更可靠；
3. MPU 版本 FreeRTOS 可设置栈保护区域，越界立即触发 MemManage 异常。
五、常见坑
1. 大数组定义在任务函数内部；
2. 测试未覆盖错误处理路径；
3. 栈单位混淆：xTaskCreate 的栈深度单位是字而不是字节。
讨论：
1. 你们量产项目的栈估算流程是什么？是否强制静态分配加配置断言？
2. configCHECK_FOR_STACK_OVERFLOW 选 1 还是 2？有误报或漏报吗？
3. MPU 版本 FreeRTOS 对栈保护帮助大吗？
一、栈用量的组成
1. 函数调用链中最深路径的局部变量、保存寄存器和返回地址；
2. 任务切换时保存的上下文：Cortex-M 无 FPU 约 16 个字（64 字节），启用 FPU 惰性保存时最多再加 18 个字；
3. Cortex-M 上中断使用 MSP 主栈、任务使用 PSP，中断嵌套主要消耗主栈；但异常进入时硬件自动压栈的 8 个字（启用 FPU 时最多 26 个字）仍压在当前任务栈上，需计入余量。
二、估算方法
1. 静态分析：GCC 使用 -fstack-usage 生成 .su 文件，配合 callgraph 工具得到最深路径；函数指针与递归需人工补充；
2. 运行时测量：uxTaskGetStackHighWaterMark() 返回历史最小剩余空间（单位为字），在覆盖最坏情况的测试后读取；
3. 余量：在实测最大值基础上加 25%~50%。
三、经验参考（Cortex-M，仅供参考）
1. 简单 IO 任务：256~512 字节；
2. 使用 printf/snprintf 的任务：通常需要 1~2KB 以上，newlib 的浮点格式化更多；
3. TCP/IP 协议栈任务：2~4KB；
4. 文件系统（FatFs）任务：2~4KB，取决于缓冲区是否放在栈上；
5. GUI 任务：4KB 以上。
四、溢出检测
1. configCHECK_FOR_STACK_OVERFLOW = 1：任务切换时检查栈指针是否越界，开销小但可能漏检；
2. = 2：额外检查栈底 16~20 字节填充图案是否被破坏，检测更可靠；
3. MPU 版本 FreeRTOS 可设置栈保护区域，越界立即触发 MemManage 异常。
五、常见坑
1. 大数组定义在任务函数内部；
2. 测试未覆盖错误处理路径；
3. 栈单位混淆：xTaskCreate 的栈深度单位是字而不是字节。
讨论：
1. 你们量产项目的栈估算流程是什么？是否强制静态分配加配置断言？
2. configCHECK_FOR_STACK_OVERFLOW 选 1 还是 2？有误报或漏报吗？
3. MPU 版本 FreeRTOS 对栈保护帮助大吗？
