两个 STM32G0 I2C 通信异常的案例分析

客户反馈其产品在使用 STM32G0C1NEY6TR 和一个充电管理 IC 通信时，速率为100KHz 时通信正常，但工作在 400KHz 时，有时会产生 I2C 错误。

把 I2C GPIO 配置为推挽输出后产生错误的概率会下降。

针对客户的反馈，建议客户用逻辑分析仪抓通信波形做进一步分析。如下图一，通信

失败时，SDA 和 SCL 在通信没有完成时都被异常拉高。

从客户的反馈看 I2C 工作在 100K 速率时通信正常，而配置 400K 速率通信的时候容易出现问题。

首先想到的是否跟 SDA 和 SCL 的上升沿建立时间有关系，因为如参考手册RM0444 中图二，I2C 工作在 standard mode 100K ,和 Fast mode 400K 速率在 tr( Rise time) 上是有差异的。

后面让客户用示波器抓取 SCL 波形，并且建议在 I2C GPIO 配置为开漏模式时测量上升沿上升的时间，如下图三，在上拉电阻为 4.7K 时，Rise time 是 180ns 左右，符合规格书要求。

又建议客户尝试将上拉电阻改为 2.2K, 如下图 Rise time 是 72ns,客户反馈这时出现通信异常的概率比原来 4.7K 上拉时小很多。但问题是功耗变大，客户不接受改小上拉电阻。

由于不能通过调小上拉电阻的阻值调整上升沿的时间，建议客户尝试在 STM32CubeMX 工程将 Rise time 设置跟实际测量值一致，如下图。客户反馈在 STM32CubeMX 调整后并没有明显改善。

最后让客户直接抓出问题时的示波器波形，如下图：

可以发现，绿色 SDA 的高电压值大概是在 2v,处于一个临界状态，这可能导致 I2C 停止通信，并把 I2C 的 SDA 和 SCL 电平拉高。因为按规格书要求高电平必须在 70%VDD，即

70%x3.3V=2.31v,如上图。

根据波形的情况，建议客户将 GPIO 速度调高，并且不建议使用推挽模式，因为这不符合

I2C 规范。看波形有没改善。客户反馈是问题依旧存在。

进一步的分析是看谁把 SDA 的电平拉低，建议客户在 SCL，SDA 线路接电阻测量出问题时，I2C 主从两端的电压变化。

STM32G0 是和两个 I2C slave 通信，一个是充电管理芯片，另一个是 LED 驱动芯片。

最后发现是 LED 驱动芯片进入低功耗模式时把 I2C SDA 脚拉低导致 I2C SDA 电平被拉低，进而影响了 STM32G0 和充电管理芯片之间的 I2C 通信。

后面修改了 LED 驱动芯片进入低功耗的时机，问题得到解决。

另一个关于 STM32G0C1 I2C 的问题是客户发现在复位 I2C slave 后，下一包数据有时会发送失败。并且会收到 BERR 错误。

针对客户的反馈，建议客户抓取发现问题时的示波器波形以及 I2C 的寄存器状态。

如上图寄存器状态看，确实是发生了 BERR 错误，并且示波器抓的图形看，发现最后一个NACK 的上升沿变化时，SCL 看起来是为高的。

一般如果 I2C 从设备接收到的数据有错误（例如校验错误）或从设备无法处理接收到的数据时，它就会发送 NACK。

而现在这个 NACK 信号的上升边沿恰好引起了主机误判，以为是 STOP 信号（在 SCL 为高时，SDA 由低变为高）而这个STOP 又不是在第九个 clock 后产生，所以导致产生 BERR 错误。

后面建议客户排查一下从机端为什么会发送 NACK 信号并进行相应优化处理。

同时增加I2C 超时处理机制，复位主从 I2C，并重新初始化 I2C 外设。最后问题得到解决。

上面分享了两个有关 I2C 通信异常案例的分析过程和解决办法，供大家参考。

本文档参考ST官方的《LAT1490 两个STM32G0 I2C 通信异常的案例分析》文档。