新凯来 嵌入式软件开发 一面面经（20 题）

《面试题目》

1. 简单做个自我介绍，并说明你和嵌入式软件最相关的一段经历。
2. 你简历里最核心的一个项目，你负责哪一块？用时序把关键链路讲清楚。
3. volatile 在嵌入式里什么场景必须用？不用会发生什么？
4. const 修饰指针和修饰数据，在 MCU 开发里分别常见于哪些用法？
5. 中断里能不能做耗时操作？如果必须通知任务层，一般怎么做更稳妥？
6. 关中断保护临界区和用互斥锁，分别适合什么场景？有什么风险？
7. UART 通信出现偶发丢字节或错帧，你一般按什么顺序排查？
8. SPI 全双工传输时，时钟极性/相位配错，现象通常是什么？怎么快速定位？
9. I2C 出现 ACK 失败或总线挂死，常见原因有哪些？如何恢复？
10. 请对比轮询、中断、DMA 三种收数方式，各自适合什么场景？
11. DMA 传输完成后数据偶发错乱，你会检查哪些配置和缓存一致性问题？
12. 裸机项目里如何做软件定时器和超时重传？要注意哪些并发问题？
13. 如果用过 RTOS：任务优先级怎么定？出现优先级反转你怎么处理？
14. 二值信号量和互斥锁有什么区别？什么时候绝对不该混用？
15. Flash 在线升级时，为什么要做镜像完整性校验？常用哪些校验方式，失败怎么处理？
16. 双分区升级失败后如何保证设备还能起来？回滚触发条件一般怎么设计？
17. Bootloader 跳转 App 前通常要做哪些准备？向量表和中断为什么容易踩坑？
18. 驱动层、协议层、应用层你怎么分层？层与层之间通过什么接口解耦？
19. 讲一次你印象最深的线上/联调问题：现象、定位手段、根因和最终改法。
20. 反问环节你想了解新凯来嵌入式岗位的哪些信息？

《参考解析》

volatile 与 const 是这类岗位的开场必考。volatile 必须用的三类场景：硬件寄存器（轮询状态位，不加会被优化成死循环或只读一次）、中断与主循环共享的变量（ISR 里置标志、主循环里检查）、以及多任务共享的简单标志。要主动说清它的边界：不保证原子性、不提供内存屏障和同步语义，i++ 在并发下仍会丢更新，真正的保护要靠关中断或原子操作。const 修饰指针的四种组合要能默写出来：const char *p（指向的内容不可改）、char * const p（指针本身不可改）、const char * const p（都不可改）、以及 char const *p 与前两种的等价写法。MCU 开发里的常见用法是把只读的查表和常量字符串放 const（让编译器放进 Flash，省 RAM），把外设寄存器指针声明成 volatile，两者叠加就是「只读状态寄存器」的 const volatile。

中断的约束与临界区选择：中断服务程序要尽量短，因为中断期间同级中断被屏蔽，长时间占用会丢中断、破坏实时性；耗时逻辑要「上半部做标记、下半部交任务」。必须通知任务层时，用 RTOS 队列/信号量的 FromISR 版本（不阻塞、退出时按需触发一次上下文切换），裸机则用 volatile 标志位或环形缓冲区加「关中断入队」。关中断 vs 互斥锁的取舍是这题的考点：关中断适合保护极短的临界区（几条指令）、实时性要求高的场景，风险是关太久会丢中断、影响系统响应，且只在单核上是真正的互斥（多核需要自旋锁）；互斥锁适合临界区较长、可能涉及内存分配或函数调用、以及需要阻塞等待的场景，风险是可能引发优先级反转、不能在中断里使用、以及持锁期间做耗时操作会放大竞争。工程上的常见约定是「关中断只包住最短的读改写，任何带循环或函数调用的保护都用锁，并且持锁时间越短越好」。

UART 偶发丢字节或错帧的排查顺序建议按信号层到协议层：① 先看物理层——查波特率是否匹配（包含时钟源误差累计，用示波器量实际位宽而不是只看配置）、电平是否正常（TTL/RS232 混接、地线是否共地、线长与干扰）、上下拉与驱动能力；② 看收发时序——是否有溢出（ORE）、帧错误（FE）、噪声（NE）标志，读一下状态寄存器就知道；③ 看软件层——中断处理是否及时（高优先级任务长时间占用导致 FIFO 溢出）、环形缓冲区是否溢出、多任务访问共享缓冲是否加了保护、DMA 与 CPU 是否有竞争；④ 看协议层——帧头帧尾、长度字段与校验是否正确，是不是粘包/半包问题（用固定长度或字节填充的帧格式更稳）；⑤ 用日志统计错误类型分布（丢的是首字节还是随机位）来区分是硬件干扰还是软件时序问题。

SPI 极性相位配错的典型现象是数据整体移位、读到全 0 或全 F、或者第一个 bit 丢失——因为采样边沿与原设备不一致，采到的是相邻位的值或建立时间不足的抖动值。快速定位方法是先用示波器/逻辑分析仪看 SCLK 的空闲电平和数据在哪个边沿稳定，再对照从设备手册的 CPOL/CPHA 要求，同时检查片选（CS）的时序（是否在传输期间保持拉低）、时钟频率是否超过从设备上限、以及 MISO/MOSI 是否接反。全双工情况下还要注意「发送即接收」——读操作也要发 dummy 字节才能产生时钟。I2C 的 ACK 失败与总线挂死更常见：ACK 失败的原因有从设备地址写错（7 位/8 位混淆是经典坑）、上拉电阻缺失或阻值不合适、从设备没上电或未就绪、时钟频率超过从设备能力；总线挂死的经典场景是主机在从设备拉低 SDA 期间复位，导致 SDA 一直被从设备占住——恢复办法是主机发 9 个以上时钟脉冲让从设备释放总线，再发一个 STOP，或者用 GPIO 手动模拟时序解挂；更彻底的做法是加外部 I2C 复位芯片或总线隔离器。

轮询、中断、DMA 的对比要落到「CPU 占用与实时性」这一对矛盾上：轮询实现最简单、延迟可预期但浪费 CPU，适合极低频或对时间要求严格的短等待；中断由事件驱动、CPU 在无事时可做别的，适合中低频、需要及时响应的场景，但高频中断会把 CPU 吃满（每次进出中断都有开销）；DMA 让外设直接读写内存、几乎不占 CPU，适合高速大批量数据（SPI 高速采样、ADC 连续采集、UART 大数据量），代价是配置复杂、要处理缓存一致性和传输完成的同步。实际项目多是组合：DMA 搬运 + 传输完成中断通知任务。

DMA 数据偶发错乱要查三类问题：① 配置——源/目的地址是否正确且对齐、传输长度是否与实际一致、循环模式与单次模式的语义是否搞反、通道优先级是否与其它 DMA 冲突；② 缓存一致性（带 D-Cache 的 MCU 如 STM32H7 必考）——DMA 绕过 CPU 直接读写内存，CPU 侧可能读到 D-Cache 里的旧数据（应做 invalidate）或 DMA 读到尚未写回的脏数据（应做 clean），且要注意按 cache line 对齐做操作，否则会误伤相邻数据；③ 并发与生命周期——DMA 传输期间 CPU 是否改了同一块内存、缓冲是否被提前复用、是否有两个 DMA 通道写同一区域。工程实践是把 DMA 缓冲区放在非缓存区（MPU 配置）或明确执行 clean/invalidate，并用「双缓冲 + 完成回调」避免竞争。

Flash 在线升级的完整链路是这套题的重点。为什么要做完整性校验：Flash 写入可能因掉电、擦写干扰、传输错误导致镜像不完整或损坏，启动一个损坏的镜像轻则反复重启、重则变砖，所以写入后必须校验才能置「可启动」标志。常用方式是 CRC32（快、能查错但不能防伪造）、哈希（SHA-256，安全性更好）和数字签名（用私钥签、设备内置公钥验，能同时保证完整性与来源真实）。失败处理要先明确「失败在哪一步」：传输失败可重传、校验失败要作废该分区并保留旧分区、写 Flash 失败要重试或标记坏块。双分区升级保证还能起来的关键是「永远保留一份已知可用的镜像」：A/B 双分区轮流作为运行区和升级区，升级只写非运行分区；再加第三种「bootloader 自身不可升级或双备份」。回滚触发条件的设计是这题的高分点，常见组合是：新分区校验失败 → 直接回滚；新固件连续启动失败 N 次（用启动计数器，应用启动成功后主动清零）→ 回滚；看门狗复位来自新分区 → 回滚；以及显式超时（启动后 T 秒内没有「健康上报」）→ 回滚。要强调「回滚标志本身也要双副本 + 校验」，否则掉电正好发生在写标志时会两边都不确定。

Bootloader 跳转 App 前的准备有固定清单：关掉所有中断与外设（避免跳转后中断向量还指向 Bootloader 的旧地址）、把外设恢复到复位状态、设置主栈指针 MSP（从 App 的向量表第 0 项取）与复位向量（取第 1 项）、重定位向量表（SCB->VTOR = APP_BASE，这一步最容易漏）、清理并关闭 SysTick 与可能触发中断的定时器、必要时关闭 MPU/D-Cache 再重新配置、最后通过函数指针跳转。向量表和中断容易踩坑的原因是：Cortex-M 的中断向量表偏移由 VTOR 决定，如果 App 没有重定位 VTOR，中断发生时仍会跳到 Bootloader 的向量表，表现为「主循环能跑但一进中断就飞到错误地址/死机」；另一个坑是链接脚本的起始地址与向量表布局必须与 Bootloader 约定一致，否则跳转过去的栈指针和入口地址就是错的。

分层设计的答法要给出「层与层的接口是什么」而不是只报层次名：驱动层对外暴露「初始化 + 读 + 写 + 控制」这类与硬件无关的语义接口（例如 sensor_read(buf, len)），内部处理寄存器与总线细节；协议层负责帧的组包/解析、校验、重传和会话状态，对外暴露「发送一条消息」「订阅某类消息」的接口；应用层只做业务编排，不直接碰寄存器。解耦手段包括：用函数指针表/接口结构体做依赖倒置（上层的业务逻辑只依赖接口，具体驱动由装配阶段注入），用消息队列/事件回调把同步调用改成事件驱动，以及把硬件相关宏集中到 board.h 里。这一题的高分回答会提「可测试性」——分层之后驱动层可以在 PC 上用 mock 替换，协议层与业务逻辑可以脱离硬件跑单元测试。

最后两题（联调排查故事、反问）：故事题要挑一个有排查过程的而不是一个顺利实现的功能，按「现象 → 定位手段 → 根因 → 改法 → 怎么验证不会复发」五段讲，其中「定位手段」要具体（示波器看波形、加 GPIT 翻转测时序、二分注释代码、对比正常与异常的日志），因为这是嵌入式岗位最看重的能力。反问环节可以问：这个岗位主要做哪一层（驱动、协议还是应用）、产品从设计到量产的大致节奏、新人前三个月通常接手什么样的模块、团队怎么做代码评审和测试——问这些比问「加班多不多」更能体现你在认真考虑要不要来。