荣耀嵌入式软件开发一面面经：RTOS 调度、优先级反转与 DMA 缓存一致性

《面试题目》

1. 介绍你负责过的嵌入式项目里，任务划分、中断边界和数据流是怎么设计的？
2. 项目里遇到过一次偶发死机或数据错乱，你怎么定位到根因？
3. FreeRTOS 一次任务切换，从 SysTick/PendSV 到恢复现场，硬件上发生了什么？
4. 高优先级任务等互斥锁时被低优先级任务拖住，FreeRTOS 侧通常怎么处理？
5. 链接脚本里为什么要把 vector、code、rodata、data、bss 分开，启动时各做什么？
6. CPU 开了 D-Cache 后，DMA 收数偶发错位或旧数据，根因通常在哪？

《参考解析》

任务划分与中断边界的设计。这题的答案要能落到「为什么这么切」上。切分的依据是实时性：硬实时动作（采样、PWM、通信时序）放中断或最高优先级任务，业务逻辑放中优先级，日志、上报、UI 放低优先级，这样最坏响应时间才可控。中断服务程序只做最短路径——清标志、读硬件寄存器、投递队列或置事件，协议解析、动态内存分配、阻塞调用一律挪到任务里，因为中断上下文不能阻塞，也会拉长其他中断的延迟。跨任务数据用定长消息或环形缓冲，明确谁生产、谁消费、满了是丢新、丢旧还是反压，这个策略必须写进设计而不是运行时随机发生。共享资源按「谁持有多久」设计，临界区尽量短，能用队列解耦就不要用全局大锁。启动顺序也要固定：时钟与引脚 → 驱动 → 创建 OS 对象 → 拉起任务，避免未初始化就被中断访问。

偶发死机与数据错乱的定位方法论。这类问题不能靠猜，要靠把概率拉高和证据链。第一步是构造边界条件复现：特定负载、特定中断密度、特定温度或低压场景，把概率从万分之一提到百分之一，问题才有得查。第二步看复位原因与故障寄存器：HardFault、总线错误、看门狗复位、欠压复位要能区分硬件复位与软件故障，HardFault 还要读出栈帧里的 PC/LR 定位到出错指令，看是非法地址、非对齐访问还是除零。第三步对照现场上下文：任务栈水位（uxTaskGetStackHighWaterMark）、堆剩余、关键队列深度、最近一次中断与 DMA 完成时刻，判断是栈溢出、堆耗尽还是缓冲区被覆盖。第四步查竞态：中断与任务是否同时写同一缓冲、是否缺内存屏障、Cache 与 DMA 是否同步，共享变量有没有用 volatile 或原子操作。第五步用 GPIO 翻转或高精度时间戳卡时序，确认是优先级反转、栈溢出，还是 DMA 覆盖了尚未消费的数据。修复之后必须用压测和边界用例回归，确认故障窗口消失，而不是「暂时不出现」。

FreeRTOS 任务切换的硬件过程。一次切换的触发有两条路径：SysTick 滴答中断到期，或任务主动 yield。Cortex-M 上常见的做法是把实际切换挂到 PendSV——它优先级最低，可以推迟到所有其他异常处理完之后再执行，这样切换不会打断别的高优先级中断。真正保存现场时，Cortex-M 硬件会自动把 xPSR、PC、LR、R12、R0–R3 压入当前任务的栈（异常进入时的自动入栈），R4–R11 由内核按 AAPCS 约定手动保存到当前任务的 TCB 栈里，因为硬件只保证调用者保存寄存器。调度器随后选出最高优先级的就绪任务，切换 pxCurrentTCB，把新任务的栈顶写回 PSP。异常返回时硬件从新任务栈恢复寄存器并回到线程模式，PC 落到新任务的断点继续执行。答题时值得补两点：关中断或关调度（taskENTER_CRITICAL）的区间必须短，否则表现为周期任务抖动、中断延迟变大；如果开了 FPU，浮点寄存器是惰性入栈的，上下文切换和中断里使用浮点都要留意。

优先级反转与治理。现象是低优先级任务持有互斥锁，被中优先级任务抢占，导致高优先级任务拿不到锁只能空等——系统的实时性被一个不相关的中优先级任务破坏。FreeRTOS 侧的标准解法是用带优先级继承的互斥量（xSemaphoreCreateMutex），持锁任务在等待者优先级更高时被临时提升到该优先级，直到释放锁，从而缩短被抢占的窗口；注意普通二值信号量没有继承语义，别拿它当锁用。工程上更彻底的做法是减掉这把锁：临界区只保护共享结构，绝不在持锁期间做 Flash 擦写、长延时、阻塞 IO；能改成单写多读、消息传递或单生产者单消费者无锁环缓的，就不要用互斥锁把整条业务串行化。观测指标是最长持锁时间和高优先级任务的最坏响应时间，而不是「功能正确」。还要清楚继承的边界：它解决单把锁的优先级反转，解决不了多把锁形成的链式反转与死锁，固定加锁顺序、带超时获取、避免锁嵌套才是根治手段。

链接脚本分段与启动流程。分段的本质是区分「运行时要写」和「只要读」。向量表、代码、只读数据放只读区，上电即可取指执行，可以留在 Flash 里 XIP；.data 的初值存放在 Flash 镜像中，运行时必须拷到 RAM 才能读写；.bss 是未初始化的全局与静态变量，只需要运行时清零，不必占用镜像空间——这正是镜像能比 RAM 占用小得多的原因。启动流程在 Reset_Handler 里排得很固定：设置栈指针（有些芯片还要先初始化看门狗与时钟）→ 拷贝 .data → 清零 .bss → 系统与时钟初始化 → 进 main。用分散加载文件可以把不同段放到 ITCM/DTCM/SRAM/外部 SDRAM，取舍标准是速度与容量：紧循环放 TCM 提速，大缓冲放外部 RAM 省内部资源。常见的坑是栈、堆、DMA 缓冲放到了错误属性或错误总线上，表现为 HardFault 或 DMA 搬数异常；收尾要核对 map 文件里的入口地址、各段范围、栈顶和保留区，避免出现「编译能过但一跑就飞」的镜像。

D-Cache 与 DMA 的一致性。根因是两条访问路径看到的内存视图不同：CPU 读写经过 D-Cache，DMA 直接访问物理内存。两类典型故障由此而来——发送方向，CPU 写了缓冲区但数据还在 Cache 里是脏行，DMA 从内存读走的是旧数据；接收方向，DMA 把新数据写进内存，但 CPU 读到的仍是 Cache 里缓存下来的旧行，或者投递完成后 Cache 的脏行回写把 DMA 刚写的数据覆盖掉。解法按优先级排：最省心的是把 DMA 缓冲区放到非缓存区，或用 MPU 把该区域配置为 non-cacheable / device 属性，从根上不产生不一致；必须使用 Cache 时，发送前对缓冲区做 clean（写回），接收后做 invalidate（失效），顺序不能反。这里有两个高频坑：一是缓冲区要按 cache line 对齐，invalidate 是按整行操作的，若同一行里有其他被 CPU 修改过的数据，一次 invalidate 会把这些改动丢掉（伪共享）；二是长传输要配合 ping-pong 双缓冲，在每个缓冲区的切换点做 Cache 维护，而不是等整包收完。另外要清醒：volatile 只约束编译器不做优化，不产生 Cache 维护动作，用它「解决」DMA 数据错位是典型的误用。