Camera I2C不通的分析思路

转载 已于 2025-01-20 11:34:16 修改 · 2.8k 阅读 · 20 ·
CC 4.0 BY-SA版权
原文链接：https://www.aliyun.com/jiaocheng/14274.html
文章标签：

#i2c

于 2018-08-15 15:07:29 首次发布
本文提供了摄像头调试的常见问题解决思路，包括I2C不通的分析方法、花屏问题的可能原因及解决方案、光晕现象的排查步骤。对于I2C不通的情况，文章详细介绍了如何通过检查slave端和master端来定位问题；对于花屏问题，则分析了HS/VS/PCLK极性配置错误或驱动电流不足的影响；光晕现象则通常由data线丢失导致。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

常见问题及debug

1) Camera I2C不通的分析思路

I2C不通,有两种原因:一种是device端(也就是我们的camera sensor)本身就没有回ACK,另一种就是在master端(也就是我们的baseband端)。我们可以从kernel log里面搜索I2C的关键字:“I2C_TIMEOUT”和“I2C_ACKERR”。

I2C_ACKERR:问题多半在slave端,需要检查上电时需是否符合sensor spec的规范,和模组厂的工程师或者sensor厂的工程师一起修改sensor的上电时序。（PS：工作中遇到另外一种情况，在上电时序正常的情况下，还是发现I2C不通。最后是I2C驱动能力不足的问题，增强I2C的驱动电流即可。）

I2C_TIMEOUT:一般是BB端,至于是代码的哪个地方造成的I2C_TIMEOUT,我们得根据具体问题具体分析,出现I2C_TIMEOUT的rootcause之一是, 在I2C bus上没有上电的情况下去操作I2C,就会出现timeout。如果I2C bus有电,就需要结合示波器等手段深入分析。这个问题也是分析一般I2C器件不通的常用思路。 

2)花屏:如果是很多绿线的花屏的话那么通常是HS/VS/PCLK的极性配置反了或者驱动电流太小被干扰了,如果是红蓝的颜色反了的那么是yuv输出数据反了。

3)光晕:出现此种现象的原因是data线有丢失。

a) 检查data line是否配置正确。

a) 可以修改sensor的输出能力,另一个是改pclk的极性。

b) 去掉HW上的,CAMERA data pin上的EMI器件。

供自己备忘：

原文地址：淘宝网 - 淘！我喜欢

I2C不通的分析思路
当我荒废时间的时候，会有多少人在拼命
10-12 1590
本篇文章主要介绍了"I2C不通的分析思路"，主要涉及到I2C不通的分析思路方面的内容，对于I2C不通的分析思路感兴趣的同学可以参考一下。 [DESCRIPTION] 在camera porting的过程中，有很多原因会导致Camera I2C不通 此篇FAQ的目的是为camera i2c没通的情况，提供一个大概的思路   [SOLUTION] I2C不
Linux驱动分析——I2C子系统
fang_yang_wa的博客
01-28 1017
stm32mp157 盘古开发板 Linux内核版本4.19 目录 1、朱有鹏老师视频笔记 2、I2C子系统的4个关键结构体 3、关键文件 4、i2c-core.c初步分析 ​4.1、smbus代码略过 4.2、模块加载和卸载:bus_register(&i2c_bus_type); 在i2c-core-base.c中 4.3、I2C总线的匹配机制 ​4.3.1、match函数 4.3.2、probe函数 4.4、核心层开放给其他部分的注册接口 5、adapter模...
当camera遇到i2c 不通该怎么办？
极创it的博客
06-30 1330
1.检查硬件i2c是否有波形，mipi是否有数据。（若i2c没波形，考虑是不是i2c的电源未开启） 2.检查软件上电时许是否符合规格书[data sheet]的要求 3.检查i2c地址是否有冲突:比如2颗sensor的地址都为0x2c，这就有问题了。 ...
camera sensor i2c数据传输时序及其分析
Focus on the Linux kernel
10-30 4160
以上时序摘自镁光的一款camera sensor. 1写模式：   首先开始信号，主机发送从机地址（0-7位）/写（第8位），等待从机发送ACK信号，应答之后发送word16位的消息为sensor寄存器地址，分八位传输中间有ACK信号。同理接着发送16位value对应刚才寄存器地址。（见下面源码）   static int mt9t013_i2c_write_w(unsigned sho
【Camera专题】I2C不通或地址读错总结
jfl558604的博客
03-23 2988
最近遇到一个比较奇葩的问题：我们kernel层加了后摄的otp后，会出现某些机器概率性前摄ID读错问题，otp读出来的数据也全是0。dtsi文件关于otp的修改···//id读错//otp读错···分析：i2c通信时ok的，但是就是读错了，肯定是读到某个地址的值了，所以id没读对，移除dtsi后摄的otp修改，就能读对。可以确认的是加了后摄的otp导致的。需要注意的是，otp是烧录在sensor。
I2C不通，可能的原因分析
lizhiguo199013的专栏
07-16 6116
I2C不通，可能的原因分析步骤： 1.检查上电是否正确 2.检查从芯片的主输入时钟（mclk）是否正确 3.检查i2c线路配置（i2c控制器配置）是否正确 4.检查从设备i2c地址及i2c速率配置是否正确...
I2C 不通 排查方法
a895176463的专栏
03-18 2663
I2C 总线比较简单，可能的问题主要出在时序上，一般设计者即使忽略也不太会有麻烦，但是有几个指标一定要认真考虑：1、总线驱动能力。上拉电阻和负载电容决定了总线在某一速率下的稳定性。当输出为高时，电流通过上拉电阻对负载电容充电。上拉越大，电容越大，所需要的时间就越长，如果超过了通信周期的10%，那么这个上升沿就太缓了，相应的建立时间会受到影响，I2C规范的最大负载电容是400pF，快速模式下是100pF。
camera调试：i2c不通如何排查？
qq_34341546的博客
02-14 6595
camera调试，i2c通讯失败，驱动注册失败问题排查
camx EAP问题分析一：【硬件故障】/vendor/lib64/hw/camera.qcom.so crash解决思路。8625174
04-21 1544
camx EAP问题分析一：【硬件故障】/vendor/lib64/hw/camera.qcom.so crash解决思路。一般产品发布后会监控用户反馈的诸多异常，如ANR率，crash率，重启率等等，开发需要一个个去修复解决，并在后续的版本OTA升级来修复问题。同时测试团队会要求各种标准要达标，这里我们分析一个top eap crash问题，既然是硬件问题，又如何达标呢？
Camera知识问答
weixin_38360181的博客
07-20 4798
I2C不通的情况下怎么检查？ I2C地址，址的宽度，总线配 确认sensor的i2c地址是否配置正确，由于i2c通信地址是7bit，而不同的平台可能存在差异。有些配置7bit；有些则配置8bit，最后一位是读写标志。 检查上电时序 确认驱动中，是否在上电过程中，都按照sensor datasheet的上电流程配置电源和将reset，pwdn拉到相应的电平状态 检查上电电压是否正确 检查mclk 硬件测量是否正确 是否与别的I2C地址冲突 mipi不通的情况下怎么检查？ 确认硬件mipi lane上是..
camera MCLK配置错误造成 i2c不通的 修改方法
wang714818的博客
09-17 5357
[DESCRIPTION] 在MT6795 MT6735平台，HW 上MCLK和SW上MCLK 配置不匹配的话，如HWMCLK 共用，SW没有共用的话，会造成能开机搜到对应的sensor id，但open时又找不到id，i2c不同。 1 开机能search 到sensor id原因：开机时三路MCLK 的pll都打开了，所以在kd_camera_hw.c中对正确的MCLK上电就可以正常工作
Camera i2c、常见概念、系统架构简介
weixin_38360181的博客
07-21 3124
Cmera I2C介绍 I2C总线协议 I2C总线在物理连接上比较简单，分别由SDA(串行数据线)和SCL(串行时钟线)及上拉电阻组成。通信原理是通过对SCL和SDA线高低电平时序的控制，来产生I2C总线协议所需要的信号进行数据的传递。在总线空闲时，这两根线一般被上面所接的上拉电阻拉高，保持着高电平。I2C通信方式为半双工，只有一根SDA线，同一时间只可单向通信。 * ** I2C总线特征 I2C总线上的每一个设备都可以作为主设备或者从设备，而且每一个设备都会对应一个唯一的地址(地址通过物理接地或者拉高..
camera和codec调试利器–i2c tool
#维多利亚的秘密#
11-03 1249
最近调试codec的驱动调试郁闷了，一次又一次的重新编译内核，一次又一次的烧写。于是想能不能简单的修改寄存器参数呢?经过google后果然有，那就是i2c-tool ，这一系列工具。 下载 http://dl.lm-sensors.org/i2c-tools/releases/ 编译 1.解压到i2c tool目录。 2.进入i2c tool，修改Make
MTK 平台 camera点亮之 I2C不通
Cam_韦的博客
11-09 2849
由于MTK平台 camera点亮涉及很多文件，很可能造成点亮失败！！！。I2C不通是点亮失败的重要之一，总结如下做相互学习，也做备忘之效 1、对照spec文档，检查上下电时序（AVDD、DVDD、DOVDD、RST、PowerDown） 2、对照上电，用示波器检查的信号（SDL/SCL)波形 3、检查当前的camera 模组挂载I2C bus。检查模组规格书中I2C芯片地址，和代码中kernel-4.14/drivers/misc/mediatek/dws/项目名.dws ...
I2C的那些坑和填坑方法（I2C失效原因及解决办法）‌
最新发布
2503_91889531的博客
05-08 1565
用最接地气的话讲透I2C的那些坑和填坑方法（I2C失效原因及解决办法）‌
Camera IIC总线
自废一胳膊
03-08 1284
Camera IIC总线 该文章写于2016年，一直未发表。近期工作中又涉及到了Camera相关的内容，重新温习了下相关知识。决定把这篇文章发表出来，大家共同学习。   IIC即Inter-Integrated Circuit：集成电路总线，有时简写为I2C，是飞利浦半导体公司在八十年代初设计出来的一种简单、双向、二线制、同步串行总线。，IIC是一种多向控制总线，多个芯片可以连接到同一总线结构下，同时每个芯片都可以作为实时数据传输的控制源。IIC协议标准规定同一时刻只可以有一个设备发起通信，称为主设备
Camera BSP之GPIO/I2C/PMIC简介
程序员Android
10-16 1076
和你一起终身学习，这里是程序员Android经典好文推荐，通过阅读本文，您将收获以下知识点:一、GPIO介绍二、I²C 总线概括三、PMIC 概括四、思考一、GPIO介绍GPIO：General Purpose Input Output （通用输入/输出）GPIOs are I/O pins that provide peripheral connections to the MSM™ chips...
解决Popmetal板上I2C挂载额驱动不正常，含陀螺仪、重力传感器
u010854102的专栏
08-05 684
最近楼主拿到的popmetal板上的陀螺仪芯片使用不正常，可读到设备号，却没办法读到数据，经过测试，发现所有挂载在IIC总线上的设备全都不正常，然后在别人的另一块板上可正常运行，发现两块板的IR旁的编号不一样，别人板编号是1445，而楼主的板是1522，估计是新板，在询问芯客的工程师后，他们在检测之后，发现是新板中i2c-1总线上的SDA信号被干扰了，sda线被强制拉低，故只要将对应的干扰信号的线
camera实现一个image 自适应几十个camera ----- i2c 设备 unregister 过程
JK198310的专栏
12-25 852
xxx_subdev_probe v4l2_i2c_new_subdev_board     ==>  i2c_new_device:     ==>  really_probe         probe_failed:         dev_set_drvdata(dev, NULL);
写一个kill 枚举 内核日志camera进程的脚本
03-19
<think>好的，用户让我写一个能够枚举并杀死相机相关进程的内核日志脚本。首先，我需要理解他的需求。他说要“kill 枚举 内核日志camera进程”，可能是指查找与摄像头相关的进程，记录到内核日志，并终止这些进程。不过，直接杀死内核进程可能有风险，我需要提醒他注意这一点。 接下来，我需要考虑如何实现这个脚本。用户可能希望脚本自动查找所有与摄像头相关的进程，比如使用grep过滤进程名中包含“camera”的条目，然后获取PID，记录到内核日志，最后用kill命令终止。不过，内核日志通常是通过dmesg或者syslog来管理的，可能需要使用logger命令或者直接写入/dev/kmsg。 另外，用户提到“内核日志”，可能需要将操作记录到系统日志中，这样在排查问题时可以查看。因此，在脚本中添加日志功能，比如使用logger或者echo到/dev/kmsg，但需要注意权限问题，可能需要root权限。 然后，安全方面。直接杀死进程可能会导致系统不稳定，特别是如果杀错了关键进程。因此，在脚本中需要加入确认步骤，或者先列出进程让用户确认后再杀死。用户可能希望自动化，但安全起见，还是应该给出提示。 还有，查找进程的方法。使用ps命令配合grep过滤，但要注意grep自身也会出现在结果中，需要使用grep -v grep来排除。或者使用pgrep更直接获取PID。此外，进程名可能不一定是“camera”，可能需要更宽泛的关键词，比如“camera”、“video”等，或者查找使用/dev/video0设备的进程，使用lsof /dev/video*来获取相关信息。 另外，用户可能遇到无法用普通kill命令终止的进程，这时候可能需要使用kill -9，但这也更危险。是否在脚本中使用-9选项？可能需要作为可选参数，或者在强制模式下使用。 最后，脚本的结构。可能需要分为几个部分：查找进程、记录日志、杀死进程。同时，处理权限问题，可能需要sudo运行。还要考虑兼容性，不同的Linux发行版可能有些命令路径不同，但一般常用的工具如ps、grep、kill应该都是可用的。 现在，综合这些考虑，我需要编写一个脚本，首先查找与摄像头相关的进程，记录相关信息到系统日志，然后询问用户是否终止，或者自动终止。同时，处理可能出现的权限问题，并给出适当的警告信息。</think>--- ### **分步实现脚本设计思路** #### **1. 核心需求分析** - **目标**：捕获与摄像头相关的进程，记录到内核日志（dmesg），并支持选择性终止 - **难点**：精确匹配进程、避免误杀系统关键服务、内核日志写入权限 #### **2. 技术方案选择** | 组件 | 选择理由 | |-----------------|--------------------------------------------------------------------------| | `lsof + /dev/video*` | 直接定位使用摄像头设备的进程（比进程名更可靠） | | `dmesg -T` | 解析人类可读时间戳的内核日志 | | `logger` | 通过syslog间接写入内核日志（避免直接操作`/dev/kmsg`的高风险） | | `kill -15` | 优先尝试SIGTERM正常终止，而非直接使用SIGKILL | --- ### **完整脚本代码** ```bash #!/bin/bash # 脚本名称：camera_killer.sh # 功能：定位摄像头进程并记录到内核日志，支持安全终止 # 执行权限：需root权限 LOG_IDENT="CameraKiller" # syslog标识 # 检测root权限 if [[ $EUID -ne 0 ]]; then echo -e "\033[31m错误：此脚本必须用root权限执行\033[0m" >&2 exit 1 fi # 核心函数：记录到syslog并显示 log_to_kernel() { local message="$1" logger -t "$LOG_IDENT" "$message" echo "[KERNEL LOG] $message" } # 查找摄像头相关进程 find_camera_processes() { log_to_kernel "开始扫描摄像头进程..." # 方法1：通过设备文件查找 CAM_DEVICES=$(ls /dev/video* 2>/dev/null) if [[ -z "$CAM_DEVICES" ]]; then log_to_kernel "未找到摄像头设备文件" return 1 fi # 获取使用摄像头的进程 LSOF_OUTPUT=$(lsof $CAM_DEVICES 2>/dev/null | awk 'NR>1 {print $2,$1,$NF}') PIDS=$(echo "$LSOF_OUTPUT" | awk '{print $1}' | sort -u) # 方法2：通过进程名二次过滤 PROCESS_NAMES=("cheese" "guvcview" "v4l2" "camera" "gst-launch") EXTRA_PIDS=$(pgrep -f "$(IFS=\|; echo "${PROCESS_NAMES[*]}")" || true) ALL_PIDS=$(echo "$PIDS $EXTRA_PIDS" | tr ' ' '\n' | sort -u) if [[ -z "$ALL_PIDS" ]]; then log_to_kernel "未找到活跃的摄像头进程" return 0 fi # 显示进程详情 log_to_kernel "发现摄像头相关进程：" ps -p "$ALL_PIDS" -o pid,user,comm,cmd return 0 } # 终止进程逻辑 kill_processes() { local PIDS=$1 for PID in $PIDS; do # 跳过系统关键进程检查 if [[ $(ps -p $PID -o comm=) =~ ^(systemd|udevd|Xorg)$ ]]; then log_to_kernel "跳过系统关键进程：PID $PID" continue fi # 先尝试SIGTERM log_to_kernel "正在终止进程 PID=$PID ..." kill -15 $PID 2>/dev/null # 检查是否存活 sleep 1 if kill -0 $PID 2>/dev/null; then log_to_kernel "进程 $PID 仍在运行，尝试SIGKILL" kill -9 $PID fi done } # 主流程 case "$1" in --kill) found_pids=$(find_camera_processes | grep -Po 'PID \K\d+' | tr '\n' ' ') kill_processes "$found_pids" ;; *) find_camera_processes echo -e "\n\033[33m如需终止以上进程，请执行：$0 --kill\033[0m" ;; esac ``` --- ### **关键安全机制说明** 1. **双重验证机制**： - **硬件层**：通过`lsof`直接检测使用`/dev/video*`设备的进程 - **软件层**：通过进程名二次匹配（支持自定义正则表达式） 2. **系统进程保护**： ```bash # 过滤白名单进程 if [[ $(ps -p $PID -o comm=) =~ ^(systemd|udevd|Xorg)$ ]]; then log_to_kernel "跳过系统关键进程：PID $PID" continue fi ``` 3. **分级终止策略**： - 优先使用`SIGTERM`允许进程清理资源 - 若进程未响应，1秒后升级到`SIGKILL` --- ### **使用示例** #### 1. 仅检测不终止 ```bash sudo ./camera_killer.sh ``` **输出示例**： ``` [KERNEL LOG] 开始扫描摄像头进程... [KERNEL LOG] 发现摄像头相关进程： PID USER COMMAND COMMAND 4567 user chrome /opt/google/chrome/chrome --use-camera 8910 user v4l2-ctl v4l2-ctl --list-devices 如需终止以上进程，请执行：./camera_killer.sh --kill ``` #### 2. 执行终止操作 ```bash sudo ./camera_killer.sh --kill ``` **内核日志验证**： ```bash dmesg -T | grep CameraKiller ``` **输出**： ``` [Fri Jun 7 14:30:15 2024] CameraKiller: 正在终止进程 PID=4567 ... [Fri Jun 7 14:30:16 2024] CameraKiller: 进程 8910 仍在运行，尝试SIGKILL ``` --- ### **扩展建议** 1. **审计功能增强**： ```bash # 记录完整进程树 pstree -p $PID | logger -t "$LOG_IDENT" ``` 2. **摄像头状态监控**： ```bash # 持续监控摄像头使用 inotifywait -m /dev/video0 | while read; do ./camera_killer.sh --kill done ``` 3. **与SELinux集成**： ```bash # 阻止特定进程访问摄像头 ausearch -c '进程名' --raw | audit2allow -M mypolicy semodule -i mypolicy.pp ``` 如果需要进一步调整进程匹配规则或日志格式，请提供具体场景需求。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值