多彩编程 多彩编程MZPH · CODE BLOG
ARTICLE DETAIL

文章详情

深耕前端与后端开发技术的一线实战笔记与踩坑复盘。

海思Hi3519DV500接入OS04A10的sensor调试全记录

海思Hi3519DV500接入OS04A10的sensor调试全记录 这块板子到我手上时只知道一个任务Hi3519DV500接OS04A10把输入链路的图像跑出来。听起来不过是嵌入式视觉里最普通的sensor bring up但只有真做过的人才知道这活儿看着简单实际推进时每一步都可能把你卡到怀疑人生。I2C不通、MIPI配错、ISP和sensor能力集对不上、出图后满屏花条纹……我在这个项目里基本全踩了一遍。这篇就把整个调试过程掰开揉碎写出来包括硬件核对、I2C通联、MIPI配置、问题反推、图像质量验证的完整链路。如果你正在做海思平台的sensor接入或者准备把OS04A10这颗sensor用到自己的板子上这篇应该能帮你省下不少弯路。1. 点亮之前先花半天把三份文档对齐很多同学拿到板子的第一反应是烧固件、跑demo我一开始也这么干过结果回头发现最耗时间的不是代码而是前期该核对的东西没核对清楚。sensor调试这个事物理层的问题如果不提前堵住后面所有软件层的排查都会变成在错误的地基上盖楼。1.1 原理图、sensor手册、平台手册缺一不可拿到一块新打样的板子我会先找三样东西原理图、OS04A10的datasheet、Hi3519DV500对应的硬件手册。很多人觉得原理图是硬件工程师的事软件不用看这是个很大的误区。sensor能不能正常工作从管脚连接那一刻就已经决定了。对着原理图逐管脚核对重点看这几类信号MIPI差分对data lane和clock lane有没有接反有没有串电阻、串电容阻抗控制是否合规I2CSDA/SCL有没有接上拉电阻上拉电平是接到哪个电源域MCLK主时钟sensor的时钟输入引脚是否和平台MCLK输出相连中间有没有加缓冲器复位和掉电引脚XSHUTDOWN、PWDN这些控制脚有没有被正确连接是GPIO控制还是直接接固定电平电源AVDD、DOVDD、DVDD三路供电是否齐备是否经过滤波其中最容易出问题的是I2C上拉和电源时序。OV系sensor对上电时序有严格顺序要求一般是DVDD先上再AVDD最后DOVDD如果板子上用了多路电源芯片且没有做时序控制sensor可能偶尔能读、偶尔读不到这种幽灵故障最难排查。我在这个项目里就遇到过一次DOVDD比AVDD晚上了几十毫秒的情况现象是I2C设备扫描偶尔能扫到但初始化时读ID会偶发失败。1.2 先算一笔账MIPI速率和带宽OS04A10是一颗400万像素的sensor常见输出是2688x1520 30fpsRAW10格式。在配置MIPI参数之前我建议先手动算一遍带宽需求这个计算能帮你理解驱动里那个MIPI速率参数到底应该填多少。单帧数据量 2688 x 1520 x 10bit 约40.85Mbit30fps时有效数据率就是约1225Mbps。如果走2-lane MIPI每lane的有效数据率约612Mbps再算上MIPI协议包头、ECC、CRC、行消隐、帧消隐这些开销实际lane速率至少要留出1.2到1.5倍余量也就是800Mbps到900Mbps以上。如果走4-lane每lane有效数据率约306Mbps加上开销后400到500Mbps基本够用。这个参数决定了你在sensor初始化序列里配置的MIPI速率也决定了平台侧MIPI RX的接收能力是否匹配。Hi3519DV500的MIPI RX对lane速率有上限要求超过范围直接解不出数据配置过低又可能出现帧率不满、丢帧。我见过有人在2-lane配置下把lane速率填得很低结果只能跑到20fps还以为是sensor本身的问题。先把这笔账算清楚后面配参数就有依据了。2. I2C通联sensor活没活在这一步就定了硬件核对完上电后的第一件事永远是I2C通联。sensor驱动的所有后面动作——初始化、曝光设置、增益设置——全部建立在I2C能正常读写的基础上。这一步通了sensor就是活的不通后面什么都别谈。2.1 地址对不上一切白搭I2C通联的第一步不是读寄存器而是确认地址。OS04A10跟很多OV系sensor一样I2C地址可以通过芯片的地址选择引脚配置常见的默认7bit地址可能是0x208bit写地址0x40或者0x368bit地址风格具体以你手里的原理图和模组规格书为准。这里有个特别容易踩的坑平台代码里填的地址格式和I2C控制器要求的地址格式不一致。有的代码里用8bit地址右移一位变成7bit地址使用有的直接传8bit地址让控制器自己处理搞混了就出现明明地址没错但读出来全是0xFF的诡异情况。我在调试OS04A10时先用总线扫描工具把挂在I2C总线上的所有设备地址扫出来确认sensor的物理地址再和驱动的地址定义对齐这一步能省掉后面一大半的困惑。2.2 读不顺的时候按这个顺序排查I2C通联失败我一般按下面这个顺序排查这个顺序是从信号产生的先后链条推导出来的电压量AVDD、DOVDD、DVDD三路电压是否正常。DOVDD尤其关键它决定I2C接口的电平域如果DOVDD是1.8V但I2C上拉到3.3Vsensor端可能根本识别不了高电平时钟MCLK有没有起来频率是多少。OV系sensor如果MCLK没有正常供给很多寄存器都读不了复位XSHUTDOWN和PWDN的电平是否正确。有些模组要拉高才退出复位有些要拉低接反了sensor一直处于复位状态地址再次确认7bit/8bit地址的换算关系确认总线扫描到的地址和代码里填的地址一致上拉电阻SDA/SCL上必须要有上拉电阻阻值常见1.8V上拉用2.2k到4.7k没有上拉设备就不会ACK示波器抓波形把SDA/SCL波形抓出来看地址字节、ACK位、寄存器地址字节那段波形能直接告诉你问题出在哪一步这套顺序我基本是背下来的因为每一条都真实踩过。尤其是第2条MCLK没配好导致的I2C异常非常容易误判成sensor坏了或者地址错了。2.3 读ID但别只读IDI2C通联正常后第一步常规操作是读chip ID。OS04A10这类OV系sensor的chip ID寄存器通常在0x300A和0x300B附近高字节和低字节分别存放读出来的值和datasheet对照就能确认sensor型号和I2C链路确实稳定工作。但我个人建议不要只读ID就收工顺手再读几个关键寄存器做交叉验证比如软件复位状态寄存器、流控寄存器、曝光寄存器。好处是能确认sensor内部图像处理管线确实在工作而不只是数字接口活着。如果后续在调试曝光和增益时发现寄存器写不进去回过头来排查I2C稳定性那才是真的浪费时间。3. MIPI链路握手数据能不能进来就看这里I2C通了寄存器能读能写sensor也能正常stream on但图像就是出不来——这应该是整个调试过程中最让人抓狂的阶段。问题大概率出在MIPI链路配置上。MIPI不是简单的有信号就行它是一套包含物理层、协议层、数据格式的完整体系任何一层不对都收不到有效数据。3.1 四个参数必须一一对应MIPI链路上有四个关键参数必须保证sensor侧和平台侧完全一一对应任何一个不匹配都会导致收不到数据lane数sensor输出2-lane还是4-lane平台侧MIPI RX就要配置接收几路虚拟通道VC默认配置VC0。如果sensor初始化序列里把数据配置到了其它VC通道平台侧解包时也要对应修改数据类型DTRAW10、RAW12、YUV422等。sensor输出什么格式平台侧就要按什么格式解析时钟lane模式有些sensor支持Continuous Clock模式配置不匹配会导致平台侧时钟检测失败这四个参数在OS04A10侧通过初始化寄存器序列配置在平台侧则是在sensor驱动的能力集结构体里声明。两边不一致的典型结果就是示波器能看到MIPI波形但平台ISP收不到完整数据画面黑屏或花屏。我在调试OS04A10时就遇到过sensor初始化序列里把DT配置成了RAW12而平台驱动里声明的是RAW10结果画面出来是红绿蓝三色乱跳的条纹排查到后面才发现是这种低级不一致。3.2 示波器确认sensor到底有没有输出如果配置看起来都对了但还是不出图别急着反复改代码先拿示波器抓一下MIPI物理层信号。这一步能把问题快速定性——到底是sensor没输出还是平台没收到。我一般看三个点MCLK有没有正常供给频率是否稳定是否有明显抖动clock lane在LP状态和HS状态之间是否正常切换data lane上有没有HS数据传输的脉冲如果clock lane一直处于LP状态说明sensor没有被正确stream on或者PLL没有锁定如果clock lane有HS信号但data lane完全没脉冲可能sensor内部图像处理管线没跑起来如果数据lane有信号但画面还是花的那就更可能是协议参数不匹配。示波器虽然不能解出MIPI数据内容但能快速判断sensor的物理层工作状态这在分阶段定位问题时非常关键。3.3 Hi3519DV500侧sensor驱动要注册对海思平台下sensor接入ISP这条链路从软件层面看主要涉及几个环节VIVideo Input模块的MIPI接收配置sensor驱动的注册和加载ISP按sensor能力集进行初始化海思SDK里sensor驱动通常以一个独立的so文件形式提供编译时通过Makefile配置指定使用哪个sensor。OS04A10的驱动需要实现一组标准回调接口包括初始化、退出、设置曝光时间、设置增益、设置帧率等。加载后ISP会读取驱动声明的能力集按这个配置去接收和处理sensor送进来的数据。这里最容易出错的地方是能力集与实际寄存器配置不一致。比如驱动里声明sensor输出2688x1520 RAW104-lane但初始化序列里实际配的是2-lane输出两边对不上图像就会异常。我调试时习惯先把能力集字段逐个和sensor初始化序列核对一遍包括分辨率、帧率、位宽、lane数、MIPI速率全对上了再往下走这一步做个检查表格效率非常高。4. 不出图时根据报错特征反推问题走到这一步配置也核对了示波器也抓了但图像还是出不来就需要建立一套完整的排查链路。调试sensor输入这件事最忌讳东一榔头西一棒子我习惯根据现场现象先分类再按链路顺序系统排查。4.1 完全黑屏也没有数据中断如果VI完全没有产生帧中断优先怀疑MIPI链路握手失败。此时查平台侧MIPI RX的状态寄存器海思平台一般有MIPI相关错误状态位能看到CRC错误、ECC错误、lane状态异常等信息。如果状态寄存器显示没有收到任何有效包那就是物理层或者协议层就没对上。按我的经验优先查两件事第一sensor有没有被真正stream on。有的sensor驱动里stream on函数只是写了某个寄存器但没有延时等待PLL稳定结果平台侧已经开始收数据了sensor这边还没准备好。第二平台侧MIPI接收时钟配置是否在sensor输出范围之内。如果平台期望的lane速率和sensor实际输出速率差太远链路上的CDR时钟数据恢复电路就无法锁定表现为一直收不到有效数据。4.2 花屏、横条纹、噪点优先怀疑数据格式画面能出来但花的通常是数据格式相关的问题。这类问题的特征是错位有规律——整行偏移、颜色通道错乱、规律性横条纹。一句话总结就是sensor怎么出的数据和平台怎么解析的数据两者之间没对齐。常见的不对齐包括以下几类RAW位宽不一致sensor输出RAW10但平台按RAW12解析像素位宽错位Bayer格式不匹配GRBG、RGGB、BGGR这些Bayer排布顺序配置错画面颜色会整体偏色但轮廓正常行消隐/帧消隐参数差异如果平台侧按固定消隐参数去解数据和sensor实际输出不一致画面边缘会出现斜切或错行处理方式是先读取sensor当前实际寄存器状态确认芯片的真实输出配置再和平台解析配置逐一对照不要让我以为sensor是这样配的误导排查方向。4.3 出图后马上黑掉或者间歇性丢帧刚能出图的时候我遇到过画面出来几秒就黑掉的现象。这种问题比一开始就黑屏更让人头疼因为链路本身是通的但某个环节在运行中掉链子。我排查下来这类现象有几类原因一是ISP的3A算法没有正确初始化曝光积分时间被设置成0画面当然就全黑了。二是sensor驱动里的初始化序列不完整某个关键寄存器在运行过程中被平台侧重复写坏导致sensor内部状态机错乱。三是VSYNC/HSYNC同步信号异常导致ISP后续帧同步失败。定位这类问题我建议先在应用层把自动曝光和自动白平衡关掉手动设置一组固定的曝光时间和增益。如果画面稳定了问题大概率在3A链路如果仍然黑掉或丢帧就回头查ISP配置和sensor寄存器状态。5. 出图只是开始输入调试远不止亮起来当屏幕上有稳定画面的时候很多人会觉得调试已经完成了。实际上这恰恰是调试进入深水区的开始。输入调试的核心目标不是亮起来而是稳定地、可靠地、高质量地出图。5.1 帧率与分辨率切换验证先用平台工具抓帧间隔确认实际帧率和目标一致。很多人只看sensor标称30fps但实际走完MIPI、ISP、编码之后端到端不一定还是30fps中间任何一个环节处理不过来都会掉帧。确认基础帧率后还需要验证分辨率切换。OS04A10支持多分辨率输出从2688x1520切到1280x720需要把sensor先stream off重新加载新分辨率对应的寄存器序列再stream on。这套流程里如果漏掉某个复位步骤或者寄存器序列加载不完整切换后图像就会异常。这个问题在量产阶段非常常见因为很多产品菜单里都有分辨率切换功能。5.2 图像质量的基础验证出图稳定了开始验证图像质量。在均匀光照下拍灰阶卡或白墙检查有没有坏点、竖条纹、暗角、噪声偏大等问题。OS04A10这类sensor对电源纹波敏感如果画面上有固定频率的条纹优先检查电源和MCLK的噪声。电源纹波大在图像上通常表现为周期性横条纹MCLK干扰则更多表现为随机噪点。基础曝光换算也要验证。曝光时间寄存器、模拟增益、数字增益之间的换算关系要确认清楚不然后面做3A联动时会发现曝光值对不上。我自己调试时会做一份固定曝光、固定增益、固定白平衡的参数文件方便图像质量测试时反复切换也方便对比不同参数组合下的画质差异。5.3 长时间稳定性最后一道关输入调试的最后一道关是长时间稳定性验证。我习惯做至少24小时烤机观察丢帧计数、I2C通信错误计数、ISP异常中断次数是否为零。烤机期间用脚本定时抓帧检查帧号是否连续。温度因素也不能忽略。sensor长时间工作后温度升高MIPI信号质量和I2C稳定性都可能发生变化。如果烤机期间偶发丢帧大概率是MIPI链路余量不足可以适当调整驱动里的MIPI速率配置或时序参数。如果I2C偶尔通信失败则更可能是电平或者时序裕量问题。5.4 留下一份调试checklist整个调试接近尾声时我会把自己踩过的所有坑整理成一份checklist。包括管脚核对、上电时序、I2C地址检查、MCLK频率确认、MIPI lane数和VC/DT匹配、sensor能力集核对、ISP 3A初始化、帧率与分辨率切换、长时间烤机。每当新项目要换sensor或者换平台就先按这份checklist走一遍大部分问题能在半天内定位。我在实际调试这套Hi3519DV500加OS04A10平台的过程中最深的体会是真正折腾人的往往不是某个高深的技术难点而是sensor侧一份配置、驱动侧一份配置、应用层又来一份配置三份信息不一致导致的低级问题。所以后来我在调试前都会先建一个配置总表把sensor寄存器序列、驱动能力集、应用层设置三方的参数列在一起逐一比对让信息流保持一致很多莫名其妙的问题在动手之前就已经被拦住了。这套思路从OS04A10这个项目之后我一直在用每次都很管用。
返回列表