你的浏览器版本过低,可能导致网站不能正常访问!
为了你能正常使用网站功能,请使用这些浏览器。

经验分享 | LAT1490 两个STM32G0 I2C 通信异常的案例分析

[复制链接]
攻城狮Melo 发布时间:2026-3-16 09:57

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

关键字:STM32G0C1NEY6TR,I2C

下载文档:LAT1490 两个STM32G0 I2C 通信异常的案例分析

1. 案例一问题描述

客户反馈其产品在使用 STM32G0C1NEY6TR 和一个充电管理 IC 通信时,速率为 100KHz 时通信正常,但工作在 400KHz 时,有时会产生 I2C 错误。把 I2C GPIO 配置为推挽输出后产生错误的概率会下降。

2. 案例一问题确认

针对客户的反馈,建议客户用逻辑分析仪抓通信波形做进一步分析。通信失败时,SDA 和 SCL 在通信没有完成时都被异常拉高。 image.png

3. 案例一问题分析

从客户的反馈看 I2C 工作在 100K 速率时通信正常,而配置 400K 速率通信的时候容易出现问题。首先想到的是否跟 SDA 和 SCL 的上升沿建立时间有关系,因为 I2C 工作在 standard mode 100K,和 Fast mode 400K 速率在 tr (Rise time) 上是有差异的,具体参数如下:

表格

Symbol Parameter Standard-mode (Sm) Fast-mode (Fm) Fast-mode Plus (Fm+) SMBus Unit
Min. Max. Min. Max. Min. Max. Min. Max.
tHD:DAT Data hold time 0 - 0 - 0 - 0.3 - us
tVD:DAT Data valid time - 3.45 - 0.9 - 0.45 - - -
tSU:DAT Data setup time 250 - 100 - 50 - 250 - ns
- Rise time of both SDA and SCL signals - 1000 - 300 - 120 - 1000 ns
- Fall time of both SDA and SCL signals - 300 - 300 - 120 - 300 ns

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

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

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

最后让客户直接抓出问题时的示波器波形, image.png

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

根据波形的情况,建议客户将 GPIO 速度调高,并且不建议使用推挽模式,因为这不符合 I2C 规范,查看波形是否有改善,客户反馈问题依旧存在。

4. 案例一问题解决

进一步的分析是看谁把 SDA 的电平拉低,建议客户在 SCL、SDA 线路接电阻测量出问题时,I2C 主从两端的电压变化。STM32G0 是和两个 I2C slave 通信,一个是充电管理芯片,另一个是 LED 驱动芯片。最后发现是 LED 驱动芯片进入低功耗模式时把 I2C SDA 脚拉低导致 I2C SDA 电平被拉低,进而影响了 STM32G0 和充电管理芯片之间的 I2C 通信。后续修改了 LED 驱动芯片进入低功耗的时机,问题得到解决。

5. 案例二问题描述

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

6. 案例二问题分析

image.png

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

I2C 中断和状态寄存器(I2C_ISR)相关说明

  • 地址偏移:0x18
  • 复位值:0x00000001
  • 访问方式:无等待状态
  • Bit 8 BERR:总线错误,当外设参与传输时检测到错误的起始或停止条件,硬件会置位该标志;从机模式下的地址阶段该标志不会置位;可通过软件置位 BERRCF 位清除该标志,当 PE=0 时,硬件会清除该位。

错误条件说明

总线错误(BERR)产生条件为 SCL 为高电平时 SDA 出现边沿变化。只有当 I2C 作为主机或被寻址的从机参与传输时(即非从机模式下的地址阶段),总线错误标志才会置位。当检测到总线错误时,I2C_ISR 寄存器中的 BERR 标志会置位,如果 I2C_CR1 寄存器中的 ERRIE 位被置位,会产生中断。

从寄存器状态看,确实是发生了 BERR 错误,并且从示波器抓取的图形看,发现最后一个 NACK 的上升沿变化时,SCL 为高电平。一般如果 I2C 从设备接收到的数据有错误(例如校验错误)或从设备无法处理接收到的数据时,它就会发送 NACK。而此次这个 NACK 信号的上升边沿恰好引起了主机误判,以为是 STOP 信号(在 SCL 为高时,SDA 由低变为高),而这个 STOP 又不是在第九个 clock 后产生,所以导致产生 BERR 错误。

7. 案例二问题解决

后续建议客户排查一下从机端为什么会发送 NACK 信号并进行相应优化处理,同时增加 I2C 超时处理机制,复位主从 I2C,并重新初始化 I2C 外设,最后问题得到解决。

8. 小结

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

image.png
收藏 评论0 发布时间:2026-3-16 09:57

举报

0个回答

所属标签

相似分享

官网相关资源

关于
我们是谁
投资者关系
意法半导体可持续发展举措
创新与技术
意法半导体官网
联系我们
联系ST分支机构
寻找销售人员和分销渠道
社区
媒体中心
活动与培训
隐私策略
隐私策略
Cookies管理
行使您的权利
官方最新发布
STM32N6 AI生态系统
STM32MCU,MPU高性能GUI
ST ACEPACK电源模块
意法半导体生物传感器
STM32Cube扩展软件包
关注我们
st-img 微信公众号
st-img 手机版