企业官网建设流程全解析

I2C 总线出问题的时候，最让人头疼的不是"完全没反应"，而是"时好时坏"——设备偶尔能读到数据，偶尔 NACK，偶尔整个总线被拉死。很多人的第一反应是换器件、换板子，但真正高效的排查路径应该是从最便宜的工具开始，逐层缩小范围。万用表能帮你确认静态电平是否正常，示波器能让你看到时序和毛刺，逻辑分析仪能解码出 ACK 到底有没有出现。这篇文章就把这条排查链路完整拆开，从最基础的电压测量讲到 ACK 位的判定，每一步都告诉你为什么这么做、看到什么现象对应什么问题。

1. 先搞清楚 I2C 的电气本质再动手

1.1 开漏输出与上拉电阻的关系

I2C 的 SDA 和 SCL 都是开漏（open-drain）结构，这意味着器件只能把线拉低，不能主动拉高。高电平完全靠上拉电阻把线拉到 VCC。这个特性决定了几个关键事实：总线上任何一个器件把线拉低，整条线就是低；只有所有器件都释放总线，线才会被上拉电阻拉高。

上拉电阻的取值不是随便选的。它和总线电容构成一个 RC 充电回路，上升时间大约为：

t_r ≈ 0.847 × R_pullup × C_bus

标准模式（100kHz）要求上升时间小于 1000ns，快速模式（400kHz）要求小于 300ns。假设你的总线电容是 200pF，用 4.7kΩ 上拉，上升时间约 0.847 × 4700 × 200e-12 ≈ 796ns，勉强满足标准模式但快速模式就不够了。这就是为什么很多高速 I2C 场景要用 2.2kΩ 甚至 1.5kΩ 上拉。

但上拉电阻也不能太小，否则器件拉低时灌入的电流会超过它的承受能力。大部分 I2C 器件的低电平灌电流能力在 3mA 左右，VCC 为 3.3V 时，最小上拉电阻约为 3.3V / 3mA ≈ 1.1kΩ。所以 1.5kΩ 到 10kΩ 是常见范围，具体要看总线电容和速率。

注意：很多开发板上的 I2C 上拉电阻是 10kΩ，这个值在短距离、低速场景能用，但一旦接上多个从机或者排线较长，上升沿就会变得很缓，导致通信不稳定。

1.2 为什么静态测量就能排除一半问题

在通电但总线空闲的状态下，SDA 和 SCL 都应该是高电平（等于 VCC）。如果你用万用表测到某条线是低电平或者中间电平，那说明有器件在持续拉低总线，或者上拉电阻缺失/损坏。这个判断不需要任何复杂设备，一个万用表就够了。

常见的静态异常包括：

万用表测量的时候要注意：必须在总线空闲时测。如果主控正在不断发起通信，你看到的电压是平均值，不代表真实电平。可以先把主控的 I2C 外设关掉，或者让程序停在初始化之前再测。

2. 万用表能查到的和查不到的

2.1 通断与短路排查

在断电状态下，用万用表的通断档可以快速确认几件事：SDA 和 SCL 之间是否短路、每条线对 VCC 和对 GND 是否短路。正常的 I2C 总线，SDA 对 VCC 应该有上拉电阻的阻值（几 kΩ），SDA 对 GND 应该是开路或者很大的阻值。

如果测到 SDA 对 GND 只有几欧姆，那基本可以确定有器件击穿或者焊接短路。这种情况在手工焊接的板子上特别常见，尤其是 QFN 封装的传感器，引脚间距小，很容易连锡。

我自己的习惯是：拿到一块新板子，先不上电，用万用表把 I2C 相关的几个测试点全部量一遍。SDA-SCL 之间、SDA-VCC、SDA-GND、SCL-VCC、SCL-GND，五个阻值记录下来。正常的话应该是：

• SDA-SCL：开路或很大
• SDA-VCC：等于上拉电阻值
• SDA-GND：开路或很大
• SCL-VCC：等于上拉电阻值
• SCL-GND：开路或很大

只要有一个不对，先解决硬件问题再谈软件。

2.2 万用表测动态信号的局限

很多人想用万用表测 I2C 通信时的电压变化，看到数字跳动就以为在通信。这个判断非常不可靠。万用表的采样率通常只有几 Hz 到几十 Hz，而 I2C 的时钟是 100kHz 或 400kHz，万用表看到的只是随机采样的平均值。

更麻烦的是，万用表的输入电容和引线电感会加载到总线上，可能让本来勉强能通信的总线直接失效。所以万用表只适合静态测量，不适合判断通信是否正常。要判断通信，必须上示波器或者逻辑分析仪。

提示：如果你只有万用表，可以用它测 SDA/SCL 的平均电压。空闲时应该是 VCC，通信时会在 VCC 和某个中间值之间。但这个只能作为"有没有在动"的粗略判断，不能作为"通信是否成功"的依据。

3. 示波器上看什么才算有效信息

3.1 探头选择和接地处理

用示波器测 I2C，第一个坑就是探头接地。很多人用探头自带的鳄鱼夹接地，引线太长，测出来的波形全是振铃和过冲。正确的做法是用探头自带的弹簧地针，直接顶在板子上的 GND 测试点，尽量缩短接地回路。

探头建议用 10:1 无源探头，带宽至少 100MHz。虽然 I2C 本身速率不高，但你要看的是上升沿和毛刺，带宽不够会把毛刺滤掉，反而看不到问题。输入耦合选 DC，因为你要看的是绝对电平。

触发设置很关键。用 SCL 或者 SDA 的下降沿触发，触发电平设在 VCC/2 左右。如果总线完全没动静，可以用"自动"触发模式先看看有没有信号，再切回"正常"模式抓细节。

3.2 上升沿、电平和毛刺的判读

抓到波形之后，重点看这几个方面：

上升沿时间。如果上升沿明显是圆弧形，说明上拉电阻太大或者总线电容太大。标准模式要求上升时间小于 1000ns，快速模式小于 300ns。测量方法是从 0.3×VCC 到 0.7×VCC 的时间。

高电平幅值。正常应该接近 VCC。如果只有 2V 左右（VCC 是 3.3V），说明上拉电阻和某个器件的漏电流形成了分压，或者有器件在弱拉低。

低电平幅值。正常应该接近 0V。如果低电平有 0.5V 以上，说明器件拉低能力不足，或者地线回路有问题。

毛刺。在 SCL 或 SDA 的边沿上如果有窄脉冲，可能是串扰或者反射。这种毛刺如果被从机误认为是时钟沿，就会导致数据错位。

我遇到过一个典型案例：一块板子上 I2C 时好时坏，示波器看波形发现 SCL 上升沿有大约 50ns 的振铃，幅度达到 1V。后来发现是排线太长，而且 SCL 和一根 PWM 信号线并排走。把排线缩短、分开走线之后问题消失。

3.3 用示波器判断总线死锁

总线死锁是 I2C 最常见的问题之一。现象是 SDA 被某个从机持续拉低，主机无法发起新的通信。用示波器可以清楚看到：SCL 在正常翻转，但 SDA 一直是低电平。

死锁的常见原因是主从复位不同步。比如从机在发送 ACK 的时候主机突然复位，从机还在等下一个时钟，而主机已经重新初始化了。这时候从机可能把 SDA 拉低等待时钟，但主机不发时钟，就卡住了。

解决办法是主机在初始化 I2C 之前，先手动发送 9 个时钟脉冲，让从机把剩余的数据位发完，然后发送 STOP 条件。这个操作在很多 MCU 的 I2C 外设里没有现成功能，需要用 GPIO 模拟。

// 用 GPIO 模拟时钟脉冲解除 I2C 死锁 void i2c_bus_recovery(void) { gpio_set_mode(SCL_PIN, OUTPUT_OD); gpio_set_mode(SDA_PIN, INPUT); for (int i = 0; i < 9; i++) { gpio_write(SCL_PIN, 0); delay_us(5); gpio_write(SCL_PIN, 1); delay_us(5); } // 发送 STOP 条件 gpio_set_mode(SDA_PIN, OUTPUT_OD); gpio_write(SDA_PIN, 0); delay_us(5); gpio_write(SCL_PIN, 1); delay_us(5); gpio_write(SDA_PIN, 1); delay_us(5); }

这段代码的逻辑是：先让 SCL 翻转 9 次，把从机可能卡住的位全部时钟出去，然后手动构造一个 STOP 条件（SCL 高时 SDA 从低变高），让总线回到空闲状态。

4. ACK 位到底怎么判定

4.1 ACK 的时序位置

I2C 每传输 8 个数据位之后，第 9 个时钟周期是 ACK/NACK 位。发送方在第 9 个时钟的低电平期间释放 SDA，接收方如果正确接收，就在这个时钟周期把 SDA 拉低，表示 ACK；如果不拉低，就是 NACK。

用示波器看 ACK，需要同时抓 SCL 和 SDA，然后数时钟。第 9 个 SCL 上升沿时，如果 SDA 是低电平，就是 ACK；如果是高电平，就是 NACK。

实际操作中，建议用示波器的"单次触发"模式，触发条件设为 SDA 下降沿，然后展开波形数时钟。或者用逻辑分析仪直接解码，省去数时钟的麻烦。

4.2 用逻辑分析仪解码 ACK

逻辑分析仪是排查 I2C 最顺手的工具。它能把 SDA 和 SCL 的波形直接解码成地址、数据、ACK/NACK，不需要你手动数时钟。常见的逻辑分析仪配合开源软件就能用，采样率建议至少 24MHz，对于 400kHz 的 I2C 来说足够。

解码之后，你会看到类似这样的输出：

Start Address: 0x68 [Write] ACK Data: 0x00 ACK Data: 0x75 ACK Stop

如果某个字节后面显示 NACK，说明从机没有正确接收。可能的原因包括：从机地址不对、从机没有上电、从机忙、从机损坏。

注意：有些逻辑分析仪的软件会把"地址+读写位"合并显示，有些会分开。看的时候要确认一下，避免误判地址。

4.3 NACK 的几种典型场景

NACK 不一定是坏事，要看出现在哪个位置：

地址字节后 NACK：从机没有响应。检查从机地址是否正确（注意 7 位地址和 8 位地址的区别）、从机是否上电、从机是否在复位状态。

数据字节后 NACK（写操作）：从机接收到了地址但拒绝接收数据。可能是从机寄存器地址越界，或者从机内部缓冲区满。

数据字节后 NACK（读操作）：这是正常的。主机在读最后一个字节之后，会主动发送 NACK，告诉从机"我读完了"，然后发送 STOP。所以读操作的最后一个字节后面出现 NACK 是正确的。

我见过很多人把读操作最后的 NACK 当成故障来查，浪费了很多时间。记住：读操作的最后一个字节，主机必须发 NACK，这是协议规定的。

5. 从波形到根因的完整排查链路

5.1 分层排查的思路

I2C 排查最忌讳的就是一上来就改代码。正确的顺序是从物理层往上查：

1. 静态电平：断电测通断，上电测空闲电平
2. 动态波形：示波器看上升沿、幅值、毛刺
3. 协议解码：逻辑分析仪看地址、数据、ACK
4. 软件配置：时钟频率、地址、寄存器配置
5. 从机状态：从机是否复位、是否忙、是否损坏

每一层确认没问题再往上一层查。这样能避免在软件层浪费时间，而问题其实在硬件层。

5.2 一个真实的排查案例

之前调试一个 GT911 触摸屏，I2C 地址是 0x5D 和 0x14 二选一，取决于复位时序。现象是主机能读到地址 ACK，但读数据全是 0xFF。

排查过程：

第一步，万用表测静态电平，SDA 和 SCL 都是 3.3V，正常。

第二步，示波器看波形，上升沿约 400ns，在 400kHz 下勉强够用，但有一点振铃。暂时不认为是根因。

第三步，逻辑分析仪解码，发现地址 0x5D 有 ACK，但读寄存器时返回 0xFF。0xFF 通常意味着从机没有真正驱动数据线，或者寄存器地址不对。

第四步，查 GT911 手册，发现复位时序决定了 I2C 地址。如果复位时 INT 引脚为低，地址是 0x5D；如果 INT 为高，地址是 0x14。我们的硬件上 INT 引脚悬空，导致地址不确定。

第五步，把 INT 引脚加上拉电阻，确保复位时为高，地址固定为 0x14。问题解决。

这个案例说明：ACK 正常不代表通信正常。从机可能响应了地址，但内部状态不对，返回的数据就是无效的。

5.3 常见问题速查表

6. 几个容易被忽略的细节

6.1 电平转换电路的影响

很多系统里主控是 3.3V，而从机是 5V，中间需要电平转换。常见的电平转换方案有 MOS 管方案和专用芯片方案。MOS 管方案在 I2C 上有个问题：当一侧拉低时，另一侧通过体二极管被拉低，但上升时依赖上拉电阻，如果两侧上拉电阻都比较大，上升沿会变得更缓。

我实测过，用 2N7002 做电平转换，两侧各 4.7kΩ 上拉，400kHz 下上升沿达到 600ns 以上，通信开始出错。把上拉改成 2.2kΩ 之后恢复正常。所以加了电平转换之后，上拉电阻要重新计算，不能照搬原来的值。

6.2 多从机场景的电容累积

每增加一个从机，总线电容就增加一些。PCB 走线大约每厘米 1-2pF，器件引脚大约 5-10pF，排线每厘米可能 10pF 以上。如果挂了 8 个从机，加上排线，总线电容很容易超过 400pF，这是 I2C 规范的上限。

超过之后，上升沿会明显变缓，通信距离和速率都要降。解决办法是减小上拉电阻，或者用 I2C 多路复用器把总线分段，每段单独挂从机。

6.3 软件 I2C 和硬件 I2C 的差异

软件 I2C 用 GPIO 模拟时序，灵活性高，但时序精度受中断影响。如果系统里有高优先级中断，软件 I2C 的时钟可能会被拉长，导致从机超时。

硬件 I2C 由外设自动产生时序，精度高，但配置复杂，出问题时不好调试。我的经验是：调试阶段先用软件 I2C 确认从机能正常工作，再切到硬件 I2C 优化性能。这样能把硬件问题和软件问题分开。

6.4 上电顺序和复位时序

有些从机对电源和信号的上电顺序有要求。比如某些传感器要求 VCC 先上，然后 SDA/SCL 才能有电平，否则会通过 ESD 保护二极管漏电，导致总线异常。

还有的从机需要特定的复位时序，比如复位引脚拉低一定时间，然后在特定引脚上产生特定电平来选地址。这些细节在手册里通常写得很清楚，但容易被忽略。

提示：调试新器件时，先把手册里的"Power-Up Sequence"和"Reset Timing"两节仔细看一遍，能避免很多莫名其妙的问题。

7. 工具选型与实战建议

7.1 万用表、示波器、逻辑分析仪怎么选

三种工具各有定位，不是替代关系：

• 万用表：查通断、查静态电平、查短路。几十块钱的够用。
• 示波器：看波形质量、上升沿、毛刺、死锁。建议带宽 100MHz 以上，双通道。
• 逻辑分析仪：解码协议、看 ACK、看数据。几十块钱的 8 通道够用。

如果预算有限，优先级是：万用表 > 逻辑分析仪 > 示波器。因为大部分 I2C 问题通过静态测量和协议解码就能定位，示波器主要用于排查信号完整性问题。

7.2 抓波形的几个实用技巧

用单次触发抓偶发问题。时好时坏的问题最难查，用单次触发模式，设置好触发条件，让设备反复运行，抓到异常波形后自动停止。

双通道对比 SCL 和 SDA。单独看一条线很难判断问题，两条线一起看才能确定时序关系。

用余辉模式看抖动。如果波形有抖动，用余辉模式累积多次波形，能看出抖动的范围和规律。

保存波形供后续分析。很多示波器支持保存波形到 U 盘，抓到的异常波形保存下来，方便慢慢分析或者对比。

7.3 代码层面的防御性设计

硬件排查完之后，软件层面也要做一些防御：

// I2C 读写超时保护 #define I2C_TIMEOUT_MS 100 int i2c_write_with_timeout(uint8_t addr, uint8_t reg, uint8_t data) { uint32_t start = get_tick_ms(); while (i2c_is_busy()) { if (get_tick_ms() - start > I2C_TIMEOUT_MS) { i2c_bus_recovery(); // 超时后尝试恢复总线 return -1; } } // 正常写入流程 return i2c_write(addr, reg, data); }

这段代码的核心是：任何 I2C 操作都要有超时。没有超时保护的 I2C 代码，一旦总线死锁，整个系统就卡住了。加上超时和恢复机制之后，即使偶尔死锁也能自动恢复。

另外，初始化的时候建议先做一次总线恢复，确保总线处于空闲状态再开始通信。这个习惯能避免很多上电时的偶发问题。

7.4 关于 ACK 的一个常见误解

最后说一个很多人搞混的点：ACK 是接收方发的，不是发送方发的。主机写数据时，ACK 由从机发；主机读数据时，ACK 由主机发。所以看波形的时候，要明确当前是谁在发送、谁在接收。

在读操作的最后一个字节，主机发 NACK，这是告诉从机"不要再发了"。如果主机错误地发了 ACK，从机会继续发送下一个字节，导致数据错位。这个细节在写 I2C 驱动的时候特别容易出错，尤其是用 GPIO 模拟的时候。

我在实际项目中养成的习惯是：每次调试新的 I2C 器件，先用逻辑分析仪抓一次完整的读写时序，确认地址、寄存器、数据、ACK 都对得上，再开始写驱动代码。这样能把协议层的问题提前排除，写代码的时候只需要关注业务逻辑。踩过几次坑之后你会发现，I2C 的问题百分之八十都能通过"静态测量 + 协议解码"定位，剩下的百分之二十才需要示波器深入分析信号完整性。工具不在多，在于用对顺序。