车载摄像头+max96712 + rk3568 调试过程中遇到的问题

本文不会详细讲解max96712芯片的功能,因为芯片手册上的内容已经足够丰富。本文主要讲述本人在调试rk3568通过mipi-csi2链接max96712,max96712再外接4路车载摄像头过程中遇到的问题,以及最终如何解决这些问题。图中会贴上很多重要且关键的波形图,以便读者在调试过程中进行比对,分析。

1、整体框图

视频数据流框图如下:

由于车载摄像头内部已有ISP,通过mipi到rk3568的图像数据不需要再过soc内部的isp,直接在soc端的cif(vicap)上采集数据即可。所以物理上数据流如下(设备树配置上不需要开isp):

4路车载摄像头(coax)->max96712(mipi)->dphy0->csi2->vicap

2、调试中遇到的问题

2.1、固定无法识别到link D端的摄像头

在max96712中将4路GMSL对应的反向通道,正向通道速率,模式(GMSL1/GMSL2)配置完成,并使能4路GMSL通道,再根据摄像头厂商的要求配置下摄像头就能够识别到摄像头。但是在调试过程中固定无法识别到link D对应的摄像头。通过示波器观察正常和异常情况下GMSL链路上波形。

而在link D的GMSL上通过示波器能成功够抓取到去配置摄像头的数据波形,但是配置完成后,识别不到摄像头即GMSL未link。通过波形,可以肯定软件层面配置摄像头的数据是下发成功了的,再次推动硬件工程师检查原理图.

初看,感觉GMSL_IN3N链接pin6 SIODN,GMSL_IN3P链接pin7 SIODP没什么问题。

看下max96712芯片手册上Pin管脚的描述,

pin6为SIODP,pin7为SIODN。原理图封装画错了,pin6和pin7管脚颠倒了,飞线修改后能够识别到摄像头了。

2.2、抓取图像时内核崩溃

rk3568上抓图时,linux内核产生oops，函数调用栈如下:

根据最后报错的位置,rkcif_queue_setup,走读cif相关代码，最终发现在 rkcif_mbus_pixelcode_to_v4l2 函数中没有可以匹配max96712驱动配置的sensor输入图像类型MEDIA_BUS_FMT_UYVY8_2X8的匹配项。导致rkcif_set_default_fmt-> rkcif_set_fmt 设置stream->cif_fmt_out为NULL,rkcif_queue_setup中则使用到了stream->cif_fmt_out中的值，但是其为NULL指针导致内核产生oops。

在rkcif_mbus_pixelcode_to_v4l2中添加对应的转换项即可，需要注意,如果sensor的图像类型在 in_fmts[]和out_fmts[]不存在的话,需要添加相关的内容,避免输入和输出格式进行检查时不匹配导致其他问题。

修改后再抓图,不会产生oops了。

2.3、抓取图片时产生ecc和crc错误

产生oops的问题解决了，但是抓图时,mipi控制器在不断地报错:

根据错误打印信息,ecc报错的话,说明报头存在误码。crc报错的话,说明数据负载存在误码。也就是说整个数据包都是存在问题。

具体可以查看mipi协议中数据包说明章节的文档。下图是mipi d-phy 长包和短包的协议格式。

软件层面采取的措施如下:

降频,由2G到1G再到400MHZ

降lane,由4x降到2x。

但是问题并没有解决。

用示波器抓取信号图如下:

时钟信号如下:

数据波形如下:

波形上没得什么问题，走查代码,最终排查到max96712的驱动,发现是mipi的lane数配置不对,以及修改 struct rkmodule_csi_dphy_param中vendor成员由PHY_VENDOR_SAMSUNG修改为PHY_VENDOR_INNO。

完成上述修改后,每路摄像头抓图图像成功。

如果在调试过程中,mipi总线上的波形没得什么问题的话,还是抓图失败的情况下,需要着重检查 频率,lane数,摄像头分辨率,摄像头输入图像格式 等重要配置**。** 如果内核产生了MIPI或者d-phy或者cif或者isp错误打印信息,那么就需要根据报错的位置去走读下相关部分代码来排查报错的原因了。