1、案例一問題描述

客戶反饋其產品在使用 STM32G0C1NEY6TR 和一個充電管理 IC 通信時，速率為100KHz 時通信正常，但工作在 400KHz 時，有時會產生 I2C 錯誤。把 I2C GPIO 配置為推挽輸出后產生錯誤的概率會下降。

2、案例一問題確認

針對客戶的反饋，建議客戶用邏輯分析儀抓通信波形做進一步分析失敗時，SDA 和 SCL 在通信沒有完成時都被異常拉高。

3、案例一問題分析

從客戶的反饋看 I2C 工作在 100K 速率時通信正常，而配置 400K 速率通信的時候容易出現問題。首先想到的是否跟 SDA 和 SCL 的上升沿建立時間有關系，因為如參考手冊RM0444 中圖二，I2C 工作在 standard mode 100K ,和 Fast mode 400K 速率在 tr( Risetime) 上是有差異的。

后面讓客戶用示波器抓取 SCL 波形，并且建議在 I2C GPIO 配置為開漏模式時測量上升沿上升的時間，如下圖三，在上拉電阻為 4.7K 時，Rise time 是 180ns 左右，符合規(guī)格書要求。

又建議客戶嘗試將上拉電阻改為 2.2K, 如下圖 Rise time 是 72ns,客戶反饋這時出現通信異常的概率比原來 4.7K 上拉時小很多。但問題是功耗變大，客戶不接受改小上拉電阻。

由于不能通過調小上拉電阻的阻值調整上升沿的時間，建議客戶嘗試在 STM32CubeMX 工程將 Rise time 設置跟實際測量值一致?？蛻舴答佋?STM32CubeMX 調整后并沒有明顯改善。

最后讓客戶直接抓出問題時的示波器波形。

可以發(fā)現，綠色 SDA 的高電壓值大概是在 2v,處于一個臨界狀態(tài)，這可能導致 I2C 停止通信，并把 I2C 的 SDA 和 SCL 電平拉高。

根據波形的情況，建議客戶將 GPIO 速度調高，并且不建議使用推挽模式，因為這不符合I2C 規(guī)范。看波形有沒改善?？蛻舴答伿菃栴}依舊存在。

4、案例一問題解決

進一步的分析是看誰把 SDA 的電平拉低，建議客戶在 SCL，SDA 線路接電阻測量出問題時，I2C 主從兩端的電壓變化。STM32G0 是和兩個 I2C slave 通信，一個是充電管理芯片，另一個是 LED 驅動芯片。最后發(fā)現是 LED 驅動芯片進入低功耗模式時把 I2C SDA 腳拉低導致 I2C SDA 電平被拉低，進而影響了 STM32G0 和充電管理芯片之間的 I2C 通信。后面修改了 LED 驅動芯片進入低功耗的時機，問題得到解決。

5、案例二問題描述

另一個關于 STM32G0C1 I2C 的問題是客戶發(fā)現在復位 I2C slave 后，下一包數據有時會發(fā)送失敗。并且會收到 BERR 錯誤。