I2C控制器Busy死锁根因分析与总线恢复机制设计

1. 问题初见：I2C 控制器卡死在 Busy 状态

做嵌入式开发的朋友，十有八九都跟 I2C 打过交道。这协议看起来简单，就两根线——SCL 时钟、SDA 数据，加上上拉电阻就能跑，最高速率还能到 3.4Mbps（高速模式），灵活性和扩展性都没得说。但正因为简单，一旦出问题，反而更难排查，因为它不像 USB、PCIe 那些复杂协议有完善的错误上报机制，很多时候就给你一个干巴巴的状态位。

这次要聊的问题就是 I2C 控制器进入 Busy 状态后无法退出。现象非常典型：主控通过 I2C 去读传感器或 EEPROM 的数据，代码执行到I2C_WaitFlag或类似等待 Busy 标志清除的地方，就死等在那里，超时之后报错，但再次初始化依然无法恢复。用示波器抓 SCL 和 SDA，能看到两根线要么一直拉低，要么呈现一种非常诡异的不完整波形——时钟数到一半停了，数据位传了一半断了，总之总线状态和控制器内部的状态机完全对不上。

这个问题的麻烦之处在于：它不像通信失败那样能重试解决，Busy 状态是控制器内部状态机锁死的表现，常规的软件重试根本没用。你发Start命令，控制器不回你；你发Stop命令，它也装作没看见；寄存器读出来的 Busy 位一直为 1，怎么都清不掉。遇到这种情况，经验不足的人很容易掉进反复调试超时参数、重写驱动逻辑的坑里，折腾一整天都找不到根因。

我是怎么碰到这个问题的？当时在调试一块带电容触摸屏的开发板，触摸屏通过 I2C HID 协议跟主控通信。系统跑着跑着，触摸突然没反应了，内核打印i2c_designware驱动的报错，说控制器超时。我看了下i2cdetect -l，总线还在；但i2cdetect -y 1扫描设备时，所有地址都返回UU（表示地址被驱动占用）或直接报总线错误。i2cget读设备寄存器，指令发出去就卡住，等了几秒钟才返回Remote I/O error。这种表现，基本就是控制器进 Busy 死锁了。

排查过程确实走了不少弯路，所以这篇博文我不打算只讲“怎么解决”这一个点，而是想把整条排查链路、每个关键决策背后的理由、以及最后沉淀下来的一套实用方案都讲清楚，里面有不少踩坑换来的经验，常规文档里不会有。如果你也在调 I2C，尤其是做 Linux 内核驱动、裸机驱动或者 MCU 上的 I2C 外设驱动，这篇文章应该能帮你省下不少排查时间。

2. 根因拆解：Busy 状态为什么会产生

2.1 从协议层面理解 Busy 状态的含义

要理解 Busy 状态，先得搞清楚 I2C 协议里“总线忙”这个概念是怎么定义的。I2C 是半双工通信，SCL 和 SDA 都是开漏输出，通过上拉电阻拉高。空闲状态下，两根线都是高电平。当一个主机要发起通信时，它先在 SDA 上产生一个下降沿（此时 SCL 为高），这叫 Start 条件；通信结束时，在 SCL 为高的时候让 SDA 产生一个上升沿，这叫 Stop 条件。

所以从协议层面来说，总线是否忙碌，看的是当前有没有 Start 条件产生而 Stop 条件还没出现。硬件上，I2C 控制器内部会有一个状态机来跟踪这个状态，还有一个 Busy 标志位来反映它。正常情况下，主机发送完 Stop 条件后，Busy 位应该自动清零。但问题往往就出在这个“应该”上。

实际工作中有个容易忽略的点：Busy 位的判断不止看控制器自身发出的 Start/Stop，还取决于它监测 SDA 和 SCL 电平变化的方式。很多控制器的 Busy 检测逻辑是这样的：它持续监测 SDA 线，如果检测到下降沿（认为可能有 Start），就进入 Busy 状态；如果检测到上升沿（认为可能是 Stop），就退出 Busy 状态。问题在于——这个上升沿或下降沿的判定，有一个同步逻辑和滤波逻辑在里面。如果 SDA 线上有毛刺，或者电平处于中间状态（因为负载过大导致上升沿不够陡峭），控制器内部的同步器可能采到错误的值，导致状态机跳转出错。

2.2 从异常路径分析：谁在捣乱

根据我排查过的多个案例，I2C 控制器进入 Busy 死锁，常见原因可以归为以下几类：

第一类：物理层异常。这是最常见的原因。SDA 或 SCL 被外部设备拉死（比如从机故障锁死总线）、上拉电阻阻值不对导致信号上升沿太缓、总线电容过大导致波形畸变、或者板子上有焊接短路问题。这类问题通常是偶发或者一开始就存在，特定温度或电压条件下浮现出来。

第二类：从机异常。I2C 从机如果进入异常状态（比如内部逻辑跑飞、固件 bug），可能会在收到部分数据后不释放总线，或者持续拉低 SCL 进行时钟拉伸（Clock Stretching）但没在合理时间内释放。有些容性触摸屏控制器、充电管理芯片都出现过类似情况。

第三类：主机状态机跑飞。这属于控制器本身的问题。比如你在通信过程中来了个高优先级中断，中断服务函数里又碰了 I2C 外设（在裸机环境下这种嵌套非常危险），导致正在传输的字节被中断打断。控制器启动了一个 Start 条件或发送了一半数据，状态机记录到“传输中”，但传输永远无法完成，Busy 标志自然清不掉。

第四类：电气干扰。在电机驱动、逆变器等强干扰环境下，I2C 线上会耦合噪声。如果噪声导致 SDA 或 SCL 上出现虚假的 Start/Stop 信号，控制器的 Busy 状态机就会被误导。

我做了一个简单的排查落点对照表，方便大家快速定位问题方向：

2.3 控制器的状态机设计缺陷

这是我最想单独拿出来聊的一点。硬件 I2C 控制器的状态机设计是有先天缺陷的，至少在很多中低端 MCU 和 SoC 上是这样。

以我当时用的 DWC（DesignWare）I2C 控制器为例，它的状态机里有几个寄存器：IC_STATUS（状态寄存器）、IC_INTR_STAT（中断状态寄存器）、IC_RAW_INTR_STAT（原始中断状态寄存器）。其中IC_STATUS的 bit 0 就是ACTIVITY位，bit 5 是SLV_DIS，bit 6 是RESTART_DET，bit 7 是MST_ACTIVITY。这个控制器里还有一个IC_ENABLE_STATUS寄存器，bit 0 是IC_EN，bit 1 是IC_DIS。

DWC 控制器判断总线的 Busy 状态，依据的是内部bus_active标志。这个标志在检测到 Start 条件时置位，在检测到 Stop 条件时清除。问题在于：当控制器被软件禁用（IC_ENABLE写 0）的时候，它仍然在监测总线。如果你在总线上刚好有 Start 条件产生了，但 Stop 条件没接收到（比如对端异常），那么就算控制器自己没有被使能，它的bus_active标志也会被置位。

等你重新使能控制器想发起传输时，发现IC_STATUS里的 Busy 位是 1，然后软件就死等——因为控制器认为总线上有其他主机在通信，它不能去抢总线。这个“我没发 Start，但总线上有 Start 条件”的诡异状态，就是 Busy 死锁的典型场景之一。

我写过不少关于中断设计的代码，这里必须提醒一下：如果你在中断服务函数里直接操作 I2C 寄存器，而不是只置标志位，那么风险非常高。中断的优先级如果不当，完全可能打断正在进行的 I2C 字节传输，导致控制器状态机卡死。另外，有的 SoC 会把 I2C 控制器的时钟单独做门控（Clock Gating），如果你在传输过程中把该外设的时钟关了，状态机也会锁死在中间状态。

3. 实战排障流程：从现象到根因的完整链路

3.1 第一步：确认 Busy 状态的真实来源

遇到 I2C 卡死，先别急着改代码。第一步是确认 Busy 标志是软件层的还是硬件层的。这个非常重要，因为软件层的 Busy 可能只是驱动自己维护的一个标志位，硬件层的 Busy 才是控制器状态机真正锁死。

我当时是在 Linux 环境下调试的，用的是i2c_designware驱动。这个驱动的i2c_dw_handle_tx_abort函数会处理传输中止情况，但它对 Busy 死锁的处理并没有做太多针对性设计。我通过devmem工具直接读取了寄存器地址，确认了问题是硬件层IC_STATUS寄存器的 Busy 位确实为 1。

如果你在 MCU 裸机环境下，操作更简单：直接读状态寄存器就行。比如 STM32 的 I2C 外设，I2C_ISR的 bit 15 是BUSY位；I2C_CR1的 bit 15 是SWRST（软件复位）。在确认BUSY=1且SDA=1, SCL=1（示波器看）但控制器还不退出 Busy 时，就说明不是总线电平问题，而是控制器内部锁死了。

这里有个关键点：必须用示波器同时看 SCL 和 SDA 两条线的电平状态。如果两条线都是高，说明总线物理上是空闲的，但控制器认为忙——这是软件/状态机问题；如果 SDA 被拉低，说明有设备把总线咬死了——这是物理层/从机问题。两条线都是高但控制器报忙，是最麻烦的那种，因为信号路径看起来完全正常，纯粹是控制器的内部状态锁死。

3.2 第二步：给控制器“松松骨”——软件复位与总线恢复序列

绝大多数情况下，控制器报忙但物理总线空闲时，可以通过让控制器重新初始化来恢复。但这个重新初始化不是简单地把I2C_ENABLE置 0 再置 1，因为 DWC 控制器的设计里，从使能到禁用需要等待IC_ENABLE_STATUS寄存器里的IC_EN位变成 0 才算真正完成。

我当时写的恢复序列大概是这样：

static int i2c_bus_recovery(struct dw_i2c_dev *dev) { u32 enable_status; int ret; /* 1. 禁用控制器 */ dw_writel(dev, 0, DW_IC_ENABLE); ret = readl_poll_timeout(dev->base + DW_IC_ENABLE_STATUS, enable_status, !(enable_status & DW_IC_ENABLE), 10, 20000); if (ret) { dev_err(dev->dev, "timed out waiting for controller disable\n"); return ret; } /* 2. 软件复位 DWC 控制器 */ dw_writel(dev, DW_IC_SWRST, DW_IC_SWRST); udelay(10); dw_writel(dev, 0, DW_IC_SWRST); /* 3. 延时等待复位完成 */ usleep_range(1000, 2000); /* 4. 重新初始化控制器 */ dw_writel(dev, 0, DW_IC_INTR_MASK); /* 这里继续按正常流程配置: 地址、速率、使能等 */ ... }

第 2 步里面有个坑：DWC 控制器的SWRST位写 1 触发复位，但这个位在复位完成后会自动清 0。如果你直接读回该位判断是否复位完成，会在某些芯片版本上读到不确定的值。实测下来，最稳妥的做法是先写 1，然后udelay(10)，再写 0，这样确保复位信号被正确锁存并释放。不同 SoC 对这个寄存器的实现略有差异，有的需要写 1 再写 0，有的只需要写 1。最好是查你所用芯片手册里关于这一段的时序说明。

如果是 STM32 那种 I2C 外设，恢复思路类似：先拉低 SCL 时钟 9 个周期（模拟一个完整的字节传输），然后发 Stop 条件，最后软复位外设。这个过程可以手动用 GPIO 模拟，也可以依赖某些 MCU 自带的超时检测。网上有大量关于“I2C Bus Recovery”的 GPIO 模拟代码，核心原理就是让从机状态机复位，释放 SDA 线。

3.3 第三步：硬件层面验证与抓波形

软件恢复做了，但没解决根本问题的话，就得回头查硬件了。我提供一个非常实用的验证顺序：

1. 用示波器（至少 100MHz 带宽）同时接 SCL 和 SDA，触发方式设为下降沿触发。
2. 在系统启动时就开始抓波形，持续抓，直到复现问题。
3. 抓到的波形重点看三个点：是否有完整的 Start 条件？SDA 有没有被拉低超过 1ms？SCL 上有没有超过 9 个时钟周期的连续方波？

如果看到 SDA 被拉死，先别怀疑控制器的状态机，十有八九是从机死锁或者上拉配置不对。可以做的排查方式有：把所有从机的 SDA 引脚断开，只保留上拉电阻，看 SDA 是否恢复高电平；如果恢复，逐个接回从机，找到咬死总线的那个设备。

如果看到波形是正常的、完整的，但控制器还是报 Busy，那问题就回到控制器本身，重点检查时钟源。有些 SoC 的 I2C 模块没有独立时钟或者时钟频率配置错误，会导致状态机跑飞。特别是在系统进入低功耗模式再唤醒后，I2C 外设的时钟有时不会被正确恢复。

3.4 实战案例：触摸屏 I2C 死锁的完整排障记录

我在调试电容触摸屏时遇到的死锁问题，根因很特殊，写出来给大家参考。

现象是这样的：系统跑 1 到 2 小时后，触摸屏偶发失灵。失灵后cat /proc/interrupts查看触摸屏的中断号，可以看到触摸屏的中断并没有频繁触发（说明不是中断风暴），但 I2C 总线访问超时。用i2cdetect扫描，总线上的设备全部消失或者返回错误。

我用示波器抓了一下午，终于抓到一次问题现场：SDA 线上出现了一个下降沿，但 SCL 没有对应的时钟，随后 SDA 又回到了高电平。这个下降沿持续了大约 30 微秒，对于 I2C 总线来说，这既不是合法的 Start 条件（因为 Start 要求在 SCL 高电平时 SDA 下降），也不是合法的数据信号（因为数据要在 SCL 低电平时变化）。这大概率是触摸屏芯片在某个状态下，SDA 引脚出现了异常的脉冲输出。

进一步排查发现，这个触摸屏芯片的中断输出引脚 INT 和 SDA 引脚在 PCB 布局上相邻，且布线距离较长。触摸屏的 INT 引脚在检测到触摸时会输出一个低电平脉冲，这个脉冲通过串扰耦合到了 SDA 线上。在 SDA 本来就处于高电平时，这个耦合噪声恰好形成了下降沿，控制器误判为 Start 条件，Busy 位置位。

最终处理方案分两层：硬件上，在 INT 引脚和 SDA 之间增加一个 33pF 的小电容做滤波，同时调整 INT 引脚的驱动强度；软件上，在 I2C 驱动里增加了 Busy 状态检测和自动恢复机制。这个案例说明一个很重要的事：排查 I2C 死锁问题，不能只盯着控制器和从机本身，周边信号耦合也是重要怀疑对象。

4. 一套可落地的 Busy 退出机制设计

4.1 裸机/RTOS 环境下的防御性编程

在裸机环境下调 I2C，我通常会做三件事来防止 Busy 死锁和快速恢复：

首先，所有 I2C 等待循环必须有超时。这是个铁律。我在代码审查时见过太多人写while (I2C_GetFlagStatus(I2Cx, I2C_FLAG_BUSY));这样的代码，看起来没啥问题，但一旦遇到异常，这里就是死循环。正确做法是：

uint32_t timeout = 10000; while (I2C_GetFlagStatus(I2Cx, I2C_FLAG_BUSY)) { if (--timeout == 0) { /* 超时处理 */ break; } }

其次，增加 Busy 状态自动恢复机制。在每次 I2C 传输开始前，先检查 Busy 标志，如果 Busy 但 SDA、SCL 都是高电平（用 GPIO 模式读取确认物理空闲），就自动执行一次软复位，恢复状态机：

int i2c_safe_transfer(struct i2c_msg *msg) { int ret; ret = i2c_busy_check_and_recover(); if (ret) return ret; ret = i2c_transfer_internal(msg); if (ret == -EBUSY) { i2c_busy_check_and_recover(); ret = i2c_transfer_internal(msg); /* 重试一次 */ } return ret; }

第三，初始化 I2C 时不要依赖上一帧的残余状态。上电初始化时，有些芯片 I2C 模块会因为之前的异常状态而无法工作，可以在初始化阶段主动把引脚切换到 GPIO 模式，手动拉 SCL 9 个周期（模拟时钟脉冲），然后切回复用功能。这段代码在主流 MCU 上都能跑，效果也不错。

4.2 Linux 内核环境下的 I2C 总线恢复机制

Linux 内核对 I2C 总线恢复已有官方方案，用i2c_gpio_recovery机制，它通过复用 SCL/SDA 引脚为 GPIO，手动产生时钟脉冲来复位从机。使用时需要在内核设备树里配置：

&i2c1 { status = "okay"; clock-frequency = <100000>; pinctrl-names = "default", "recovery"; pinctrl-0 = <&pinctrl_i2c1_default>; pinctrl-1 = <&pinctrl_i2c1_gpio>; i2c-scl = <&gpio 20 0>; i2c-sda = <&gpio 21 0>; i2c-gpio-delay-us = <5>; };

注意，pinctrl-names里的default和recovery与i2c-scl、i2c-sda属性是配套的。i2c-scl和i2c-sda属性声明了用于恢复的 GPIO 节点，而pinctrl-1指向的 recovery 引脚状态需要预先在 pinctrl 驱动里配置好，因为gpio_request_one会用到。

配置好之后，内核的i2c_adapter会注册一个recover_bus回调，当传输中止（-EAGAIN）且检测到超时或总线错误（-ETIMEDOUT、-EBUSY）时自动触发总线恢复。恢复过程是：先通过 GPIO 把 SCL 拉低，产生 9 个脉冲，然后释放 SCL、SDA，回读状态，再切回复用功能。这个机制对付“从机咬死 SDA”特别有用。

但这里有个我印象很深的坑：GPIO 恢复对主控状态机锁死不生效。如果控制器内部状态机已经乱了，GPIO 模拟波形并不能让控制器自己的状态机复位。这种情况下，只能靠驱动里做软复位或者调用i2c_put_adapter+i2c_get_adapter重新初始化。所以如果你的 DWC 控制器跑飞了，内核的recover_bus帮不了太多，还得在驱动层面补充。

4.3 针对 DWC 控制器的软复位补丁方案

我在针对 DWC 控制器做补丁时，走了不少弯路。最开始时我在i2c_dw_xfer函数里检测-EBUSY就调用__i2c_dw_disable+__i2c_dw_enable，结果发现中断状态没有清理干净，导致重新使能后中断风暴，内核日志刷屏。

正确做法是完整做三步：

static void i2c_dw_clear_stop_interrupt(struct dw_i2c_dev *dev) { u32 stat; stat = dw_readl(dev, DW_IC_INTR_STAT); if (stat & DW_IC_INTR_STOP_DET) dw_writel(dev, DW_IC_INTR_STOP_DET, DW_IC_CLR_INTR); } static int i2c_dw_recover_busy(struct dw_i2c_dev *dev) { u32 enable_status; int ret; /* 清掉残留的中断 */ i2c_dw_clear_stop_interrupt(dev); /* 禁用控制器，并等它真正停掉 */ dw_writel(dev, 0, DW_IC_ENABLE); ret = readl_poll_timeout(dev->base + DW_IC_ENABLE_STATUS, enable_status, !(enable_status & DW_IC_ENABLE), 10, 20000); if (ret) return ret; /* 复位 */ dw_writel(dev, DW_IC_SWRST, DW_IC_SWRST); udelay(10); dw_writel(dev, 0, DW_IC_SWRST); usleep_range(1000, 2000); return 0; }

补上这个函数之后，我在传输错误路径里加上了i2c_dw_recover_busy的调用，并且在重试前调用i2c_dw_disable+i2c_dw_init重新配置控制器参数（地址、速率、FIFO 阈值）。这套组合拳实测下来，触摸屏死锁后的恢复时间从原来的需要重启系统，缩短到了大约 2 毫秒，系统无感恢复。

5. 高频踩坑场景与排查速查表

5.1 常见问题与处理经验

排障经验积累多了，你会发现很多问题是有规律可循的。我整理了一些高频场景，每个都是实际踩过坑的：

SCL 或 SDA 被拉死导致 Busy 不恢复

这种情况示波器看过去，SDA 或者 SCL 有一根线电平恒为低。如果 SCL 被拉低，通常是某个从机在做 Clock Stretching，也就是它还没准备好接收数据，一直把时钟钳位住。处理方法是检查从机的供电是否稳定，或者看从机是不是处于异常状态需要复位。如果 SDA 被拉低，优先怀疑有从机在总线空闲时抢占总线，或者从机内部闩锁了。

同一条 I2C 总线挂了多个不同速率的设备

I2C 协议允许不同速率设备共存，因为它们会通过时钟同步机制自动降速。但如果其中一个从机在快速模式下需要 400kHz，另一个在标准模式下只支持 100kHz，高速设备一旦先发起通信，低速设备可能因为跟不上节奏而误判信号，产生虚假的 Start/Stop，进而干扰主控的状态机。解决方式是明确划分总线速率，如果实在混挂，加上总线隔离器（如 PCA9546）做物理隔离。

上拉电阻阻值配置不当导致信号边沿过缓

这个在低功耗板子上特别常见。为了省电，设计者把上拉电阻做到 10kΩ，甚至 47kΩ，再加上总线上的电容，上升沿就变得非常缓。示波器上看，信号波形不是跳变，而是弯弯的圆弧。这种波形会被 I2C 控制器的输入缓冲判成不确定状态，从而产生误触发。一般来说，100kHz 模式用 4.7kΩ 上拉，400kHz 模式用 2.2kΩ 上拉，具体还要根据总线电容修正。

内核里 I2C 驱动中断被频繁触发导致死锁

在 Linux 下如果 I2C 中断没有在驱动里正确屏蔽或者清理，就在错误中断里反复进入中断处理函数。如果中断处理函数里又尝试去操作 I2C 控制器，相当于嵌套调用了 I2C 的传输流程，状态机不死才怪。我在排查另一个项目时就遇过类似的问题：一个 GPIO 按键驱动的中断把 I2C 触屏的中断抢占了，导致触屏的寄存器读写卡在中间位置。解决方式是在中断服务函数里严格做到“只置标志位，不执行具体操作”，把 I2C 的实际处理放到线程或主循环去执行。

系统进入低功耗唤醒后 I2C 状态异常

低功耗场景下，I2C 外设的时钟门控如果在睡眠时没有被正确配置，唤醒后就会出问题。我遇到过的情况是：睡眠后 DWC I2C 控制器的时钟被关闭，唤醒后时钟恢复，但控制器内部状态机没有复位，导致 Busy 位永远置位。这种情况下，需要在唤醒流程里加一次完整的软复位操作，不能只重新配置寄存器。

5.2 问题排查速查表

这个表可以直接打印出来贴在工位上，排查问题的时候对照着看，能省不少时间。

5.3 一套完整的 Linux 下 I2C 排查命令清单

调试 I2C 问题，Linux 下的工具链非常有用。熟悉这些命令会让排查效率翻倍：

先用i2cdetect -l列出系统中的 I2C 总线。再用i2cdetect -y <bus号>扫描总线上的设备地址。正常情况下每个设备地址会显示为一个数字（hex 格式），如果某个地址显示UU，说明该地址被内核驱动占用，这也是有用的信息——说明这个设备已经被 driver probe 了。

i2cdump -y <bus> <addr>可以读取设备所有寄存器的值。i2cget -y <bus> <addr> <reg>读取指定寄存器。i2cset则是写寄存器。但注意，这几个命令会直接操作 i2c-dev 节点，如果你同时有驱动在用同一个设备，可能会产生竞争。可以在调试时先把对应设备的驱动卸载掉（如果可能的话）。

读 DWC 控制器的寄存器，我用devmem在读物理地址。比如：

# 查看 IC_STATUS 寄存器(地址偏移 0x0014) devmem 0xf00c0014 # 查看 IC_ENABLE_STATUS 寄存器(地址偏移 0x009C) devmem 0xf00c009c

IC_STATUS的 bit 0 是 ACTIVITY，bit 6 是 MST_ACTIVITY。如果 ACTIVITY=1 且 MST_ACTIVITY=0，说明控制器认为总线上有活动但不是自己发起的，这正是 Busy 死锁的一个典型寄存器特征。此时执行：

# 写 0 禁用控制器 devmem 0xf00c0080 32 0

然后立刻读回来确认IC_ENABLE_STATUS的 bit 0 变为 0，再重新初始化。但devmem只能应急，真实修复还是得在驱动里写逻辑。

6. 架构层面的思考与防御性设计

6.1 不要让 I2C 成为系统的单点故障

嵌入式系统里，I2C 经常挂载一些关键外设——触摸屏、PMIC、温度传感器、EEPROM、充电管理芯片等。一旦 I2C 总线锁死，这些外设全部失联，系统的使用体验会断崖式下降。很多产品在量产之后才暴露出 I2C 偶发死锁问题，往往是产品经受不住时间考验的最大隐患。

所以在架构设计阶段就要做好防御性设计，而不是等问题爆发了再去填坑。我总结了几条经验：

第一，凡是 I2C 访问外设的地方，必须有超时。超时之后不能只是抛个错误就完事，要有恢复策略。裸机环境用定时器或者循环计数做超时，Linux 环境用内核readx_poll_timeout或wait_for_completion_timeout。

第二，凡是做 I2C 传输，必须做返回值检查。不要只关心“数据有没有发完”，要关心“有没有返回 -ETIMEDOUT、-EBUSY、-EIO”。这些错误码处理策略不完全一样。

第三，驱动里对 I2C 外设的访问要设计成可重入的。同一时刻最好不要有两个线程同时去访问同一个外设，这会引发总线竞争。如果无法避免，需要加互斥锁或者用 I2C 控制器自带的仲裁机制。

6.2 不同硬件方案的 I2C 异常处理能力对比

选型时各家的硬件 I2C 实现差异很大，有些单片机自带的 I2C 外设没有完善的异常恢复机制，有些支持自动总线释放（比如 STM32H7 系列带有I2C_CR1.ANFEN、I2C_TIMINGR等配置），有的还能检测到 SDA 被拉低超时后自动复位。

我对比过几类常见方案：

如果你的项目对 I2C 可靠性要求极高（比如车载、医疗、工控），我的建议是：硬件 I2C + 软件兜底全都要，甚至可以考虑用 GPIO 软件模拟 I2C 作为冷备方案。用软件模拟虽然占 CPU，但好处是每个时序都自己掌控，永远不会“状态机跑飞”，因为根本没有状态机。代价是时序精度和 CPU 占用率需要权衡。

6.3 把 Busy 死锁当作一种常态看待

心态上要转变：在真实硬件环境中，I2C Busy 死锁不是“会不会发生”的问题，而是“什么时候发生、多久恢复”的问题。就算你的硬件设计非常完善，但在高温、高湿、强干扰、电源波动等极端环境下，I2C 依然可能出问题。优秀的嵌入式工程师不会把“总线永不锁死”作为设计目标，而是把“总线锁死后能否被快速检测、快速恢复、对系统影响最小”作为设计目标。

基于这个思路，我给自己的代码库加了一个 I2C 健康监控模块，核心逻辑很简单：每次 I2C 传输之后记录下来成功/失败次数、最近一次错误类型、错误时间戳。如果连续失败超过 5 次，就主动做一次总线重新初始化。如果重新初始化后还是失败，再升级到 GPIO 模拟模式作为兜底。这套机制在很多项目里帮了大忙，尤其是在量产后的现场问题排查中，日志里的错误计数和错误类型能直接告诉你问题出在哪一层。

7. 最后的实操心得

把整个排查过程走完，我心里比较有感触的一点是：I2C 问题排查的核心不是“多会看代码”，而是“对硬件行为和协议本质有足够的理解”。Busy 状态的成因从协议层面看一定是有 Start 条件没被 Stop 条件解除，但为什么会出现这种情况，原因可以千奇百怪。从物理层的信号波形、从机逻辑的异常、主控状态机的设计缺陷到电源噪声的耦合，每个环节都可能插一脚。

我个人的经验是，接到一个 I2C 死锁问题，先别急着写代码修复，先花时间做三件事：看波形、读寄存器、理清状态机。把这三件事做透了，问题基本就解决了一半。剩下的一半，就是写一套完整的恢复机制，并且反复做压力测试，确认它在极端情况下也能兜住。

另外，如果你在调试中遇到类似的“寄存器状态和物理信号对不上”的问题，我建议你养成一个习惯：动手之前先写一段脚本或命令，把现场的关键寄存器状态完整记录下来，包括时间戳和调用栈。这在复现偶发问题时非常有用，能帮你快速定位问题发生的上下文。很多偶发问题不是思路不对，是信息不够，导致一直在瞎猜。

最后再分享一个小技巧：I2C 总线恢复的时候，如果遇到“控制器已经软复位了，但重新初始化后第一次传输还是超时”的情况，试一下在复位后延时 2 毫秒再初始化。这个延时让芯片内部的电源域和时钟域完全稳定下来，很多莫名其妙的“复位不彻底”问题就消失了。这个坑我至少踩过两次，写出来给各位参考。