引子
在對STM32利用4G模塊進行遠程升級時，如何保證下載下來的bin檔案是完整沒有丟失的呢？
有兩種方式：
1. 分包打校驗，接收一包校驗一包
2. 整包打校驗，接收完畢后整體校驗
為快速實作，采用第二種方式
校驗方式
選擇簡單常見的CRC校驗，
為了降低難度，參考安富萊電子的教程，使用keil在編譯時生成整個程式包的crc校驗
keil支持用戶定義的命令，如下圖在User標簽頁選擇編譯后執行的腳本CopyHex_Flash.bat
該腳本檔案中主要利用srec_cat檔案對編譯生成的hex做crc校驗，對于本次實作的OTA更新具體有兩種方式：
方式1：在指定位置存放crc
srec_cat.exe .\FLS-B100\FLS-B100.hex -intel -crc32-l-e 0x0803FFFC -o .\BIN\output-crc.hex -intel -Output_Block_Size=16
hex2bin .\BIN\output-crc.hex
- srec_cat.exe .\FLS-B100\FLS-B100.hex -intel 以intel格式讀取 hex文
- -crc32-l-e 0x0800FFFC 在 0x0800FFFC 存放之前檔案的crc校驗
- -o .\BIN\output-crc.hex -intel -Output_Block_Size=16 輸出操作完畢后的hex檔案
- hex2bin .\BIN\output-crc.hex 生成bin檔案
這種方式的優點是： 適合在單片機端做校驗，程式可直接定義變數指向該位置,如下：
uint32_t crc_res __attribute__((at(0x0800FFFC)));
代碼中可以使用變數crc_res來獲取編譯時計算的crc結果，然后和單片機計算的結果進行對比
缺點是占用空間，比如程式總大小并沒有達到0x0800FFFC ,那么在程式最大末尾段到 0x0800FFFC會自動填充，導致生成的bin檔案過大，不適合OTA傳輸，
方式2：在hex檔案末尾存放crc
srec_cat.exe .\FLS-B100\FLS-B100.hex -intel -crc32-l-e -maximum-address .\FLS-B100\FLS-B100.hex -intel -o .\BIN\output-crc.hex -intel -Output_Block_Size=16
hex2bin .\BIN\output-crc.hex
- -crc32-l-e -maximum-address .\FLS-B100\FLS-B100.hex -intel 在 .\FLS-B100\FLS-B100.hex最大地址也就是最末尾生成 crc校驗 以intel格式
這種方式的優點是生成的bin檔案小，適合OTA傳輸
缺點是難以在STM32程式中把變數指向生成的crc所在的位置（因為腳本中設定crc存放與程式的最 末端，而最末端的地址單片機不能向前一種方式直接確定），為解決這一問題，可以借助EC20做HTTP請求bin檔案時回傳檔案大小來輔助定位crc結果存放的位置，
最終我選擇第二種方式，為確保無誤，首先手動驗證是否能給通過長度計算出crc位置，
1.編譯完成后的bin大小：
2.STM32利用EC20通過HTTP下載bin檔案時回傳的檔案大小
3.查看bin檔案中crc位置
如圖中紅色字體注釋，驗證結果為：可以通過bin檔案大小減去4位元組得到crc的的結果，這樣的話就能最小化韌體體積，
實操校驗
校驗要在bootloader程式中完成，下載bin檔案寫入到flash后，利用STM32自帶的硬體CRC校驗 （bin位元組總大小-4 ）個位元組，然后將得到的結果與存放于相對于APP起始位置偏移（bin檔案總大小-4）的CRC值進行對比，如果一致，說明程式完整，否則不完整，從而進一步處理，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/280967.html
標籤：其他
下一篇：C#的Socket案例