本文主要是通過遷移的思維，記錄本人初次使用周立功的Aworks框架進行BSP開發

本文主要講述在RT1052上面，MIPI顯示馬賽克的處理過程。

1. 硬體原理圖

2. 問題現象

在汽車ACC點火之後，顯示馬賽克。

3. 問題排查

（1）出現問題時，通過CAN訊息切換該區域的顯示內容，發現可以正常顯示，至少說明顯示硬體電路是正常的。
（2）由於MCU是XIP執行，且資料在flash上面，猜想如果是flash資料讀取異常的話，至少會出現系統取指異常的問題，但是實際上並沒有，所以提除flash讀取出錯的可能性。
（3） 復現該問題時，每次均在圖片的後半斷出錯，在車頭位置。
（4） FAE建議關閉Cache之後，看一下現象是否還有，關閉之後該問題不再出現，但是對顯示幀率影響很大。這說明本身程式碼流程是沒有問題的。是異常因素導致。本質上還是降低軟體的效率，降低flash的讀寫。
（5）單獨對flash做大容量的讀寫測試，也沒有問題。說明本身驅動沒有關題。在qspi flash驅動下，通過flash資料手冊，重新確認讀寫的時序及資料鎖存的時候，均在正常範圍內。且單獨降低flash的工作時鐘至60M，該問題依然存在。
（6） 由於qspi flash的執行時鐘比較高120M以上的工作時鐘，所以對走線及PCB的阻抗有要求，雖然硬體沒有按要求做，但是無法通過軟體去斷定肯定是硬體問題。比較明顯的區別就是做過阻抗匹配參考板的PCB，調整flash時鐘的輸出強度，均不會造成讀寫出錯，但是如果板子不做阻抗匹配的PCB，在某些輸出強度會有讀寫失敗的現象。

4. 處理方法

綜上處理分析：
1.如果斷定是硬體問題，需要等新板子回來之後，只要在新板子上面不再出現該問題，說明是走線及阻抗問題導致。
2. 通過圖片原始資料校驗規避該問題。
3. 減少不必要的flash讀操作，由於解壓圖片時，預設優先會使用jpeg進行解析，但是圖片資源是Png格式，預設優先使有png格式進行解析，發現該問題不再出現。

5. 總結

本質上面flash讀出錯的話，主要還是flash的時鐘，尤其是不穩導致。還有就是軟體解析出錯，但是可以性比較小。該問題待確認根本原因。