企业官网建设流程全解析

Linux I2C 调试三板斧：从 regmap 到逻辑分析仪

I2C 在嵌入式系统里像空气一样无处不在——Sensor 配置、EEPROM、PMIC、Tuning 参数，全走 I2C。但 I2C 不出问题还好，一出问题能卡你好几天。

这篇文章不讲 I2C 协议基础，直接讲调试实战。

第一板斧：I2C-tools

工具集装一次，受用终生：

# 扫描总线i2cdetect-y0# 读写寄存器i2cget-y00x30 0x10 w# 读 wordi2cset-y00x30 0x10 0xFF# 写 byte# dump 一段寄存器i2cdump-y00x30 b

最常见的坑：i2cdetect显示--（地址被占用）其实不一定说明设备坏了。有些 Sensor 在进入 streaming 状态后会屏蔽掉通用扫描命令，需要用-r参数强制读。

还有发现i2cget读出来全是0xFF——不是设备坏了，是 I2C 总线上的上拉电阻焊错了。4.7K 换 2.2K 立马正常。

第二板斧：内核调试接口

Linux 内核的 I2C 子系统提供了很多调试手段，很多人不知道：

# 打开 I2C 调试日志echo0x0f>/sys/module/i2c_core/parameters/irq_debug# 查看 I2C 适配器信息cat/sys/bus/i2c/devices/i2c-0/namecat/sys/bus/i2c/devices/i2c-0/speed# 查看设备树里配的设备cat/sys/bus/i2c/devices/0-0030/name

更高级的：打开内核 I2C 消息跟踪：

// 在驱动里加，或改内核配置#CONFIG_I2C_DEBUG_BUS=y#CONFIG_I2C_DEBUG_CORE=y

开了之后 dmesg 会看到每次 I2C 传输的完整消息流——地址、长度、数据。在排查 NACK 或总线 Hang 问题时非常有用。

第三板斧：逻辑分析仪抓波形

软件调试到极限了，必须上逻辑分析仪。

I2C 协议很简单，总共就 SCL 和 SDA 两根线。但看波形时重点看三个地方：

1. 起始条件（START Condition）

• SCL 高电平时，SDA 从高→低跳变
• 最常见的问题：上拉电阻太大，SDA 下降沿太缓，导致从设备没识别到 START

2. ACK/NACK

• 第9个 SCL 时钟，主设备释放 SDA，从设备拉低表示 ACK
• 连续出现 NACK 的三个原因按概率排序：
  ① 地址不对（7位 vs 8位地址搞混了）
  ② 设备没上电
  ③ 设备处于 busy 状态（正在处理上一笔传输）

3. STOP Condition 后的总线状态

• SCL 高电平时，SDA 从低→高跳变
• STOP 后 SDA 和 SCL 都应该被上拉到高电平
• 如果 STOP 后 SDA 被拉到低电平 → 总线锁死了

总线锁死（Bus Lock）是我遇到的 I2C 最恶心的 bug。原因是某个传输中途被中断了（比如系统高负载时 I2C 中断被打断），导致从设备还在等时钟，主设备已经不发了。

解决办法：

• 硬件层面：SCL 上串联一个 GPIO，检测到总线锁死时主动给 9 个时钟脉冲复位从设备
• 软件层面：I2C 传输加超时，超时后 reset I2C 控制器

踩坑实录：Sensor I2C 配置失败

分享一个案例——某款 Sensor 在批量生产时，大约 3% 的模组 I2C 读 ID 失败。

现象：

• i2cdetect 能扫到设备地址
• 读 16-bit 寄存器时，前 50 次成功，第 51 次开始返回 0xFF
• 复位 Sensor 后恢复，但传输 30-40 次后又挂

排查过程：

1. 先怀疑时序——加大clock-frequency从 400K 降到 100K，没用
2. 开I2C_DEBUG_BUS看内核日志，发现每次失败前有一笔「写 16-bit 地址 + 读 8-bit 数据」的传输耗时超过 10ms
3. 上逻辑分析仪抓波形，发现 Sensor 在某些写入后需要 5-8ms 的「消化时间」，如果这期间发新请求，SENSOR 内部还在处理上一笔，导致 ACK 丢失

根因：Sensor 的 OTP（One-Time Programmable）校准区读取不能连续访问，每次读之间需要至少 5ms 的 delay。

修复：在驱动里每次读 OTP 寄存器后加usleep_range(5000, 8000)。

I2C 调试决策树

总结

做嵌入式这么多年，I2C 的坑永远不是协议本身，而是物理层和时序。