南芯嵌入式二面：电源状态机、I2C 配置可靠性与 HardFault 定位

《面试题目》

1. 介绍一个你最有代表性的嵌入式项目，你负责哪一块、难点是什么？
2. 如果项目里要做一个充电/电源管理状态机，你会怎么设计？
3. I2C 读写 PMIC/充电芯片寄存器时，如何保证配置可靠？
4. ADC 采样不准时，你从哪几层排查？
5. 中断里能做什么、不能做什么？你怎么划分 ISR 和任务？
6. FreeRTOS 出现栈溢出或 HardFault，你怎么定位？
7. 讲一下任务通知、队列、互斥量的选用和坑。

《参考解析》

1. 项目介绍：二面要的是「边界 + 难点 + 证据」。 先说清背景：芯片平台/主频、有没有 RTOS、用了哪些外设、业务目标（采集、通信还是控制）。然后划个人边界——驱动、协议、业务状态机，还是系统联调与量产支持，别把团队成果说成自己的。难点挑一个真实的技术矛盾，比如「充电电流采样在 PWM 开关瞬间被干扰，导致恒流段抖动」；定位手段要具体（分级日志、逻辑分析仪抓 I2C 时序、示波器看采样点、断言、栈水位）；收尾给可验证的结果（误码率、响应时间、功耗、连续跑测时长）。二面的追问会顺着「你怎么知道是这个原因」往下钻，所以每个结论最好都对应一次实验。

2. 电源管理状态机怎么设计。 先把状态列全：空闲/待机、插入检测、预充（涓流）、恒流（CC）、恒压（CV）、满充/浮充、故障、恢复。每个状态写四件事：进入条件、退出条件、超时保护、失败动作——比如预充阶段电压 30 分钟没到阈值就判电池异常，进故障态并锁存。然后做分层：采样（ADC/电量计）在周期任务里做，决策放在状态机里，执行（写寄存器、开关 MOS）放在驱动层，状态机不直接碰硬件。故障要能打断一切正常流程（过压、过流、过温、通信丢失、看门狗），并且故障优先于流程。再补两条工程细节：状态切换打点记录（带上时间戳和关键电压电流），方便复现现场；状态机用表驱动而不是一长串 if-else，便于评审和加状态。通信/插拔事件用队列送进状态机，避免在中断里做决策。

3. I2C 配置寄存器的可靠性。 五个手段，答全就够深：① 按手册时序来——上电稳定时间、写后等待、某些芯片要解锁或按页切换，别把「写完立刻读」当成理所当然；② 写后读回比对，不一致就重试并上报错误码，关键配置（电压/电流门限、保护位）必须校验；③ 总线级超时与恢复——从机无应答、忙等超时后做总线恢复（9 个时钟脉冲 + 停止位），不能让一次卡死拖住整个任务；④ 并发保护——多任务访问同一总线要加互斥量，一次事务（起始→地址→寄存器→数据→停止）不能被别的任务插进来；⑤ 寄存器表结构化——把地址、位域、默认值、可写属性做成表，减少魔法数，初始化和校验共用一份定义。追问常到「重试几次、失败怎么办」：给有限次数（如 3 次）、失败置错误标志并让状态机进安全态，不要无限重试。

4. ADC 采样不准，按四层排查。 硬件层：参考电压是否准和稳、地回路与采样点是否共地、输入阻抗与采样保持时间是否匹配、滤波电容、通道间串扰、走线是否被开关节点干扰。配置层：采样时间够不够（源阻抗大就要加长）、分辨率与对齐方式、触发源（软件/定时器/外部）、是否开了 DMA、ADC 时钟是否超规格。软件层：是否在电压尚未稳定时采样（比如刚切完档）、滤波是否过度导致滞后（平均值窗口太长会掩盖真实跳变）、是否取到了上一次的残留值。校准层：偏移与增益校准、温度漂移补偿。最后一定要给「怎么证明」：用基准源或高精度万用表对照、示波器同时看采样点与输入波形，从而区分是「芯片/前端不准」还是「时序/算法问题」。电流采样还要提一句开尔文接法与差分走线。

5. ISR 与任务的划分。 ISR 里只做确定的、短的事：清中断标志、读关键寄存器/取走数据、给队列或信号量、记录时间戳。不做长循环、printf、malloc、复杂协议解析、阻塞等待（中断没有任务上下文，阻塞的语义根本不成立）。数据用环形缓冲或队列交给任务处理，任务里做业务、日志、上报。共享变量要 volatile 加临界区保护，注意「读—改—写」不是原子操作。划分原则是按最坏响应时间倒推：中断服务时间要远小于最紧的截止时间，否则就把后半段挪进任务并降低优先级。还要注意中断嵌套和关中断时长——长时间的临界区会把所有中断延迟一起拉长。

6. 栈溢出与 HardFault 的定位。 栈溢出先看高水位：FreeRTOS 每个任务有 uxTaskGetStackHighWaterMark，跑完典型场景后看剩余最小值，留 30% 以上余量；打开 configCHECK_FOR_STACK_OVERFLOW（方法 2 会在栈尾填魔数并在切换时检查），配合溢出钩子记录是哪个任务。常见原因是栈上的大数组/大结构体、递归、printf 系列（格式化缓冲很吃栈）、以及深层调用链。想更早发现可以给每个任务栈加 canary，或用 MPU 把栈尾设成不可访问区，越界立刻 fault 而不是静默踩坏别人。

HardFault 的读法：先从异常帧取 PC（Cortex-M 硬件压栈 R0–R3、R12、LR、PC、xPSR，用 EXC_RETURN 的 bit2 判断当时是 MSP 还是 PSP），配合 map 文件/反汇编定位到函数；再看 CFSR（MMFSR 访存违例、BFSR 总线错误、UFSR 用法错误如未对齐/除零/跳到非 Thumb 地址）、HFSR 的 FORCED 位（说明是被升级上来的）、以及 BFAR/MMFAR（先确认 VALID 位）。典型根因清单：空/野指针、返回到非法地址、栈溢出踩坏返回地址、中断里调用阻塞 API、Flash 被擦除区执行、以及优化等级变化暴露出的未定义行为。

7. 任务通知 / 队列 / 互斥量的选用和坑。 任务通知（task notification）最快、最省内存（每个任务内建一个 32 位通知值和状态），适合一对一的事件通知或轻量计数，坑是只能一对一（多个等待者只有一个能收到）、不能广播、语义比队列弱，所以不能拿它替代「多生产者多消费者」的数据传递。队列按值拷贝、支持多对多、自带阻塞与超时，是传数据的主力；坑是拷贝开销（大结构体要传指针并约定所有权）、队列深度与元素大小要算内存、FromISR 版本不能阻塞且要处理 pxHigherPriorityTaskWoken。互斥量用于保护共享资源，带优先级继承；坑是不能在中断里用、持有时间要短、别在持锁时做可能阻塞的操作（典型死锁来源：持锁再去等另一个队列），递归锁只解决同任务重入、不解决设计问题。选型口诀：传数据用队列，一对一通知用任务通知，保护资源用互斥量，多条件等待用事件组。

整体印象：这场二面几乎没有八股，全部是「你做过什么、怎么判断、怎么验证」。 准备时把每个项目整理成「背景—边界—难点—定位—结果—复盘」六段，把每个技术选择都配一句「为什么不用另一种」，是最有效的准备方式。