安克创新嵌入式一面：MCU 内存布局与 FreeRTOS 栈排查

《面试题目》

1. MCU 上电运行后，代码、常量、已初始化数据、未初始化数据和临时运行数据一般会分布在哪些不同区域？各区域分别承担什么职责，地址安排通常有什么规律？
2. 在资源受限的嵌入式系统中，函数调用产生的临时空间与动态申请得到的空间，在分配方式、释放时机、生存期、速度以及潜在风险上有哪些本质区别？
3. 如果设备偶发死机、复位或进入异常处理，怀疑与调用栈被破坏有关，可以从哪些运行时指标、填充检测、异常现场信息入手排查？工程上怎样降低这类风险？
4. 长期运行的固件出现可用动态内存越来越少、最终分配失败的情况，通常如何定位和预防？为什么 MCU 项目更倾向于用静态区域、内存池或固定缓冲来替代频繁动态申请？
5. FreeRTOS 任务运行一段时间后触发硬件异常，怎样逐步判断根因是否与任务栈余量不足有关？会关注哪些栈水位、溢出检测钩子、异常寄存器或现场信息？
6. 串口接收帧长不固定时，如何结合 DMA、空闲中断、超时机制或协议长度字段来划分帧边界，同时减少 CPU 搬运并保证缓冲安全？

《参考解析》

1. MCU 上电后的内存分区。分区由链接脚本（STM32F103xC_FLASH.ld、memory.x）决定。Flash 侧放 .isr_vector（中断向量表，Cortex-M 复位后要从这里取初始 MSP 和 Reset_Handler，所以必须落在 Flash 起始地址）、.text（代码）、.rodata（const 全局量与字符串字面量）；RAM 侧放 .data（有非零初值的全局/静态变量）、.bss（未初始化或零初值的全局/静态变量）、heap（pvPortMalloc 从低地址向高地址长）、stack（主栈从 RAM 顶端向低地址长，RTOS 下每个任务另有独立栈）。两者之间的耦合点是启动代码：.data 的初值物理上存在 Flash，复位后由 startup 里的拷贝循环搬到 RAM；.bss 由启动代码清零。之所以要区分这两种，是因为只有「初值非零」才必须在镜像里保留一份原始数据，.bss 在镜像中只记录起止地址、不下发实际字节，所以 .bss 变大不会让烧录体积变大，但会直接吃掉 RAM。地址规律可以记成一句话：Flash 从低往高排代码与常量，RAM 从低往高排 .data/.bss/堆，栈从 RAM 末尾往下，中间剩下的空间就是留给堆栈相向生长的余量——这也是栈溢出往往先踩到堆的原因。

2. 栈与堆的本质区别。栈是「移动栈指针式」的分配，SUB sp, sp, #n 就完成了分配，函数返回时把 sp 还原即完成释放：O(1)、无碎片、不会失败，生存期严格等于函数帧，出作用域自动回收；代价是容量固定且必须在编译/链接期确定，溢出后踩的是别的数据而且往往不当场报错。堆要走分配器的空闲链表，分配时要查表、切分、维护块头，释放时要合并相邻空闲块，所以更慢，还可能返回 NULL；生存期由程序员手工管理，风险是泄漏、碎片、重复释放和越界写坏块头。还有一个容易被忽略的点：pvPortMalloc/free 内部通常要进临界区（挂起调度器或加锁），因此绝不能在中断里调用，也不具备可重入性；栈则是天生的可重入结构，这也是 RTOS 让每个任务独立持栈的原因。

3. 怀疑栈被破坏时的排查手段。分三层推进。①编译期：打开 -fstack-protector-strong 让函数返回前校验 canary，用 -Wframe-larger-than=N 把大栈帧找出来。②运行时填充检测：任务创建时把栈填成固定图案（FreeRTOS 用 0xA5），跑一段时间后用 uxTaskGetStackHighWaterMark() 反查历史最低水位；要更早发现越界，可以用 MPU 在栈边界外挂一个不可访问区域（vTaskAllocateMPURegions），越界立即触发 MemManage Fault 而不是等到数据被改坏。③异常现场：在 HardFault 处理函数里读 SCB->CFSR，MMFSR/BFSR/UFSR 分别对应存储器管理、总线和用法错误，地址相关寄存器 MMFAR/BFAR 直接给出出错地址；再通过 EXC_RETURN（LR 的 bit2）判断异常前用的是 MSP 还是 PSP，从对应栈上取出硬件压栈的 PC/LR/xPSR，把 PC 丢进 .map 文件就能定位到函数和行号。降低风险的工程习惯：每个任务栈留 30% 以上余量、禁止在大函数里放 uint8_t buf[1024] 这类局部大数组、printf/sprintf 带浮点要单独核栈、递归改迭代、vApplicationStackOverflowHook 里只做最小动作（此时栈已经坏了，再打印日志往往二次崩溃）。

4. 动态内存越来越少怎么定位和预防。先看趋势，再找源头。周期打点 xPortGetFreeHeapSize() 与 xPortGetMinimumEverFreeHeapSize()：前者持续下降说明有泄漏，后者不断探底而前者稳定说明是碎片（峰值占用高、块被切碎）。定位手段有三类：在 pvPortMalloc/vPortFree 上挂钩子记录地址、大小和调用者返回地址，把 alloc/free 做成对配平、求差集就能看出谁没还；用 heap_5 把内存拆成多个区域分别观测，能把范围缩到具体模块；打开 configUSE_MALLOC_FAILED_HOOK，在分配失败那一刻打印现场。预防永远比定位划算：启动阶段按最大帧长、最大并发数一次性建好定长内存池，运行期只从池里取还；用 configSUPPORT_STATIC_ALLOCATION 让任务、队列、信号量静态创建；变长缓冲一律改成环形缓冲加硬上限；中断和热路径里绝不分配。碎片的根因是「不同大小 + 不同生存期」的申请混在一起，只要做到定长加池化，这类问题基本就消失了。

5. FreeRTOS 任务栈不足的判定路径。①先量水位：uxTaskGetStackHighWaterMark(NULL) 返回该任务历史上剩余栈的最小值（单位是字，Cortex-M 上要乘 4），接近 0 就危险；配合 configGENERATE_RUN_TIME_STATS 和 vTaskList 找出栈用得最狠的任务。②再上检测：configCHECK_FOR_STACK_OVERFLOW 设为 2，FreeRTOS 会在每次上下文切换时校验栈末端图案，命中就回调 vApplicationStackOverflowHook，能拿到任务名和 TCB。③最后看现场：如果已经进了 HardFault，先看 CFSR 的 UFSR.STKOF 位（硬件检出的栈溢出标志），再看异常栈帧里的 PC 是否落在该任务调用的库函数中——printf/sprintf/sscanf 这类带格式化的函数是重灾区。还有两个容易误判的点：中断用的是 MSP，如果中断里调了重函数或开了独立的 ISR 栈，溢出的不是任何一个任务栈；任务调用 xQueueSend、vTaskDelay 等 API 本身也会吃几十字节栈，评估栈大小时必须把这些算进去。

6. 串口不定长帧的 DMA 加空闲中断。推荐组合是 DMA 循环模式填环形缓冲 + 空闲中断（HAL 封装为 HAL_UARTEx_ReceiveToIdle_DMA，手写则开 USART_IT_IDLE）。空闲中断在「一个字节时间内没有新数据」时触发，表示一帧结束；此时读 __HAL_DMA_GET_COUNTER() 得到 DMA 的剩余计数，与上次记录的读指针做差（回绕时取模）就是本帧长度——这一步是「减少 CPU 搬运」的关键，全程只有中断里的一次减法。工程要点：①空闲中断只能按总线静默切帧，如果协议帧内也可能出现长间隔，必须叠加协议自身的边界规则，比如 Modbus RTU 的 3.5 字符时间、或帧头的长度字段加 CRC 校验；②环形缓冲至少要能装下一帧，处理慢于接收时要么整帧丢弃并计数，要么把数据搬到二级缓冲，绝不能在中断里做耗时解析；③必须开并处理 ORE/FE/NE 错误中断，在里面清标志、复位 DMA，否则一次溢出会让接收永久停摆；④帧长可预期时用「定长 DMA 收帧头 → 解析长度 → 再切 DMA 收帧体 → 单独收 CRC」更省 CPU；⑤读写指针要用 volatile 并且配内存屏障（M7 带 D-Cache 时还要做 cache invalidate），只靠 volatile 并不能保证 DMA 写入对 CPU 可见。