企业官网建设流程全解析

I2C 总线只有两根线，看起来简单得不行，但真到了板子不通信的时候，很多人第一反应是拿万用表量电压，量完发现 SDA 和 SCL 都是 3.3V，然后就开始怀疑人生。我见过太多人卡在这一步，包括我自己刚入行那会儿，对着一个 EEPROM 死活读不出数据，折腾了一整天才发现是上拉电阻焊成了 10k 而总线电容又太大，边沿缓得示波器都快看不见了。所以这篇东西不讲教科书上的 I2C 协议定义，那些你随便搜都有，我重点讲的是：当你面对一块不通信的板子，手头只有万用表、示波器、逻辑分析仪这些工具时，到底按什么顺序去测、每一步看什么、看到什么现象对应什么问题。这套排查流程是我这些年做硬件调试和嵌入式开发攒下来的，从最粗糙的万用表静态测量，到示波器抓时序看 ACK，再到 i2cdetect 这类工具软件层面的验证，基本覆盖了 I2C 通信故障的绝大多数场景。

1. 先搞清楚 I2C 到底在测什么

1.1 两根线的物理本质与常见误解

I2C 的 SDA 和 SCL 都是开漏输出结构，这意味着任何一个设备都只能把线拉低，不能主动拉高。线要变高，靠的是上拉电阻把电平拽上去。这个结构决定了几个非常关键的测试特征：第一，空闲状态下两根线都应该是高电平，如果你量到某根线是低电平，那说明有设备在拽着它不放，要么是在通信，要么是某个芯片挂了；第二，你不能用万用表的通断档去测 SDA 或 SCL 对地是否短路，因为开漏管脚在芯片内部本来就可能呈现低阻态，正确的做法是断电测对地阻值，上电测电压；第三，很多人以为 I2C 是推挽输出，拿万用表量到 1.6V 左右就以为坏了，其实那可能是总线正在通信，万用表的采样率根本跟不上 I2C 的速率，它显示的是一个平均值。

我刚开始做硬件的时候，有个项目用的是 STM32 加 BH1750 光照传感器，原理图检查了三遍没问题，PCB 也看不出短路，但 i2cdetect 就是扫不到设备。拿万用表一量，SCL 是 3.3V，SDA 是 1.8V 左右。当时第一反应是 SDA 被拉低了，但换了个传感器还是这样。后来拿示波器一看，SDA 上有一串很规律的脉冲，频率大概 100kHz，说明主机在发时钟和数据，但从机根本没应答。问题出在 BH1750 的地址引脚接错了，ADDR 脚悬空导致地址不确定。这个案例告诉我一个道理：万用表只能给你一个静态的、平均化的印象，它无法告诉你总线上有没有数据在跑，也无法告诉你 ACK 有没有出现。

1.2 万用表、示波器、逻辑分析仪各自的能力边界

在动手之前，你得清楚每样工具能干什么、不能干什么。万用表最擅长的是测静态电平、测上拉电阻阻值、测供电电压、断电测短路。它的致命弱点是采样率太低，对于 100kHz 甚至 400kHz 的 I2C 信号，它只能显示一个平均电压，你看到 1.6V 不代表信号有问题，你看到 3.3V 也不代表通信正常。示波器能看模拟波形，能测上升沿时间、能看毛刺、能测电平幅度，但它的存储深度有限，抓长帧容易丢数据，而且触发设置不对的话根本抓不到想要的帧。逻辑分析仪则是协议层面的利器，它能直接解码出地址、数据、ACK/NACK，但它看不到模拟特性，比如上升沿太缓导致从机采样错误这种情况，逻辑分析仪可能显示一切正常，但实际芯片就是收不到。

我个人的习惯是：先万用表做静态检查，排除供电和短路问题；然后示波器看波形质量和是否有 ACK 位；最后逻辑分析仪做协议解码，确认地址和数据内容。这个顺序不能反，因为如果你连供电都没确认就上逻辑分析仪，很可能白忙活一场。

1.3 排查前必须确认的硬件前提

在开始任何测量之前，有几件事必须先确认，否则后面的测量都没有意义。第一，所有 I2C 设备的供电是否正常，用万用表量每个芯片的 VCC 脚，确保在规格范围内，比如 3.3V 设备不能低于 3.0V；第二，上拉电阻是否焊接且阻值合理，常见的是 4.7k 到 10k，高速模式下可能用 2.2k 甚至 1k，但阻值太小会增加功耗，太大会导致上升沿变缓；第三，总线上所有设备的地址是否冲突，比如两个 EEPROM 都接成 0x50，那肯定通信失败；第四，是否有设备在通信过程中复位或掉电，导致总线被拉死。

注意：如果你用的是模块化的开发板，比如正点原子或者常见的传感器模块，很多模块自带上拉电阻，这时候你主板上再焊一组上拉，并联后阻值会变小，可能导致上升沿过快产生过冲，也可能导致某些芯片驱动能力不足。我遇到过一块 SSD1306 OLED 模块，模块上已经有 10k 上拉，主板上又焊了 4.7k，结果并联后约 3.2k，通信距离短的时候没问题，但线拉长到 20cm 后就开始随机出错。

2. 万用表阶段：静态测量能排除哪些低级问题

2.1 断电测对地阻值：找出硬短路

拿到一块不通信的板子，第一步一定是断电，用万用表的二极管档或者电阻档测 SDA 对地、SCL 对地的阻值。正常的 I2C 总线，在断电状态下，由于芯片内部 ESD 保护二极管的存在，你测到的阻值应该在几百欧到几千欧之间，具体取决于芯片和上拉电阻。如果你测到接近 0 欧，那基本可以确定有短路，可能是焊接桥接、芯片击穿或者 PCB 内部短路。这时候你需要逐个断开总线上的设备，直到找到短路源。

我踩过的一个坑是：一块四层板，SDA 走线在内层，表面看不出来，但过孔处有锡珠导致对地短路。万用表测出来 2 欧，但肉眼完全看不到。后来用热风枪把那个区域的芯片吹下来才发现过孔处有锡。所以如果你测到短路，不要只盯着芯片，PCB 的过孔、焊盘、连接器都要查。

2.2 上电测静态电平：判断总线是否被拉死

确认没有硬短路后，上电但不启动通信，用万用表测 SDA 和 SCL 对地的电压。正常情况下，两根线都应该是高电平，接近 VCC。如果某根线是低电平，说明有设备在持续拉低它。常见原因有几个：一是某个芯片的 I2C 引脚配置成了推挽输出且输出低，这种情况在 STM32 的 GPIO 初始化错误时很常见；二是某个芯片处于复位状态但 I2C 引脚漏电；三是总线电容太大加上上拉电阻太大，导致上升沿太慢，万用表显示一个中间值。

这里有个细节：万用表的内阻一般是 10M 欧，它本身不会对总线造成明显负载，但如果你用指针式万用表，内阻可能只有几十千欧，会影响测量结果。所以测 I2C 电平最好用数字万用表，而且不要用电流档去测，电流档的内阻很小，相当于把总线短路了。

2.3 测上拉电阻的实际阻值：别只看原理图

原理图上标的是 4.7k，不代表实际焊的就是 4.7k。我见过太多因为贴片电阻看错丝印或者料盘混料导致的问题。用万用表直接测上拉电阻两端的阻值，注意要断电测，而且要把总线上的设备断开或者确保它们不会影响测量。如果测出来是 0 欧或者无穷大，那问题就很明显了。另外，如果你用的是排阻，要确认公共端接的是 VCC 而不是 GND，我见过有人把排阻的公共端接地，结果上拉变成了下拉，总线永远起不来。

还有一个容易被忽略的点：有些芯片的 I2C 引脚内部有弱上拉，比如某些型号的 EEPROM，内部上拉大概 100k 左右。如果你外部没有上拉，只靠内部上拉，在短距离、低速下可能勉强能通信，但一旦线长增加或者速率提高，就会出错。所以不要依赖内部上拉，外部该焊的还是要焊。

2.4 万用表阶段的典型误判与避坑

万用表阶段最容易犯的错误就是把动态信号当成静态电平来判断。比如总线正在通信时，SDA 上有一串数据，万用表显示 1.6V，你以为是电平异常，其实只是平均值。另一个错误是用通断档测 SDA 和 SCL 之间是否短路，由于芯片内部结构，这两根线之间可能存在几十千欧的阻值，通断档可能会响，但这不一定是故障。

我的建议是：万用表阶段只做三件事——断电测对地阻值、上电测静态电平、测上拉电阻阻值。这三件事做完，如果都没问题，就不要再纠结万用表了，直接上示波器。万用表能告诉你的信息就这么多，再测下去也是浪费时间。

3. 示波器阶段：从波形质量到 ACK 位的深度观察

3.1 示波器探头连接与触发设置

用示波器测 I2C，第一步是正确连接探头。如果你用的是双通道示波器，CH1 接 SCL，CH2 接 SDA，两个探头的接地夹都要接到板子的 GND，而且尽量接在同一点，避免地环路引入噪声。探头的衰减比要设对，如果是 10X 探头，示波器上也要设成 10X，否则电压读数会差十倍。触发方式建议用边沿触发，触发源选 SCL 的下降沿或者 SDA 的下降沿，触发电平设在 VCC 的一半左右，比如 3.3V 系统就设 1.65V。

如果你用的是力科或者鼎阳这类支持协议解码的示波器，可以直接打开 I2C 解码功能，设置好地址位宽和时钟速率，示波器会自动把波形翻译成地址和数据。但要注意，协议解码依赖正确的触发电平，如果电平设得不对，解码结果会乱七八糟。我一般先用边沿触发抓到稳定的波形，再打开解码确认。

3.2 看上升沿时间：最容易被忽略的模拟问题

I2C 的上升沿时间是由上拉电阻和总线电容共同决定的，公式是 t_r ≈ 0.847 × R_pullup × C_bus。对于标准模式 100kHz，上升沿时间不能超过 1000ns；快速模式 400kHz，不能超过 300ns。如果你用 10k 上拉，总线电容 200pF，算下来 t_r ≈ 0.847 × 10000 × 200e-12 ≈ 1.69us，已经超过了标准模式的上限。这时候示波器上会看到上升沿非常缓，像一个斜坡，从机可能在电平还没达到阈值的时候就已经采样了，导致误判。

我实测过一个案例：一块板子用 10k 上拉，总线挂了四个传感器，线长 15cm，示波器测上升沿大概 1.2us，100kHz 通信时偶尔出错，降到 50kHz 就正常。后来把上拉改成 4.7k，上升沿降到 600ns 左右，100kHz 稳定运行。所以如果你看到上升沿明显是个斜坡而不是陡峭的边沿，优先考虑减小上拉电阻或者缩短总线长度。

3.3 抓 ACK 位：判断从机是否应答

ACK 位是 I2C 通信中最关键的信号之一。主机发送完 8 位地址或数据后，会在第 9 个时钟周期释放 SDA，如果从机存在且准备好，它会把 SDA 拉低，这就是 ACK；如果从机不存在或忙，SDA 保持高电平，这就是 NACK。用示波器抓 ACK 的方法是：触发在 SCL 的下降沿，观察第 9 个时钟周期 SDA 的电平。如果 SDA 在这个周期内是低电平，说明有 ACK；如果是高电平，说明没有从机应答。

这里有个坑：有些示波器的存储深度不够，抓长帧的时候会丢掉后面的数据，导致你看不到 ACK。这时候可以缩短触发位置，把触发点设在帧的开头，然后调整水平时基，让整个帧都在屏幕上。另外，如果总线上有多个从机，你需要确认是哪个从机在应答，这时候逻辑分析仪比示波器更方便。

3.4 示波器阶段的常见波形异常与对应问题

这个表格是我在实际调试中总结的，基本上覆盖了示波器上能看到的典型异常。如果你遇到的波形不在这个表里，那可能是更复杂的问题，比如多个主机竞争或者从机时钟拉伸，这些需要结合协议解码来进一步分析。

4. 逻辑分析仪与软件工具：协议层的最终确认

4.1 i2cdetect 的使用与结果解读

在 Linux 系统下，i2cdetect 是最常用的 I2C 扫描工具。用法很简单：先确认 I2C 适配器编号，通常是 i2cdetect -l 列出所有适配器，然后 i2cdetect -y 1 扫描总线 1 上的所有地址。输出会显示一个地址矩阵，如果某个地址上有设备，会显示该地址的十六进制值；如果显示 "--"，表示该地址无设备；如果显示 "UU"，表示该地址被驱动占用。

但 i2cdetect 有个局限性：它只能检测有响应的设备，如果设备地址正确但寄存器读写有问题，i2cdetect 可能显示正常但实际读写失败。另外，有些设备在未初始化时不响应扫描，比如某些传感器需要先写配置寄存器才会应答。我遇到过 GT911 触摸屏，i2cdetect 扫不到，但实际通信是正常的，因为它的地址在复位后有变化，需要先拉低复位脚再释放才能进入正常模式。

4.2 逻辑分析仪解码 I2C 的实操要点

逻辑分析仪的价格从几十块到几千块不等，但即使是便宜的逻辑分析仪，只要采样率足够，也能很好地解码 I2C。关键是采样率要至少是 I2C 时钟频率的 10 倍以上，比如 400kHz 的 I2C，采样率至少要 4MHz，建议 10MHz 以上。连接时，通道 0 接 SCL，通道 1 接 SDA，地线接板子 GND。软件里设置 I2C 解码器，指定 SCL 和 SDA 通道，设置地址位宽（通常是 7 位），然后就可以看到解码后的地址、数据、ACK/NACK。

逻辑分析仪最大的优势是能抓很长时间的波形，而且能直接搜索特定的地址或数据。比如你想知道主机有没有向 0x50 写入数据，可以直接在解码结果里搜索 0x50。但逻辑分析仪看不到模拟特性，如果上升沿太缓导致从机采样错误，逻辑分析仪可能显示数据正确，但实际芯片就是收不到。所以逻辑分析仪和示波器是互补的，不能互相替代。

4.3 从软件层面验证：读写 EEPROM 的完整流程

如果你手头有一块 EEPROM，比如 AT24C02，可以用它来验证整个 I2C 链路。写一个简单的读写程序：先向 EEPROM 的某个地址写入一个字节，比如 0x55，然后读回来，看是否一致。如果写进去读出来不对，那说明时序或者地址有问题。这个测试的好处是 EEPROM 的协议非常简单，没有复杂的寄存器配置，适合用来排除主机的 I2C 外设问题。

在 Linux 下可以用 i2cset 和 i2cget 命令：i2cset -y 1 0x50 0x00 0x55 表示向总线 1 上地址 0x50 的 EEPROM 的 0x00 寄存器写入 0x55，然后 i2cget -y 1 0x50 0x00 读回来。如果读回来是 0x55，说明 I2C 链路完全正常。如果读回来是 0xFF 或者其他值，那就要检查写保护引脚是否拉高、地址是否正确、时序是否满足。

4.4 软件工具阶段的典型问题与解决

这个表格里的问题都是我实际遇到过的，尤其是 i2cdetect 显示 UU 这种情况，很多人以为是故障，其实只是驱动已经加载了，设备被占用，这时候用 i2cset 反而可能失败，需要先卸载驱动或者直接用驱动提供的接口。

5. 那些年我踩过的 I2C 排查坑

5.1 地址冲突：两个设备用同一个地址

地址冲突是 I2C 排查中最常见的问题之一。比如你同时接了两个 AT24C02，默认地址都是 0x50，那肯定通信失败。解决方法是通过地址引脚配置不同的地址，AT24C02 的 A0/A1/A2 引脚可以组合出 8 个地址。但有些模块把地址引脚固定死了，比如某些传感器模块只提供一个地址，这时候你就不能用两个同型号的模块。

我遇到过一个更隐蔽的地址冲突：一个 OLED 模块和一个温度传感器模块，地址看起来不冲突，但 OLED 模块在上电初始化时会短暂占用另一个地址，导致温度传感器初始化失败。后来查手册才发现 OLED 模块内部有一个地址切换机制，上电时会先响应一个默认地址。这种问题只能通过逻辑分析仪抓完整的上电时序才能发现。

5.2 总线电容过大：线长与设备数量的权衡

I2C 规范规定总线电容不能超过 400pF，但实际中很多人忽略这个限制。每增加一个设备，大约增加 10pF 到 20pF 的引脚电容，每增加 10cm 的走线，大约增加 10pF 到 20pF 的分布电容。如果你挂了 8 个设备，线长 50cm，总线电容可能已经超过 400pF 了。这时候上升沿会变得很缓，通信不稳定。

解决方法有几个：减小上拉电阻，比如从 10k 降到 2.2k，但这样会增加功耗；使用 I2C 缓冲器或者多路复用器，比如 PCA9548，把总线分成多段，每段电容独立；降低通信速率，比如从 400kHz 降到 100kHz。我一般优先考虑减小上拉电阻，如果还不行就上多路复用器。

5.3 时钟拉伸：从机拉低 SCL 时主机要等待

时钟拉伸是 I2C 的一个特性，从机可以通过拉低 SCL 来强制主机等待，这在从机需要更多时间处理数据时很有用。但有些主机的 I2C 外设不支持时钟拉伸，或者配置不对，导致从机拉低 SCL 后主机继续发时钟，通信失败。用示波器可以看到 SCL 被从机拉低了一段时间，然后才恢复。

如果你怀疑是时钟拉伸问题，可以先用逻辑分析仪抓波形，看 SCL 是否有被从机拉低的区间。如果是，检查主机的 I2C 配置是否使能了时钟拉伸支持。有些 STM32 的 I2C 外设需要配置 NOSTRETCH 位，如果设成了禁止时钟拉伸，就会出问题。

5.4 电源噪声与地弹：模拟层面的隐形杀手

I2C 通信失败有时候不是数字逻辑问题，而是模拟问题。比如电源噪声导致从机复位，或者地弹导致电平判断错误。用示波器看 SDA 和 SCL 的波形，如果上面叠加了高频噪声，或者地线上有大的毛刺，那就要考虑电源滤波和地线布局。我遇到过一个案例：电机驱动和 I2C 传感器共用一组电源，电机启动时 I2C 通信就出错。后来给传感器单独加了一个 LDO 和滤波电容，问题解决。

提示：如果你在调试 I2C 时发现通信时好时坏，而且和电机、继电器等大功率设备有关，优先检查电源和地线。数字逻辑问题通常是稳定的，时好时坏往往是模拟问题。

6. 从排查到预防：让 I2C 一次跑通的设计习惯

6.1 原理图阶段就要考虑的上拉与地址

很多 I2C 问题在原理图阶段就可以避免。第一，上拉电阻不要照抄参考设计，要根据总线电容和通信速率计算。我一般会在原理图上标注上拉电阻的计算公式和预期值，方便后续检查。第二，地址引脚不要悬空，要么接 VCC 要么接 GND，悬空会导致地址不确定。第三，如果总线上设备较多，预留 I2C 多路复用器的位置，方便后续扩展。

6.2 PCB 布局：走线长度与干扰隔离

PCB 布局对 I2C 的影响很大。SDA 和 SCL 尽量走在一起，保持等长，减少环路面积。远离高频信号和电源开关节点，如果必须交叉，尽量垂直交叉。总线走线不要过长，一般控制在 30cm 以内，超过的话考虑加缓冲器。上拉电阻尽量靠近主机或者总线中间位置，不要放在总线末端。

6.3 软件配置：时钟频率与超时处理

软件层面，I2C 的时钟频率不要设得太高，尤其是长线或者多设备的情况。我一般先用 100kHz 调通，再尝试提高到 400kHz。另外，一定要加超时处理，如果 I2C 通信卡死，超时后要能复位总线。STM32 的 HAL 库提供了 HAL_I2C_IsDeviceReady 函数，可以用来检测设备是否就绪，避免死等。

6.4 调试接口的预留：方便后续排查

最后，建议在 PCB 上预留 I2C 的测试点，方便后续用示波器或者逻辑分析仪抓波形。测试点可以做成小焊盘或者排针，标注好 SDA、SCL、GND。如果板子空间允许，还可以预留一个 I2C 缓冲器的位置，方便后续调试。这些预留成本很低，但调试的时候能省很多时间。

我个人在实际操作中的体会是，I2C 排查最忌讳的就是一上来就怀疑芯片坏了，然后换芯片、换板子，最后发现是上拉电阻或者地址的问题。按照万用表、示波器、逻辑分析仪这个顺序，从静态到动态，从模拟到协议，一步步缩小范围，绝大多数问题都能在半小时内定位。另外，手边常备一个便宜的逻辑分析仪和一块已知良好的 EEPROM 模块，调试的时候能省很多事。