0.環境：arm CPU 帶有IIC控制器作為slave端，帶有調試串口。
1.bug表現：IIC slave 在系統啟動后概率掛死，導致master無法detect到slave。
猜測1：認為IIC device程序有問題
檢查1：查看程序發現有可能溢出的部分，使用IIC 工具刷過量數據到slave，未出問題。
猜測2：認為IIC device寄存器進入異常狀態未能恢復
檢查2：檢查正常IIC寄存器和異常狀態IIC寄存器，未能發現問題。
猜測3：時鍾分頻問題
檢查3：詢問同事，答固定分頻。
猜測4：看波形分析
檢查4：波形未量到，測量波形導致通信異常，部分設備破壞，放棄該方法。
2.發現新情況：系統啟動過程中如果調試串口有數據輸入，問題會概率出現。如果串口沒有輸入則多次測試不會出現問題。
猜測1：串口中斷導致IIC初始化時被打斷產生問題。
檢查1：刪除調試串口設備樹節點，發現IIC啟動100%出現問題 T-T。
猜測2: 100%復現的問題和之前的概率出現的問題相同
檢查2：檢查寄存器，檢查設備detect 表現，認為是相同問題。
3.刪除調試串口，IIC受影響的原因？
刪除串口設備樹節點，IIC device 必出問題。
猜測1：懷疑調試串口外部硬件電平高低導致IIC外設受影響
檢查1：檢查原理圖，未發現影響的可能性。
猜測2：懷疑串口初始化部分處理了部分IIC設備依賴的初始化（導致不初始化串口IIC不能正常工作）。
檢查2：查看串口初始化代碼未能發現有值得注意的初始化。
猜測3：懷疑串口初始化影響公共寄存器間接影響IIC。
檢查3：發現公共寄存器IIC div分頻部分和正常工作的分頻不一樣，改回后問題解決。
4.公共寄存器怎么被修改的？
刪除串口設備后公共寄存器值不正常，串口收到數據后公共寄存器值不正常。
猜測1：調試串口或IIC代碼異常導致寄存器值被修改。
檢查1：增加打印，發現問題原因在於IIC初始化過程中分頻寄存器設置失敗。但是同樣方法在IIC device端初始化時設置該寄存器是成功的。
5.公共寄存器為什么不能寫入？
猜測1: 特定配置下IIC 分頻寄存器為只讀
檢查1:芯片設計方核實不存在這樣的設計。
檢查1:在寫入分頻寄存器前增加打印，dump所有公共寄存器。和正常公共寄存器做比較，未發現問題。寫入IIC分頻器成功。
猜測2:增加打印信息后寫入成功為必現，去掉打印會寫入不成功。
檢查2：證實猜測。
猜測3：寫入成功和讀取公共寄存器相關
檢查3：減少dump范圍，小范圍dump寫入失敗，大范圍dump寫入成功。
猜測4：寫入成功和寫入時間相關
檢查4：dump的寄存器次數不變dump相同寄存器。證實寫入成功與寫入時間相關。
6.為什么不能寫入和時間相關？
思考：可能和時鍾初始化相關，但是公共寄存器的時鍾初始化狀態dump是正常的。
猜測1：dump過程中時鍾初始化完成（證據：增加dump后寫入正常）。
檢查1：減少dump范圍，發現公共寄存器的mpll穩定寄存器未穩定。
猜測2：時鍾相關初始化未完成導致寫入失敗。
檢查2：根據時鍾依賴，在寫入前增加等待，同時去掉打印，寫入成功。
去掉串口設備導致問題100%復現，原因是串口不用初始化導致IIC 時鍾分頻更早初始化，寫入IIC分頻寄存器失敗。
總結：
1.解決問題過程中，曾經懷疑過時鍾分頻問題但是未檢查寄存器，導致問題解決時間拉長。
2.最開始未能考慮問題和時間相關的情況，如果直接思考該可能性，預計提高解決問題速度。