29、量产经验与案例：常见问题（闪屏、丢帧、花屏）、调试故事、最佳实践
做车载Camera系统，最怕什么？
不是方案选型难，也不是性能调优慢。最怕的是——量产之后，客户那边反馈说「屏幕闪了一下」、「画面卡住了」、「图像花了」。这种问题，你在实验室里可能死活复现不出来，但车在路上跑，它就是会出现。
今天我就把这些年踩过的坑、填过的雷，好好跟你聊聊。全是真金白银换来的经验。
29.1 闪屏问题：根源与定位
闪屏，说白了就是画面出现短暂的黑屏、闪烁或亮度突变。我遇到过最夸张的一次，是客户在高速上开着开着，中控屏突然黑了一秒——你想想看，这要是导航关键时刻，多吓人。
29.1.1 闪屏的常见根因
- MIPI CSI 信号不稳定：线束过长、屏蔽不良、连接器松动，都会导致信号抖动。我在一个项目中，就因为摄像头线束从1米换到1.5米，闪屏率从0.1%飙升到3%。
- ISP 参数切换瞬间：比如从白天模式切到夜晚模式，曝光和增益突变，如果没做平滑过渡，画面就会「闪」一下。
- 帧同步丢失：多路摄像头共用同一个 CSI 接口时，如果同步信号没对齐，切换通道时就会闪。
- 电源纹波过大：摄像头模组的供电如果纹波超过50mV，CMOS 传感器就容易出现行闪烁。
29.1.2 调试方法
我个人习惯，遇到闪屏先做三件事：
- 抓 MIPI 眼图：用示波器看 CSI 数据线的眼图，如果眼图开口小于 0.3UI，基本可以断定是物理层问题。
- 打 log 看 ISP 参数：把曝光时间、增益、白平衡这些参数每秒打印一次，看切换瞬间有没有跳变。
- 做压力测试：连续跑 8 小时，记录每一次闪屏的时间戳，然后跟 log 对照。
29.2 丢帧问题：从表象到真相
丢帧，就是画面看起来「卡顿」或者「跳帧」。用户感知最明显的就是——倒车影像突然卡了一下，或者全景影像拼接时画面错位。
29.2.1 丢帧的典型场景
| 场景 | 根因 | 概率 |
|---|---|---|
| 多路同时启动 | ISP 带宽不足，DDR 带宽争抢 | 高 |
| 长时间运行后 | 内存泄漏，buffer 耗尽 | 中 |
| 高负载场景 | CPU/GPU 抢占，Camera HAL 线程被饿死 | 中 |
| 热插拔 | 驱动未处理好状态机，导致 pipeline 卡死 | 低 |
29.2.2 调试故事：一个让我熬夜三天的丢帧问题
有一次，客户反馈说「倒车影像偶尔卡顿，大概每 10 分钟出现一次」。我们在实验室怎么都复现不了。
后来我干脆把车开到户外，在太阳底下暴晒了一个小时。你猜怎么着？问题出现了！
一查 log，发现是温度升高后，DDR 的刷新率发生了变化，导致 Camera HAL 申请的 buffer 分配时间变长。说白了，就是热胀冷缩让内存时序变了。
解决方案也很简单：在 Camera HAL 的 buffer 申请逻辑里，加了一个「超时重试」机制。如果一次申请失败，就等 5ms 再试一次。从此再没出现过丢帧。
29.3 花屏问题：最让人头疼的「马赛克」
花屏，就是画面出现条纹、色块、马赛克。这问题比闪屏和丢帧更棘手，因为它往往意味着数据损坏。
29.3.1 花屏的三大类
- 行花屏：画面出现一条条横线或竖线。通常是 MIPI 数据线中的某一条 lane 出了问题。
- 块花屏：画面出现一块块的色块。一般是 ISP 处理时，某个模块的配置寄存器写错了。
- 全屏花屏：整个画面都是乱码。这通常是 buffer 被踩坏了，或者 DMA 传输地址错了。
29.3.2 我曾经踩过的一个坑
有一次，客户反馈说「启动后偶尔花屏，重启就好了」。我查了三天，最后发现是——Camera HAL 在初始化时，有一个寄存器写入的顺序不对。
具体来说，ISP 的「时钟使能」寄存器必须在「数据通路使能」之前写。但我们的代码里，这两个写反了。导致在某些时序下，ISP 内部状态机跑飞了。
修复方法就一行代码：调换两个寄存器写入的顺序。但找到这行代码，花了三天。
29.4 调试故事：一次「幽灵闪屏」的追凶之旅
这个故事我一直记忆犹新。
项目已经量产了，但某个批次的车辆，在特定路段（比如高架桥下）会出现闪屏。频率不高，大概 1% 的概率。
我们怀疑是 GPS 信号干扰，但屏蔽了 GPS 天线，问题依旧。
后来我带着示波器，坐在车里跑了整整两天。终于发现——每次闪屏发生时，CAN 总线上都有一个特定的报文在传输。
原来，那个报文是「车窗防夹功能」的指令。当车窗电机启动时，会产生一个瞬间的大电流，导致摄像头供电电压跌落了几十毫秒。
解决方案：在摄像头供电线上加了一个大电容，同时优化了电源管理芯片的响应速度。
这个故事告诉我们什么？车载系统是一个整体，Camera 的问题，可能根源在车窗、在空调、在雨刮器。你必须有系统思维。
29.5 最佳实践：量产级的 Camera 系统设计
说了这么多问题，最后给你一些我总结的最佳实践。照着做，能少踩 80% 的坑。
29.5.1 硬件层面
- 线束设计：MIPI 信号线必须用同轴电缆或屏蔽双绞线，长度不超过 2 米。如果超过，加 repeater。
- 电源设计：摄像头供电必须独立 LDO，不要跟其他负载共用。纹波控制在 30mV 以内。
- 连接器选型：用 FAKRA 或 HSD 连接器，保证接触可靠性。普通排针排母在车载振动环境下很容易出问题。
29.5.2 软件层面
- buffer 管理：使用 buffer pool 机制，避免频繁申请释放。每个 buffer 加上 magic number，用于检测踩内存。
- 超时保护：所有 Camera 相关的操作（open、stream on、capture）都要加超时。超时后自动复位 pipeline。
- 状态机设计：Camera HAL 的状态机必须完整覆盖所有异常路径。比如「stream off 失败后，怎么恢复到 idle 状态」。
- log 分级：量产版本只保留 error 和 warning 级别的 log。但 debug 版本要能动态开启所有 log，方便现场排查。
29.5.3 测试层面
- 压力测试：连续运行 72 小时，记录丢帧率、闪屏次数、花屏次数。
- 环境测试：高低温箱测试（-40°C 到 85°C），湿度测试，振动测试。
- 场景测试：模拟各种驾驶场景（颠簸路、隧道、强光、弱光）。
29.6 知识体系：量产问题排查流程
下面这张图，是我自己总结的「量产 Camera 问题排查流程」。每次遇到问题，我就按这个流程走一遍，基本不会漏掉关键环节。
这张图的核心逻辑就是：先定性（闪屏/丢帧/花屏），再定向（信号/电源/配置/内存/干扰），最后定方案。每一步都要有数据支撑，不要靠猜。