1、案例一問題描述

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

2、案例一問題確認(rèn)

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

3、案例一問題分析

從客戶的反饋看 I2C 工作在 100K 速率時(shí)通信正常，而配置 400K 速率通信的時(shí)候容易出現(xiàn)問題。首先想到的是否跟 SDA 和 SCL 的上升沿建立時(shí)間有關(guān)系，因?yàn)槿鐓⒖际謨?cè)RM0444 中圖二，I2C 工作在 standard mode 100K ,和 Fast mode 400K 速率在 tr( Risetime) 上是有差異的。

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

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

由于不能通過調(diào)小上拉電阻的阻值調(diào)整上升沿的時(shí)間，建議客戶嘗試在 STM32CubeMX 工程將 Rise time 設(shè)置跟實(shí)際測量值一致。客戶反饋在 STM32CubeMX 調(diào)整后并沒有明顯改善。

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

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

根據(jù)波形的情況，建議客戶將 GPIO 速度調(diào)高，并且不建議使用推挽模式，因?yàn)檫@不符合I2C 規(guī)范?？床ㄐ斡袥]改善。客戶反饋是問題依舊存在。

4、案例一問題解決

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

5、案例二問題描述

另一個(gè)關(guān)于 STM32G0C1 I2C 的問題是客戶發(fā)現(xiàn)在復(fù)位 I2C slave 后，下一包數(shù)據(jù)有時(shí)會(huì)發(fā)送失敗。并且會(huì)收到 BERR 錯(cuò)誤。