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 实际输出几条 laneDTS 和驱动配置的 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-PHYSOT、SOT Sync、False Control、EOT SyncP/N、lane、LP/HS 时序、信号质量包层CSI-2 PacketCRC、ECC1、ECC2、ErrIDlink freq、lane、信号完整性、数据格式协议层CSI-2 ProtocolFrameSync、FrameDataFS/FE、虚拟通道、曝光/VTS/时序接收层VICAP/ISPPIC_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>三、CRC/ECC 报错它不是玄学是数据校验失败很多人看到 CRC、ECC 会觉得抽象。其实很简单MIPI CSI-2 传输时数据不是随便一串 bit 流而是一个个 packet。每个 packet 有 header也有 payload。大致可以理解为Packet Header Payload Data Checksum其中错误位置含义ECC1 / ECC CorrectedPacket HeaderHeader 有小错误但可纠正ECC2 / ECC DoublePacket HeaderHeader 错误严重不可靠CRC / ChecksumPayload Data图像数据内容校验失败ErrIDPacket HeaderData Type 或 ID 不认识FAQ 里提到Checksum 主要针对 package dataECC1/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 数据合并时顺序错会破坏 packetP/N 是否正确极性错会导致 LP/HS 识别异常高速信号质量抖动、反射、串扰都会造成 bit errorHS-prepare/HS-zero/HS-trailD-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一行总像素包含 blanking1125一帧总行数包含 blanking16每像素 bit 数比如 YUV422 16bit60帧率44 条 lane 分摊2DDR 双沿传输或频率换算相关对 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 0clock lane 没有进入 HSStopstateData 固定不变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_mbps1782mipi0-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 问题的固定模板。不能出图能出图但报错只启动报一次运行中持续报D-PHY ErrorCRC/ECCFrameSyncFIFO/DataLoss出现 MIPI ERR1/ERR2 或图像异常能否正常出图?先查 I2C/电源/MCLK/reset/pwdn判断报错是否持续出现重点查 LP 初始状态/上电时序/False Control按错误层级定位错误类型P/N、lane、LP/HS、SOT、settle、示波器link_freq、lane数、信号质量、HS时序FS/FE、VC、曝光限制、VTSISP clock、DDR、AXI、HTS、吞吐修正硬件/DTS/驱动时序长时间录像/高低温/多次开关流验证真正的视频处理高手不是记住某一个寄存器而是有流程先分层 再定位 再验证 再压力测试 最后闭环九、核心参数速查表参数所在位置影响出错表现data-lanesDTS endpointRX 使用几条 lane无图、CRC/ECC、lane 错link_freqsensor driverMIPI 速率配置SOT、CRC、ECCpixel_ratesensor driverV4L2 时序计算帧率、曝光、ISP 配置异常HTSsensor reg/driver行总长度吞吐压力、Data lossVTSsensor reg/driver帧总行数fps、曝光范围、FrameSyncbppsensor mode每像素 bit 数MIPI 速率计算错误bus_fmtsensor driverRAW/YUV 格式颜色异常、解析错误reset/pwdnDTS 硬件上电时序I2C 不通、启动异常xvclk/mclkDTS CRUsensor 输入时钟I2C 正常但无图、时序异常HS-preparesensor/D-PHYHS 前准备时间SOT 错HS-zerosensor/D-PHYHS 起始保持SOT/SOTSyncHS-trailsensor/D-PHYHS 结束保持EOT/CRCLP drivesensor regLP 电平质量False ControlDPHY statusSoC reg当前 LP/HS 状态判断是否进入高速十、实战检查清单以后你遇到 MIPI 错误可以按下面顺序来1. 先确认链路是否跑通dmesg|grep-iEmipi|csi|dphy|ERRmedia-ctl-pv4l2-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 出图”而是能做到出问题能定位 偶发问题能复现 硬件软件能分界 参数修改有依据 量产风险能提前发现这才是真正的视频处理高手。
从 MIPI ERR1/ERR2 到视频处理高手：Camera 调试必须掌握的底层排障方法
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 实际输出几条 laneDTS 和驱动配置的 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-PHYSOT、SOT Sync、False Control、EOT SyncP/N、lane、LP/HS 时序、信号质量包层CSI-2 PacketCRC、ECC1、ECC2、ErrIDlink freq、lane、信号完整性、数据格式协议层CSI-2 ProtocolFrameSync、FrameDataFS/FE、虚拟通道、曝光/VTS/时序接收层VICAP/ISPPIC_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>三、CRC/ECC 报错它不是玄学是数据校验失败很多人看到 CRC、ECC 会觉得抽象。其实很简单MIPI CSI-2 传输时数据不是随便一串 bit 流而是一个个 packet。每个 packet 有 header也有 payload。大致可以理解为Packet Header Payload Data Checksum其中错误位置含义ECC1 / ECC CorrectedPacket HeaderHeader 有小错误但可纠正ECC2 / ECC DoublePacket HeaderHeader 错误严重不可靠CRC / ChecksumPayload Data图像数据内容校验失败ErrIDPacket HeaderData Type 或 ID 不认识FAQ 里提到Checksum 主要针对 package dataECC1/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 数据合并时顺序错会破坏 packetP/N 是否正确极性错会导致 LP/HS 识别异常高速信号质量抖动、反射、串扰都会造成 bit errorHS-prepare/HS-zero/HS-trailD-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一行总像素包含 blanking1125一帧总行数包含 blanking16每像素 bit 数比如 YUV422 16bit60帧率44 条 lane 分摊2DDR 双沿传输或频率换算相关对 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 0clock lane 没有进入 HSStopstateData 固定不变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_mbps1782mipi0-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 问题的固定模板。不能出图能出图但报错只启动报一次运行中持续报D-PHY ErrorCRC/ECCFrameSyncFIFO/DataLoss出现 MIPI ERR1/ERR2 或图像异常能否正常出图?先查 I2C/电源/MCLK/reset/pwdn判断报错是否持续出现重点查 LP 初始状态/上电时序/False Control按错误层级定位错误类型P/N、lane、LP/HS、SOT、settle、示波器link_freq、lane数、信号质量、HS时序FS/FE、VC、曝光限制、VTSISP clock、DDR、AXI、HTS、吞吐修正硬件/DTS/驱动时序长时间录像/高低温/多次开关流验证真正的视频处理高手不是记住某一个寄存器而是有流程先分层 再定位 再验证 再压力测试 最后闭环九、核心参数速查表参数所在位置影响出错表现data-lanesDTS endpointRX 使用几条 lane无图、CRC/ECC、lane 错link_freqsensor driverMIPI 速率配置SOT、CRC、ECCpixel_ratesensor driverV4L2 时序计算帧率、曝光、ISP 配置异常HTSsensor reg/driver行总长度吞吐压力、Data lossVTSsensor reg/driver帧总行数fps、曝光范围、FrameSyncbppsensor mode每像素 bit 数MIPI 速率计算错误bus_fmtsensor driverRAW/YUV 格式颜色异常、解析错误reset/pwdnDTS 硬件上电时序I2C 不通、启动异常xvclk/mclkDTS CRUsensor 输入时钟I2C 正常但无图、时序异常HS-preparesensor/D-PHYHS 前准备时间SOT 错HS-zerosensor/D-PHYHS 起始保持SOT/SOTSyncHS-trailsensor/D-PHYHS 结束保持EOT/CRCLP drivesensor regLP 电平质量False ControlDPHY statusSoC reg当前 LP/HS 状态判断是否进入高速十、实战检查清单以后你遇到 MIPI 错误可以按下面顺序来1. 先确认链路是否跑通dmesg|grep-iEmipi|csi|dphy|ERRmedia-ctl-pv4l2-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 出图”而是能做到出问题能定位 偶发问题能复现 硬件软件能分界 参数修改有依据 量产风险能提前发现这才是真正的视频处理高手。
