4. I2C总线调试：时钟拉伸、地址应答、总线锁死与多主机冲突

I2C总线，搞嵌入式的没人不认识它。两根线，一主多从，协议看着简单，但实际调起来，坑是真不少。时钟拉伸、地址无应答、总线莫名其妙锁死、两个主机抢线……这些我都遇到过，而且不止一次。

今天咱们就把这几个硬骨头啃下来。我会结合自己的调试经历，把每个问题的根因、现象、排查手段和修复方法，掰开揉碎了讲清楚。

4.1 时钟拉伸（Clock Stretching）——从机说“等等，我还没准备好”

时钟拉伸是从机的权利。当从机需要更多时间处理数据时，它会主动拉低SCL线，迫使主机进入等待状态。主机检测到SCL被拉低后，必须停止时钟输出，直到从机释放SCL。

现象：SCL线上出现一段异常的低电平，持续时间不定。主机这边表现为I2C传输超时，或者卡在某个字节的ACK阶段不动了。

根因分析：

• 从机处理速度慢：比如EEPROM在写操作期间，内部正在擦写，无法响应新的命令。
• 从机固件设计问题：某些从机芯片在接收数据后，需要执行内部任务，会主动拉伸时钟。
• 主机不支持时钟拉伸：很多MCU的硬件I2C外设默认不支持时钟拉伸，或者需要特殊配置才能响应。

调试步骤：

1. 用逻辑分析仪抓取SCL和SDA波形。重点看SCL低电平的持续时间。
2. 确认从机数据手册中关于时钟拉伸的说明。有些从机明确写了“最大拉伸时间”，比如50μs。
3. 检查主机I2C配置。以STM32为例，需要确认I2C_CR1寄存器中的NOSTRETCH位是否被置位。如果置位了，硬件会忽略时钟拉伸，直接导致通信失败。

解决方案：

• 如果使用硬件I2C，确保NOSTRETCH位为0（允许时钟拉伸）。
• 如果使用软件模拟I2C，在检测到SCL被拉低后，循环等待直到SCL变高，同时增加超时保护。
• 适当增加I2C总线的超时时间，建议设置为从机最大拉伸时间的2-3倍。

4.2 地址应答异常——从机“装死”怎么办？

主机发送从机地址后，等待一个ACK。如果从机没拉低SDA，那就是NACK。这是最常见的I2C故障之一。

现象：主机发送地址后，SDA在第9个时钟周期保持高电平。通信直接终止。

根因分析：

调试技巧：

• 先用示波器抓取主机发送的地址字节，确认地址位是否正确。很多新手会把7位地址左移一位当成8位地址发送，导致地址错误。
• 检查上拉电阻。I2C总线的上拉电阻一般在1kΩ到10kΩ之间。电阻太大，上升沿变缓；电阻太小，灌电流过大。
• 如果总线上有多个从机，可以逐个断开，缩小排查范围。

4.3 总线锁死恢复——SDA和SCL都被拉低，怎么办？

总线锁死是I2C调试中最让人头疼的问题之一。现象很明确：SCL和SDA都处于低电平，总线完全瘫痪。

为什么会锁死？

根本原因是某个设备错误地输出了低电平，并且没有释放总线。常见场景：

• 从机在传输过程中意外复位，输出状态不确定。
• 主机在传输未完成时被中断打断，导致SCL或SDA电平状态残留。
• 总线干扰导致设备误判，进入了错误状态。

恢复方法：

1. 硬件复位：给从机或主机硬件复位引脚一个低脉冲。这是最直接的方法。
2. 软件恢复序列：主机主动产生9个SCL时钟脉冲。在每一个时钟脉冲后，检查SDA是否被释放。如果SDA变高，说明从机退出了错误状态。
3. 重新初始化I2C外设：如果软件恢复序列无效，需要重新配置I2C的GPIO和寄存器。

void I2C_Bus_Recovery(void)
{
    // 1. 将SCL和SDA配置为开漏输出，并输出高电平
    GPIO_InitTypeDef GPIO_InitStruct = {0};
    GPIO_InitStruct.Pin = I2C_SCL_PIN | I2C_SDA_PIN;
    GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_OD;
    GPIO_InitStruct.Pull = GPIO_NOPULL;
    GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
    HAL_GPIO_Init(I2C_GPIO_PORT, &GPIO_InitStruct);
    
    HAL_GPIO_WritePin(I2C_GPIO_PORT, I2C_SCL_PIN | I2C_SDA_PIN, GPIO_PIN_SET);
    
    // 2. 产生9个SCL时钟脉冲
    for (int i = 0; i < 9; i++)
    {
        HAL_GPIO_WritePin(I2C_GPIO_PORT, I2C_SCL_PIN, GPIO_PIN_RESET);
        delay_us(5);
        HAL_GPIO_WritePin(I2C_GPIO_PORT, I2C_SCL_PIN, GPIO_PIN_SET);
        delay_us(5);
        
        // 检查SDA是否变高
        if (HAL_GPIO_ReadPin(I2C_GPIO_PORT, I2C_SDA_PIN) == GPIO_PIN_SET)
        {
            break;  // 从机已释放总线
        }
    }
    
    // 3. 产生一个STOP条件
    HAL_GPIO_WritePin(I2C_GPIO_PORT, I2C_SDA_PIN, GPIO_PIN_RESET);
    delay_us(5);
    HAL_GPIO_WritePin(I2C_GPIO_PORT, I2C_SCL_PIN, GPIO_PIN_SET);
    delay_us(5);
    HAL_GPIO_WritePin(I2C_GPIO_PORT, I2C_SDA_PIN, GPIO_PIN_SET);
    delay_us(5);
    
    // 4. 重新初始化I2C外设
    MX_I2C1_Init();
}

4.4 多主机冲突处理——两个主机抢线，谁说了算？

多主机模式在STM32中并不常用，但一旦用上，冲突处理就是必修课。I2C协议本身支持多主机，通过仲裁机制解决冲突。

仲裁机制：

当两个主机同时尝试控制总线时，它们都会输出自己的数据。如果某个主机输出的SDA电平与总线实际电平不一致，它就失去了仲裁权，必须立即释放SDA和SCL，转为从机模式。

常见问题：

• 仲裁丢失后未正确处理：主机在失去仲裁后，没有及时释放总线，导致数据冲突。
• 总线空闲检测不严谨：主机在检测到总线空闲前就启动了传输，导致冲突。
• 中断优先级问题：一个主机的I2C中断被更高优先级的中断打断，导致时序错乱。

调试方法：

1. 用逻辑分析仪同时抓取两个主机的SCL和SDA信号。观察仲裁发生时的波形。
2. 检查主机代码中是否正确处理了仲裁丢失中断（ARLO）。在STM32中，需要检查I2C_SR1寄存器的ARLO位。
3. 确认两个主机的I2C时钟频率是否一致。频率不一致会导致仲裁失败。

多主机设计建议：

• 尽量使用软件模拟I2C实现多主机，这样对仲裁逻辑的控制更灵活。
• 如果使用硬件I2C，务必开启仲裁丢失中断，并在中断服务函数中做总线释放和重试处理。
• 在发送START条件前，增加总线空闲检测。检测到SCL和SDA都为高电平超过一定时间（建议4.7μs以上），再启动传输。

4.5 本章知识结构图

下面这张图总结了I2C调试的四个核心问题及其关联关系。你可以把它当作调试时的快速参考。

4.6 总结与调试清单

I2C调试，说白了就是跟时序和状态机打交道。每次遇到问题，先问自己三个问题：

• 波形对不对？——用逻辑分析仪看。
• 配置对不对？——核对数据手册和寄存器。
• 保护够不够？——超时、恢复、重试机制是否完善。

下面是我个人整理的I2C调试清单，每次遇到问题我都会过一遍：