最近公司有一款新版硬體，在測試時發現原有的i2c通訊測試程式執行失敗，從i2c從裝置rx8025中無法讀取到資料。使用示波器的時候，也無法在時鐘線scl上看到時鐘訊號。但是在測試資料線sda的時候，偶爾能看到一些資料。如果使用示波器錶筆點在測試的訊號線上，有時能讀到正確的資料；如果不這樣做，幾乎看不到正確的資料。開始懷疑是否是因為測試程式本身可靠性有問題，因為在一段時間測試後發現，這種現象隨機性比較大。如果程式，沒有初始化好硬體，或延時沒做好，很容易造成這種隨機性的問題。
於是，將軟體可能的延時及初始化檢查了一遍。找到了一處延時疑似有問題的地方。將這個地方的延遲增大2us後，測試竟然執行都通過了。在接下來的測試中，i2c讀寫正常。此時，找到i2c通訊失敗的原因了：i2c訊號從寫入結束傳送stop，到下一次開始讀取從裝置的start時間間隔約為在3.7us，此時間偏小，導致通訊不穩定，增加延遲可以解決問題。
在寫完，上邊的結論後，認為事情到此結束。
之後，分析了stm32的i2c主機通訊時鐘訊號的引數，同時檢查了程式中i2c的引數配置。發現不應該出現這樣的情況。因為程式配置的i2c引數，使其執行在fast mode此種模式下，stop：start的時間間隔最小為1.3us，而實際的3.7us是滿足要求的。也就是說在此處增加延時，並不能真正解決問題。
在第二天的測試中，發現原來的解決方法確實存在問題。還是會有i2c通訊失敗的情況。再將原有測試程式中i2c的超時處理部分用#if注釋掉（因為stm32庫自帶的i2c示例程式存在致使程式陷入while死迴圈的情況，而其優化解決方案使用了dma+中斷，感覺有些殺雞用牛刀，不太合適。於是在其原有程式中做了超時處理，避免i2c通訊失敗陷入while死迴圈）。發現，程式執行正常。但是，如果加上超時處理，程式就無法正常執行。由此說明，並不是什麼stop：start的時間問題。
於是將原有i2c測試程式（引數不變，帶超時處理）在舊的硬體上執行，通訊正常。
這裡問題出來了，同樣的程式，在舊的硬體中可以執行，在新的硬體上執行異常，這裡邊應該**有問題。於是，將原有的i2c通訊速率400khz的時鐘降低到200khz，保留超時處理，在新的硬體版本上執行。發現執行正常，讀取資料正常。
至此，於新版硬體的i2c通訊問題，自認為是找到了：i2c的400khz時鐘速率在新版硬體上執行存在異常，調低時鐘速率在新版硬體上執行（硬體優化後，或許繼續使用原有的引數）。
由此問題解決過程中，發現：很容易將問題q消失時，採用的方式m認為是問題出現的地方。可是往往，問題的真正原因r卻躲在某個角落，為m替其頂罪感到開心，也為躲過了一場搜捕感到竊喜。下一次，他還會出來繼續作亂。只有當真正將r繩之以法，才能根據解決問題q。而這，需要的不只只是眼睛，還有思考。
頭痛醫頭腳痛醫腳，只治得了疼，卻治不了病。
I2C匯流排硬體基礎
i2c 內建積體電路 匯流排是由philips公司開發的兩線式序列匯流排，產生於20世紀80年代，用於連線微控制器及其外圍裝置。i2c匯流排簡單而有效，占用很少的pcb 印刷電路板 空間，晶元管腳數量少，設計成本低。i2c匯流排支援多主控 multi mastering 模式，任何能夠進行傳送和接收...
i2c通訊的詳細講解 I2C匯流排簡介
本文介紹了內部積體電路 aka i2c 序列通訊協議的基本特性和突出優點。元件之間的通訊 通訊協議 毫無疑問，電子系統的共同特徵是需要在兩個或三個或十個單獨的元件之間共享資訊。工程師已經開發出許多標準協議，可以幫助不同的晶元成功通訊 當您在微控制器或數字訊號處理器的功能列表中 通訊 下面對縮略語時，...
I2C匯流排（一）硬體結構 及 IIC時序
概念 i2c中心是 兩線式 序列匯流排，用於連線微控制器及其外圍裝置。i2c匯流排只有兩根雙向訊號線 sda 資料線 scl 時鐘線 控制原理 通過控制scl和sda線高低電平時序，產生i2c匯流排協議所需的訊號進行資料傳輸。在匯流排空閒狀態，這兩根線一般被上面所接的上拉電阻拉高，保持高電平。i2c...