Android Camera 驱动 读取摄像头ID失败问题、低温下Camera打开花屏或者读不到id、概率性读取不到id

  • 底层驱动读不到摄像头的ID,可以从以下几个方面做检查

  • 首先检查硬件方面,多拿几个摄像头模组来做试验。因为会存在打样模组有问题的情况,在原理图上对清摄像头的各个脚是否都对应上了、模组是否都扣好等。这个是硬件层面上的。

  • 第二检查I2C地址是否正确,如MTK平台的基本都是以7位地址的方式操作的。既是偏移一位的。最后是要看看模组的规格书,确认器件的I2C地址

  • 第三就要看摄像头的上、下电时序这一块。如MTK平台的,它在这个文件里实现:mt6737_65_a_n_mp1\kernel-3.18\drivers\misc\mediatek\imgsensor\src\mt6735\camera_hw\kd_camera_hw.c。不同厂家的模组它的上下电时序是有所差别的,其实在你为系统添加摄像头的时候这个上下电时序就加进来了。上电时序也要参考模组规格书去写

  • 如果以上的都检查完了,都没问题,那么开始检查CMMCLK,一般会有两路CMMCLK。前后摄像头各走一路,我们需要看一下前后摄分开走mclk的还是共用一路的。我们在kd_camera_hw.c这文件里的
    kdCISModulePowerOn 和 else { /* power OFF */ 里,可以看到了有类似于如下的函数调用:

在这里插入图片描述

这里就是根据pinSetIdx来打开或关闭MCLK1 或者 MCLK2。需要注意两个点

mt6737_65_a_n_mp1\vendor\mediatek\proprietary\custom\mt6735\hal\D1\imgsensor_src\cfg_setting_imgsensor.cpp
。在这个文件里有个 MINT32 getSensorMclkConnection(EDevId const eDevId)
这个函数,要看看这里有没有被写成前后摄共用MCLK了。最好是用示波器去量过,确定它是有信号输出。

还有就是要用示波器量一下MIPI信号,看看主控有没有输入信号,以防万一。

如以上都检查完了,都没问题。但还是读ID失败的话,那我们就要看一下I2C的通道是否配置正确。因为主控一般都会有好几路I2C,完成了这6项的检查基本都会找到问题了,一定要配合抓串口log去调试、解决问题。

低温下Camera打开花屏或读不到id

问题模组:三星s5k4h7模组

模组厂:光阵

现象:低温-10°存储1个小时,开机后,第一次打开摄像头,多个模组出现花屏问题以及Camera读不到id问题,

花屏问题的机器,第二次或者第三次打开后就好了,

读不到id的机器,第二次重启系统,就正常了

现象截图

在这里插入图片描述

在这里插入图片描述 在这里插入图片描述

问题如下:

低温下Camera花屏问题,,针对低温花屏问题:第二次或者第三次打开后预览画面正常

低温下Caemra读不到id问题,,针对低温读不到id问题:第二次或者第三次打开,或者再次重启就好了

低温下有问题,正常温度下,没有这种现象,和硬件有关系。低温下供电不稳定,在不稳定的低温下,某些器件没法正常工作

排查方向

软件检查,对比软件最近是否有与相机相关的改动,回退旧版本进行验证

版本回退 看以前版本是否出现问题,增加实验数量,统计概率

在这里插入图片描述

验证发现,新旧版本出现问题比例差不多

去除Isc补偿

软件编译了一版去掉加载后摄OTP的程序,验证一台花屏的机器好了

固定绿屏问题,烧回工程样机程序没问题,与工程样机程序相比,批量程序增加了OTP LSC,临时编译一版关闭LSC程序验证绿屏问题消失

将关闭LSC的版本烧入低温花屏的机器,验证没问题,但是打不开摄像头的机器烧入该版本无效

取消后摄摄像头BTB上的泡棉验证,无效

由于打不开的是前摄,所以更换前摄验证,无效

时序检查,确认是否低温下时序发生变化

在这里插入图片描述

电源检查,确认是否低温下电源发生变化

在这里插入图片描述

  • 总结

在这里插入图片描述

低温情况下,LDO工作不稳定,导致给DVDD的供电不足1.2V,因此造成花屏或者读不到ID问题

LDO即low dropout regulator,是一种低压差线性稳压器,我们用的是1.2V的LDO。

pm8916_s3提高在启动camera时,拉高到1.5v,(原先是1.4v),在低温下不稳定!拉高后,低温下的供电如下:

在这里插入图片描述

kernel/arch/arm/boot/dts/qcom/项目.dtsi

在这里插入图片描述

kernel/arch/arm/boot/dts/qcom/msm8916-regulator.dtsi

在这里插入图片描述

rpm_proc/core/systemdrivers/pmic/config/msm8909/pm8916

– {300, 0, PM_ACCESS_ALLOWED, PM_ALWAYS_ON, PM_NPA_SW_MODE_SMPS__NPM, PM_CLK_1p6_MHz, PM_CLK_1p6_MHz,
PM_DROOP_DETECT_DIS, 1250, 1413, 0, PM_SETTLING_ERR_DIS,
PM_SETTLING_EN, 0}, //ULT BUCK CTL1

++ {300, 0, PM_ACCESS_ALLOWED, PM_ALWAYS_ON, PM_NPA_SW_MODE_SMPS__NPM, PM_CLK_1p6_MHz, PM_CLK_1p6_MHz,
PM_DROOP_DETECT_DIS, 1250, 1500, 0, PM_SETTLING_ERR_DIS,
PM_SETTLING_EN, 0}, //ULT BUCK CTL1

硬件方面:更换了更加稳定的LDO!

  • 概率性读不到id

  • 顺序影响

  • 平台:qcom-429

  • 前后id的读取顺序和otp的加载顺序不一致,导致概率性读不到id的,高通在点亮gc8034时,也遇到概率性读不到id的情况。后来和他们沟通,是两个sensor上电相互影响了。

在这里插入图片描述

  • ov8856先上电,会影响到gc8034的上电,导致gc8034读不到id!换一下顺序就可以了

  • OTP上电影响

  • 平台:8909

  • 这个平台配OTP上电时序是在kernel的dtsi文件里配置的,高通的文档配置如下:

在这里插入图片描述

qcom,cam-power-seq-cfg-val代表了上电时序,1表示拉高或者供电!

dvdd拉高->avdd拉高->io拉高->设置mclk为24M->reset脚拉高->standby脚拉高

下电时序是:

standby脚拉高->reset脚拉高->设置mclk为24M->io拉高->avdd拉高->dvdd拉高,下 电时相应的脚没有被拉低!

以reset脚为例

“sensor_gpio_reset”,->0先拉低 “sensor_gpio_reset”,->1在拉高

因此,qcom,cam-power-seq-cfg-val = <1 1 1 0 1 24000000>;这个配置对应的上电时序:

dvdd拉高->io拉高->reset脚拉低->reset脚拉高->standby脚拉高->设置mclk为24M

下电的时候,是反过来执行的,下电时序是

设置mclk为24M-standby脚拉高->reset脚拉高->reset脚拉低->io拉高->dvdd拉高

最终,reset脚会被拉低,这样reset脚就没问题了!概率性读不到id问题也可能跟这个有关系!

因为我们前后摄供电都是用的同一路供电,挂在相同的i2c总线上。

前摄 OTP下电是时候,如果reset脚还是一直拉高着,i2c总线会觉得前摄还在工作,

这时候代码跑到后摄otp上电了,就可能会导致i2c地址读错或者read_id failed!

  • 2
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值