📺 B站 嵌入式孙老师：博主个人介绍
📘 博主书籍-京东购买链接*：Yocto项目实战教程
📘 加博主微信，进技术交流群： jerrydev
从 MIPI ERR1/ERR2 到视频处理高手：Camera 调试必须掌握的底层排障方法
开篇：先带着几个问题看这篇文章
在调试 RK3576、RK3588、RV1126、RK356x 等平台的 Camera 时，我们经常会遇到类似这样的日志：
mipi0-csi2-hw ERR2:0xf0000
MIPI error: packet: 0x...
ERR1: crc errors
ERR2: header error detected and corrected
CIF_ISP_PIC_SIZE_ERROR
CIF_ISP_DATA_LOSS
很多初学者看到这些日志，第一反应是：是不是驱动写错了？是不是 IQ 文件不对？是不是 sensor 没初始化成功？
但真正有经验的 Camera 工程师，会先问下面几个问题：
- 这个错误属于 D-PHY 层、CSI-2 Packet 层、CSI-2 Protocol 层，还是 ISP/VICAP 接收层？
- TX 端 sensor 实际输出的 MIPI 速率，和 RX 端驱动里配置的
link_freq是否匹配？ - Sensor 实际输出几条 lane？DTS 和驱动配置的 lane 数是否一致？
- P/N 有没有接反？lane 顺序有没有错？
- LP11、LP01、LP00、HS 这些状态是否符合 MIPI D-PHY 时序？
- CRC、ECC 报错到底是数据 payload 错，还是 packet header 错？
HS-prepare / HS-zero / HS-trail / THS-settle这些参数到底影响什么？- 图像能正常出，但是启动时报一次 ERR2，这算不算严重问题？
- 怎么从“会改 DTS”进阶到“能系统定位视频链路问题”？
这篇文章的核心答案是：
想成为视频处理高手，不是先学滤镜、编码、算法，而是先把 Camera 输入链路吃透。MIPI 错误不是单点问题，它是 sensor 寄存器、MIPI 时序、PCB 走线、DTS 配置、驱动 link_freq、CSI2 控制器、VICAP/ISP 吞吐能力共同作用后的结果。会看 ERR1/ERR2，只是入门；能根据错误层级建立排查路径，才是真正的视频调试能力。
Rockchip 的 Camera FAQ 也明确把 MIPI 错误按链路分层：数据路径大致是 MIPI DPHY → MIPI CSI Controller → VICAP/ISP Controller，错误也应该按这个链路分层定位，而不是看到报错就盲目改参数。
一、先建立视频输入链路的全局图
做 Camera 调试，第一件事不是看代码，而是画链路。
一个典型 MIPI Camera 输入链路如下：
Sensor / HDMI-RX / SerDes
|
| MIPI CSI-2 TX
v
MIPI D-PHY RX
|
v
CSI-2 Controller
|
v
VICAP / CIF
|
v
ISP
|
v
RGA / VENC / Display / AI
对应到问题层级：
| 层级 | 主要模块 | 常见错误 | 重点排查 |
|---|---|---|---|
| 物理层 | MIPI D-PHY | SOT、SOT Sync、False Control、EOT Sync | P/N、lane、LP/HS 时序、信号质量 |
| 包层 | CSI-2 Packet | CRC、ECC1、ECC2、ErrID | link freq、lane、信号完整性、数据格式 |
| 协议层 | CSI-2 Protocol | FrameSync、FrameData | FS/FE、虚拟通道、曝光/VTS/时序 |
| 接收层 | VICAP/ISP | PIC_SIZE_ERROR、DATA_LOSS、FIFO Overflow | 分辨率、吞吐、DDR、AXI、ISP clock |
这就是高手和新手的区别。
新手看到 ERR2，只会问“怎么改”。
高手会先问：ERR2 里的哪几个 bit 置位？它属于哪一层？这层前面还有没有更底层错误？
Rockchip FAQ 里也建议 MIPI 问题按优先级处理：先看 D-PHY Level Error，再看 CSI-2 Controller Error，再看 CSI-2 Packet Level Error，然后才是 CSI-2 Protocol Level Error 和 VICAP/ISP 接收错误。
二、ERR1/ERR2 到底是什么？
不同平台打印方式不同，但大方向一致：ERR1/ERR2 是 CSI/MIPI 控制器把硬件错误寄存器打印出来。
比如你之前遇到的：
mipi0-csi2-hw ERR2:0xf0000
这类值不能只看十六进制，要拆 bit。
在 FAQ 的寄存器表中，ERR2 bit[19:16] 对应 Control Error，也就是 D-PHY Level Error: False Control Error。如果是 0xf0000，说明 bit19~bit16 全置位，往往表示多个 lane 都检测到了控制序列异常。
False Control Error 的本质是：RX 端看到的 LP 控制状态序列不合法。
正常进入高速传输前，应该类似：
LP11 -> LP01 -> LP00 -> HS
其中：
| 状态 | 简单理解 |
|---|---|
| LP11 | 空闲状态 |
| LP01 | 请求进入 HS 高速传输 |
| LP00 | 准备切换 |
| HS | 真正高速传图像数据 |
如果 P/N 接反，RX 端本来应该看到 LP01，结果会看成 LP10。这样本来合法的 HS request，就会被误判成非法控制序列，触发 False Control Error。FAQ 对 False Control Error 的处理建议中，也明确把 Data lane 的 Dn/Dp 是否接反 放在第一位检查。
所以，ERR2:0xf0000 的正确思路不是先改 IQ，也不是先改分辨率，而是优先确认：
1. Data lane P/N 是否接反
2. Clock lane P/N 是否接反
3. lane 顺序是否正确
4. DTS data-lanes 是否和硬件一致
5. sensor 初始化时是否已经切到 MIPI 模式
6. 上电阶段是否有异常 LP 波形
三、CRC/ECC 报错：它不是玄学，是数据校验失败
很多人看到 CRC、ECC 会觉得抽象。其实很简单：
MIPI CSI-2 传输时，数据不是随便一串 bit 流，而是一个个 packet。每个 packet 有 header，也有 payload。
大致可以理解为：
Packet Header + Payload Data + Checksum
其中：
| 错误 | 位置 | 含义 |
|---|---|---|
| ECC1 / ECC Corrected | Packet Header | Header 有小错误，但可纠正 |
| ECC2 / ECC Double | Packet Header | Header 错误严重，不可靠 |
| CRC / Checksum | Payload Data | 图像数据内容校验失败 |
| ErrID | Packet Header | Data Type 或 ID 不认识 |
FAQ 里提到，Checksum 主要针对 package data，ECC1/ECC2 主要针对 packet header。ECC1 是可纠正错误，payload 可能仍然有问题；ECC2 则说明 header 已经不可靠，后续就可能引发 PIC_SIZE_ERROR、DATA_LOSS 等更严重问题。
所以 CRC/ECC 报错时，优先排查这些：
| 排查项 | 为什么 |
|---|---|
| TX 实际 MIPI 速率 vs RX link_freq | 速率不匹配会导致采样窗口不对 |
| lane 数是否一致 | 4lane/2lane 配错会导致包重组失败 |
| lane 顺序是否正确 | 多 lane 数据合并时顺序错会破坏 packet |
| P/N 是否正确 | 极性错会导致 LP/HS 识别异常 |
| 高速信号质量 | 抖动、反射、串扰都会造成 bit error |
| HS-prepare/HS-zero/HS-trail | D-PHY 时序不满足会导致 SOT 或采样失败 |
| HTS/H-blanking | 行间隔太紧可能造成接收端吞吐压力 |
| 周围高频干扰 | MIPI 是高速差分，附近干扰会直接影响误码率 |
四、link_freq：驱动里的一个数，背后是整条链路的时钟契约
很多人 DTS 写通了，sensor 能 probe，就以为 MIPI 也没问题。其实真正决定 MIPI RX 怎么配置采样参数的，是 sensor driver 里的 mode 信息，尤其是：
.link_freq
.pixel_rate
.hts_def
.vts_def
.width
.height
.bus_fmt
其中 link_freq 非常关键。
它告诉接收端：我这个 sensor 当前模式下，每条 MIPI lane 的高速传输频率是多少。
如果 TX 端实际输出 1782Mbps/lane，但 RX 端按照 1500Mbps 或 2000Mbps 去配置 settle、采样窗口，就可能出现：
SOT error
SOT sync error
CRC error
ECC error
偶发花屏
启动报错但能出图
高温或长线下异常加重
你图片里提到 HDMI-IN 的计算公式：
1080P60: 2200 x 1125 x 16 x 60 / 4 / 2
这个公式的含义是估算每条 MIPI lane 的速率。
解释一下：
| 参数 | 含义 |
|---|---|
| 2200 | 一行总像素，包含 blanking |
| 1125 | 一帧总行数，包含 blanking |
| 16 | 每像素 bit 数，比如 YUV422 16bit |
| 60 | 帧率 |
| 4 | 4 条 lane 分摊 |
| 2 | DDR 双沿传输或频率换算相关 |
对 sensor 来说也类似，不能只看有效分辨率，例如 1920x1080，而要看：
总像素 = HTS x VTS
总 bit = HTS x VTS x bpp x fps
lane rate = 总 bit / lane 数
一个视频高手必须记住：MIPI 速率不是由 width x height 单独决定，而是由 HTS、VTS、bit depth、fps、lane 数共同决定。
五、HTS / VTS / H-blanking：为什么有时增加 HTS 能改善？
HTS 可以理解为一行的总长度，不只是有效图像宽度，还包含水平 blanking。
一行总时间 = active pixel 时间 + horizontal blanking 时间
如果 HTS 太小，意味着行与行之间间隔很短，sensor 发数据很紧，接收端、CSI FIFO、ISP 后级压力都会变大。
FAQ 在处理 Data loss 时提到，可以尝试增加 Sensor H-blanking 时间；在 CsiFifoOverflow 中也提到，本质是 ISP 吞吐率和 MIPI 速率不匹配，导致 CSI data lane 输入缓冲 FIFO 溢出。
所以当你遇到：
CRC/ECC 偶发
CsiFifoOverflow
Data loss
高分辨率高帧率异常
低分辨率正常
可以尝试：
1. 降低 fps
2. 增加 HTS
3. 增加 H-blanking
4. 降低 MIPI lane rate
5. 增加 lane 数
6. 提高 ISP/DDR/AXI 吞吐能力
但要注意：增加 HTS 会影响帧率或曝光上限。它不是万能药，而是用时间换稳定性。
六、LP 驱动强度、摆幅、HS 时序：示波器不是可选项，是高手必备工具
很多 MIPI 问题靠 log 只能定位方向，不能定性。真正要确认，必须上示波器。
尤其是下面这些问题：
LP11 是否稳定？
LP01 有没有变成 LP10？
LP00 持续时间是否异常？
HS prepare 是否太短？
HS zero 是否太长或太短？
HS trail 是否不足？
高速差分眼图是否足够？
FAQ 在讲 “MIPI 采集不到数据且未提示出错” 时，也建议读取 DPHY status，并结合示波器确认 Clk lane 是否有高速时钟，确认 clock lane 是 continuous 还是 non-continuous，确认 StopstateClk、StopstateData、RxClkActiveHS 等状态。
你要建立这样的判断：
| 看到的现象 | 可能原因 |
|---|---|
| RxClkActiveHS = 0 | clock lane 没有进入 HS |
| StopstateData 固定不变 | data lane 没有正常切换 |
| StopstateData 0/1 变化 | data lane 在 LP/HS 间切换 |
| continuous clock 下 StopstateClk 固定 0 | 正常 |
| non-continuous clock 下 StopstateClk 0/1 变化 | 正常 |
| 启动瞬间 False Control | 上电 LP 序列异常、P/N、初始化顺序 |
| 运行中持续 CRC/ECC | 高速信号质量、速率、lane、时序问题 |
这里要特别强调：
LP 和 HS 是两个世界。
LP 是低速大摆幅，主要用于状态切换和控制握手。
HS 是高速小摆幅，真正传输图像数据。
所以你不能只测 HS，也不能只测 LP。很多 ERR2、False Control 是 LP 阶段出问题；很多 CRC/ECC 是 HS 阶段出问题。
七、启动时报错但能正常出图，要不要管？
这是实际项目中最常见的问题。
比如你遇到过：
stream ON
dphy0, data_rate_mbps 1782
mipi0-csi2-hw ERR2:0xf0000
但后面能正常预览、正常录像。
这种情况怎么判断？
我的经验是分级处理：
| 情况 | 处理策略 |
|---|---|
| 只在 stream on 后报一次，图像/录像正常 | 低优先级，记录问题，后续优化 |
| 每次启动都报，但不影响数据 | 查上电/复位/LP 初始状态 |
| 运行中持续报 CRC/ECC | 必须处理 |
| 伴随花屏、丢帧、Data loss | 必须处理 |
| 高温、长线、震动后加重 | 必须处理 |
| 量产项目启动报错 | 建议根因闭环，避免边界风险 |
为什么启动报错但能出图？
可能是 sensor 在上电或 stream on 初期输出了异常 LP 状态，CSI 检测到一次 False Control，但后续真正进入 HS 后数据正常。FAQ 中 SC2310 的案例就提到，上电阶段 MIPI/DVP 管脚复用导致波形不可控，解决方式是先配置 sensor 管脚切到 MIPI 状态，再初始化 DPHY RX，用来规避上电阶段异常波形。
所以启动一次性 ERR 不一定致命，但它告诉你：
链路在边界时序上还不干净。
八、从普通调试到视频处理高手：要建立一套排查流程
下面这张流程图，可以作为你以后分析 MIPI 问题的固定模板。
真正的视频处理高手，不是记住某一个寄存器，而是有流程：
先分层
再定位
再验证
再压力测试
最后闭环
九、核心参数速查表
| 参数 | 所在位置 | 影响 | 出错表现 |
|---|---|---|---|
| data-lanes | DTS endpoint | RX 使用几条 lane | 无图、CRC/ECC、lane 错 |
| link_freq | sensor driver | MIPI 速率配置 | SOT、CRC、ECC |
| pixel_rate | sensor driver | V4L2 时序计算 | 帧率、曝光、ISP 配置异常 |
| HTS | sensor reg/driver | 行总长度 | 吞吐压力、Data loss |
| VTS | sensor reg/driver | 帧总行数 | fps、曝光范围、FrameSync |
| bpp | sensor mode | 每像素 bit 数 | MIPI 速率计算错误 |
| bus_fmt | sensor driver | RAW/YUV 格式 | 颜色异常、解析错误 |
| reset/pwdn | DTS + 硬件 | 上电时序 | I2C 不通、启动异常 |
| xvclk/mclk | DTS + CRU | sensor 输入时钟 | I2C 正常但无图、时序异常 |
| HS-prepare | sensor/D-PHY | HS 前准备时间 | SOT 错 |
| HS-zero | sensor/D-PHY | HS 起始保持 | SOT/SOTSync |
| HS-trail | sensor/D-PHY | HS 结束保持 | EOT/CRC |
| LP drive | sensor reg | LP 电平质量 | False Control |
| DPHY status | SoC reg | 当前 LP/HS 状态 | 判断是否进入高速 |
十、实战检查清单
以后你遇到 MIPI 错误，可以按下面顺序来：
1. 先确认链路是否跑通
dmesg | grep -iE "mipi|csi|dphy|ERR"
media-ctl -p
v4l2-ctl --list-devices
确认：
sensor 是否 probe
dphy 是否 matches sensor
csi2 是否 stream ON
data_rate_mbps 是否合理
是否能出图
2. 再确认 DTS
重点看：
data-lanes = <1 2 3 4>;
remote-endpoint = <...>;
clocks = <...>;
reset-gpios = <...>;
pwdn-gpios = <...>;
power-domains = <...>;
两端 endpoint 的 lane 数要一致。
3. 再确认 sensor driver
重点看：
link_freq_menu_items
pixel_rate
hts_def
vts_def
width
height
bus_fmt
mipi lane setting
尤其是驱动里的 link_freq 是否和 sensor 寄存器实际输出一致。
4. 再确认硬件
MIPI P/N
lane 顺序
阻抗
走线长度
连接器虚焊
排线接触
供电纹波
附近高速干扰源
你图片里提到的“排线是否松动、是否飞线、是否接触不良、附近是否有高频干扰”，这些都是非常实战的经验点。
5. 最后上示波器
重点测：
LP11
LP01
LP00
HS prepare
HS zero
HS trail
高速差分质量
clock lane continuous/non-continuous
结尾：视频处理高手的底层能力是什么？
很多人以为视频处理高手就是会 OpenCV、会编码、会调 ISP IQ。
这些当然重要，但在嵌入式 Camera 项目里，更底层的能力是：
看得懂 sensor datasheet
算得出 MIPI lane rate
配得对 DTS endpoint
读得懂 ERR1/ERR2
分得清 D-PHY/CSI/ISP 错误
会用示波器验证 LP/HS
知道什么时候改 HTS/VTS/link_freq
知道什么时候怀疑硬件，什么时候怀疑驱动
你现在遇到的 ERR2:0xf0000、CRC、ECC、link_freq、LP 驱动强度、HS 时序，其实都是视频输入链路的核心知识点。
把这些吃透之后，你就不只是“能让 Camera 出图”，而是能做到：
出问题能定位
偶发问题能复现
硬件软件能分界
参数修改有依据
量产风险能提前发现
这才是真正的视频处理高手。
扫一扫
335
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
