正文

3、把Bootloader玩出花

上面我所講的都是BL最基礎(chǔ)的一些內(nèi)容，是我們實現(xiàn)BL所必須了解的。BL真正的亮點(diǎn)在于多種多樣的固件數(shù)據(jù)獲取方式。

3.1 BL的實現(xiàn)與延伸（串口傳輸固件）

前面我講到過兩個BL應(yīng)用的實例，一個是串口傳輸固件文件，一個是SD卡拷貝固件文件。它們是在實際工程中經(jīng)常被用到的兩種BL形式。這里著重對前一個實例的實現(xiàn)細(xì)節(jié)進(jìn)行講解剖析，因為它非常具有典型意義，如圖3.21。

圖3.21 BL(串口傳輸固件)的實現(xiàn)流程圖

這個流程圖提出了3個問題：

1、串口通信協(xié)議是如何實現(xiàn)的？

2、為什么獲取到上位機(jī)傳來的固件數(shù)據(jù)，不是直接寫入到APP區(qū)，而是先暫存，

還要校驗？

3、對固件數(shù)據(jù)是如何實現(xiàn)校驗的？

串口通信協(xié)議以及文件傳輸實現(xiàn)的相關(guān)內(nèi)容略顯繁雜，在本書《大話文件傳輸》一章中會專門進(jìn)行講解。

第二個問題：經(jīng)過串口傳輸最終由單片機(jī)接收到的固件數(shù)據(jù)是可能出現(xiàn)差錯的，而有錯誤的固件冒然直接寫入到APP區(qū)，是一定運(yùn)行不起來的。所以，我們要對數(shù)據(jù)各幀進(jìn)行暫存，等全部傳輸完成后，對其進(jìn)行整體校驗，以保證固件數(shù)據(jù)的絕對正確。

針對第三個問題，我們要著重探討一下。

一個文件從發(fā)送方傳輸?shù)浇邮辗?，如何確定它是否存在錯誤？通常的作法在文件中加入校驗碼，接收方對數(shù)據(jù)按照相同的校驗碼計算方法計算得到校驗碼，將之與文件中的校驗碼進(jìn)行對比，一致則說明傳輸無誤，如圖3.22。

圖3.22 對固件文件進(jìn)行補(bǔ)齊并追加校驗碼

圖3.22是對固件文件的補(bǔ)齊以及追加校驗碼的示意。為什么要對文件補(bǔ)齊？嵌入式程序經(jīng)過交叉編譯生成的可燒錄文件，比如BIN，多數(shù)情況下都不是128、256、512或1024的整數(shù)倍。這就會導(dǎo)致在傳輸?shù)臅r候，最后一幀數(shù)據(jù)的長度不足整幀，就會產(chǎn)生一個數(shù)據(jù)尾巴。取整補(bǔ)齊是解決數(shù)據(jù)尾巴最直接的方法。這一操作是在上位機(jī)上完成的，通常是編寫一個小軟件來實現(xiàn)。這個小軟件同時會將校驗碼追加到固件文件末尾。這個校驗碼可以使用校驗和（Checksum）或者CRC，一般是16位或32位，如圖3.23。

圖3.23 通過一個小軟件實現(xiàn)對固件文件補(bǔ)齊和添加校驗碼

又有人會問：“要把整個固件暫存下來，再作校驗，那得需要額外的存儲空間吧，外擴(kuò)ROM（FlashROM或EEPROM）？”是的。如果想節(jié)省成本，我們也可以不暫存，傳輸時直接燒寫到APP區(qū)。這是有風(fēng)險的，但是一般來說問題不大（STC和STM32的串口ISP其實也都是實時燒寫，并不暫存）。

因為在傳輸?shù)倪^程中，傳輸協(xié)議對數(shù)據(jù)的正確性是有一定保障的，它會對每一幀數(shù)據(jù)進(jìn)行校驗，失敗的話會有重傳，連續(xù)失敗可能會直接終止傳輸。所以說，一般只要傳輸能夠完成，基本上數(shù)據(jù)正確性不會有問題。但是仍然建議對固件進(jìn)行整體校驗，在成本允許的情況下適當(dāng)擴(kuò)大ROM容量。同時，固件暫存還有一個另外的好處，在APP區(qū)中的固件受到損壞的時候，比如固件意外丟失或IAP時不小心擦除了APP區(qū)，此時我們還可以從暫存固件恢復(fù)回來（完備的BL會包含固件恢復(fù)的功能）。

其實也不必非要外擴(kuò)ROM，如果固件體積比較小的話，我們可以把單片機(jī)的片上ROM砍成兩半來用，用后一半來作固件暫存。

圖3.24 將片上ROM劃分為3部分

如圖3.24，我們將片上ROM劃分為3部分，分別用于存儲BL、APP固件以及暫存固件。比如我們使用STM32F103RBT6，它一共有128KB的ROM，可以劃分為16K/56K/56K。

有些產(chǎn)品對成本極為敏感。我就有過這樣的開發(fā)經(jīng)歷，當(dāng)時使用的單片機(jī)是STM32F103C8T6，片上ROM總?cè)萘繛?4K，固件大小為48K，BL為12K。在通過BL進(jìn)行固件燒寫時根本沒有多余的ROM進(jìn)行固件暫存。我使用了一招“狗尾續(xù)貂”，如圖3.25。

圖3.25 STM32F103C8T6后64K也可用

我無意中了解到STM32F103C8T6與RBT6的晶元是同一個。只是因為有些芯片后64KB的ROM性能不佳或有瑕疵，而被限制使用了。我實際測試了一下，確實如此。但是后64K ROM的使用是有前提的，也就是需要事先對其好壞進(jìn)行驗證。如果是好的，則暫存校驗，再寫入APP區(qū)；而如果是壞的，那么就直接在固件傳輸時實時寫入APP區(qū)（這個辦法我屢試不爽，還沒有發(fā)現(xiàn)后64K有壞的）。

以上振南所介紹的是一種“騷操作”，根本上還是有一定的風(fēng)險的，ST官方有聲明過，對后64K ROM的質(zhì)量不作保證，所以還是要慎用。

3.2 10米之內(nèi)隔空燒錄

這個“隔空燒錄”源于我的一個IoT項目，它是對空調(diào)的外機(jī)進(jìn)行工況監(jiān)測。大家知道，空調(diào)外機(jī)的安裝那可不是一般人能干的，它要不就在樓頂，要不就在懸窗上。這給硬件升級嵌入式程序帶來很大的困難。所以，我實現(xiàn)了“隔空燒錄”的功能，其實它就是串口BL應(yīng)用的一個延伸，如圖3.26所示。

圖3.26 通過藍(lán)牙串口模塊實現(xiàn)“隔空燒錄”

“隔空燒錄確實牛，但是總要抱著一個電腦，這不太方便吧。”確實是！還記得前面我提過的AVRUBD通信協(xié)議嗎？它的上位機(jī)軟件是有手機(jī)版的。這樣我們只要有手機(jī)，就能“隔空燒錄”了，如圖3.27。

圖3.27 手機(jī)連接藍(lán)牙串口模塊實現(xiàn)“手機(jī)隔空燒錄”

“哪個APP？快告訴我名字”，別急，藍(lán)牙串口助手安卓版，圖3.28是正在傳輸固件的界面。

圖3.28 藍(lán)牙串口助手傳輸固件文件的界面

AVRUBD其實是對Xmodem協(xié)議的改進(jìn)，這個我們放在專門的章節(jié)進(jìn)行詳細(xì)講解。

3.3 BL的分散燒錄

我們知道BL的核心功能其實就是程序燒錄。那你有沒有遇到過比較復(fù)雜的情況，如圖3.29所示。

圖3.29 一個系統(tǒng)（產(chǎn)品）中有多個部件需要燒錄固件

這種情況是有可能遇到的。主MCU+CPLD+通信協(xié)處理器+采集協(xié)處理器就是典型的復(fù)雜系統(tǒng)架構(gòu)。這種產(chǎn)品在批量生產(chǎn)階段，燒錄程序是非常繁瑣的。首先需要維護(hù)多個固件，再就是需要一個個給每一個部件進(jìn)行燒寫，燒寫方式可能還不盡相同。所以我引入了一個機(jī)制，叫“BL的分散燒錄”。

首先我們將所有的固件拼裝成一個大固件(依次數(shù)據(jù)拼接)，并將這個大固件預(yù)先批量燒錄到外擴(kuò)ROM中，比如spiFlash；再將主MCU預(yù)先燒錄好BL；然后進(jìn)行SMT焊接。PCBA生產(chǎn)出來之后，只要一上測試工裝(首次上電)，BL會去外擴(kuò)ROM中讀取大固件，并從中分離出各個小固件，分別以相應(yīng)的接口燒錄到各個部件中去。配合工裝的測試命令，直接進(jìn)行自檢。這樣作，批量化生產(chǎn)是非常高效的。當(dāng)然，這個BL開發(fā)起來也會有一定難度，最大問題可能還是各個部件燒錄接口的實現(xiàn)（有些部件的燒錄協(xié)議是比較復(fù)雜的，比如STM32的SWD或者ESP8266的SLIP）。

OK，上面振南就對一些BL實例的實現(xiàn)和應(yīng)用場景進(jìn)行了介紹。還有一些實例沒有介紹，比如通過CAN總線或SPI進(jìn)行文件傳輸，這個我們還是放到專門的章節(jié)去詳細(xì)講解。當(dāng)然，各位讀者可以在此基礎(chǔ)上衍生出更多有特色而又實用的BL來。

BL沒有最好的，只有最適合自己的。通常來說，我們并不會把BL設(shè)計得非常復(fù)雜，原則上它應(yīng)該盡量短小精煉，以便為APP區(qū)節(jié)省出更多的ROM空間。畢竟不能喧賓奪主，APP才是產(chǎn)品的主角。

4、不走尋常路的BL

4.1 Bootpatcher

我來問大家一個問題：“Bootloader在ROM中的位置一定是在APP區(qū)前面嗎？”很顯然不是，AVR就是最好的例子。那如果我們限定是STM32呢？似乎是的。上電復(fù)位一定是從0X08000000位置開始運(yùn)行的，而且BL一定是先于APP運(yùn)行的。

在某些特殊的情況下，如果APP必須要放在0X08000000位置上的話，請問還有辦法實現(xiàn)BL串口燒錄嗎？要知道APP在運(yùn)行的時候，是不能IAP自己的程序存儲器的（就是自己能自己擦出重新燒錄新固件）。請看圖3.30。

圖3.30 BL位于APP之后稱之為Bootpatcher

APP運(yùn)行時，想要重新燒錄自身，它可以直接跳轉(zhuǎn)到后面的BL上，BL運(yùn)行起來之后開始接收固件文件，暫存校驗OK之后，將固件寫入到前面的APP區(qū)。然后跳轉(zhuǎn)到0X08000000，或者直接重啟。這樣新的APP就運(yùn)行起來了。這個位于APP后面的BL，我們稱之為Bootpatcher(意為啟動補(bǔ)丁)。但是這種作法是有風(fēng)險的，一旦APP區(qū)燒錄失敗，那產(chǎn)品就變磚了。所以這種方法一般不用。

4.2 APP反燒BL

前面我們都是在講BL燒錄APP，那如果BL需要升級怎么辦呢？用JLINK。不錯，不過有更直接的方法，如圖3.31所示。

圖3.31 APP燒錄BL區(qū)

這是一種逆向思維，我們在APP程序中也實現(xiàn)接收固件文件，暫存校驗，然后將其燒錄到BL區(qū)。這種作法與Bootpatcher同理，也是有一定風(fēng)險的，但一般都沒有問題。

OK，本章對BL進(jìn)行了詳盡的剖析講解，應(yīng)該作到了深入淺出，包含基本的原理，以及實例的實現(xiàn)，還有一些知識的擴(kuò)展。這其中不乏振南的一些創(chuàng)新思想，希望能夠?qū)Υ蠹耶a(chǎn)生啟發(fā)，在實際的工作中將這些知識付諸實踐。

審核編輯：劉清