## [Ooonly] 前情提要：需要刷寫一整個app程式，分包刷寫，每包位元組數為單數，要求CRC校驗正確。（晶元底層提供32位全字刷寫和16位半字刷寫，驅動只整合了32位全字刷寫函數） 使用32位刷寫函數出現的現象：通過keil5觀察記憶體空間發現一包刷寫成功一包刷寫失敗一包刷寫成功...一直迴圈到 ...
[Ooonly]
前情提要：需要刷寫一整個app程式，分包刷寫，每包位元組數為單數，要求CRC校驗正確。（晶元底層提供32位全字刷寫和16位半字刷寫，驅動只整合了32位全字刷寫函數）
使用32位刷寫函數出現的現象：通過keil5觀察記憶體空間發現一包刷寫成功一包刷寫失敗一包刷寫成功...一直迴圈到末尾，刷寫失敗的包開始幾個位元組為亂碼，不是包中的內容，且後面為全0xFF。
一、分析問題原因
首先理解驅動中32位寫入記憶體函數刷寫單數位元組是如何處理的，在每次刷寫完一次4位元組之後，判斷該包剩餘未刷寫位元組數是否小於4，若小於4則補充0xFF至4個位元組後一次刷入4位元組結束。
出現問題，由於一個完整的app程式要求每個包中間是完美連接的，即一個分包的末尾位元組的下一個位元組為下一包的首位元組。此時一個包的末尾位元組後有剛剛補充的0xFF，記憶體通常在一次刷寫之後會自動加上防寫，再次擦除之後才可再次刷寫。
一包刷寫成功之後，下一包的首位元組刷寫地址和上一包末尾補充0xFF衝突，造成刷寫失敗寫入隨機非0亂碼。
二、解決方法
更改驅動中32位全字刷寫函數，更改邏輯為：當前包刷寫剩餘位元組數小於4時，將剩餘位元組按順序放入一個4位元組緩存中，並記錄下剩餘位元組個數。當下一包開始刷寫時，刷寫地址需減去上一包剩餘位元組個數，並從首位元組開始補充上述4位元組緩存，形成一個由上一包的尾位元組與當前包首位元組組成的4位元組全字刷寫。最後需要額外判斷整個app是否即將刷寫完成，若當前包為最後一包，那麼就沒有下一包來補充含有剩餘位元組的4位元組緩存，此時按原有邏輯補充0xFF進行32位全字刷寫。
三、註意事項
由於該全字刷寫函數不一定只有app刷寫功能調用，還有例如參數保存等功能調用，所以建議使用巨集定義，若不是app刷寫功能則32位全字刷寫函數內容與原來保持一致。作者並因為是新手，對巨集定義理解不深刻，並沒有第一時間想到這種操作方式，使用if-else也實現了，但是想起來好像巨集定義更好看一點，哈哈。有想法、問題、意見可以評論或私信提出，歡迎交流轉載。
以上就是今天要講的內容，感謝您的關註。
