剖析MCU的IAP升級軟件設計思路

關注、星標公衆,不錯過精彩內容

轉自公號:最後一個bug

二次整理:strongerHuang

做軟件開發的人,都知道程序升級。升級的方式有很多,今天就來講講升級的軟件的設計思路。

一、ISP/ICP/IAP名稱解釋

在我們學習MCU的過程中經常看到IAP、ISP、JTAG等等一些與在線編程相關的專業名詞,可能很多小夥伴到現在都迷迷糊糊的,這裏簡單爲大家介紹一下:

1)ICP -(In-circuit programmer)  

ICP表示在電路編程,MCU內部不需要有程序,直接上電就能夠進行對程序存儲區域進行編程的方式,我們平時使用JTAG或者SWD等等就屬於這種方式。

2)ISP - (In-system programer) 

ISP表示在系統編程,通過MCU專用的串行編程接口進行編程,那也就是說MCU需要具有運行的外部條件,比如需要有晶振等等。比如說平時使用的stm32通過設置boot引腳設置對應啓動模式,然後通過串口等對內部Flash進行升級,可以說這種方式就是廠家在芯片內部固化了一個BootLoader程序。

3)IAP - (In-application programer) 

IAP表示在應用編程,這種名詞應該是大家在平時學習過程中見得比較多的,相當於自己定製一個BootLoader程序,自己通過編程設計可以實現各種升級的方式比如串口、CAN、以太網等等,非常的靈活。其實這個BootLoader程序也是我們自己設計的程序,你也可以認爲是一個App程序,相當於通過對App劃分職責對自己進行更新和升級。這種方式也就是我們今天話題的主角。

二、MCU軟件升級設計思路

對於我們的MCU現在大部分的都是使用Flash來存儲程序,同時程序內部也會有讀寫Flash的接口函數,中斷也可以方便的重定位,這樣就非常適合IAP程序的開發。

1)IAP升級V1.0

升級軟件設計圖:

我們把MCU的Flash分區分爲如上圖所示的三個部分,Bootloader就是我們所要編寫的啓動程序,App程序爲項目的實際應用程序,Param區域是用於存儲相應的版本App的版本信息以及完整性校驗標誌序列等傳遞數據區域。

工作方式1:當MCU啓動以後運行Bootloader程序,檢測到Param參數區域是否存在App記錄,如果存在App直接運行App程序即可,如果不存在,則向PC機請求App文件。

工作方式2:當MCU運行App過程中,接收到PC機的升級請求,更新Param參數區域,並跳轉到BootLoader進行App程序的接受和升級,升級完成以後處理Param參數區域並運行對應的新App程序。

V1.0算是比較常規的應用案例,我們都知道對MCU內部Flash進行編程一般會有解鎖、擦除、寫入和驗證幾個階段,當我們擦除原來MCU存儲的App程序以後如果手頭上沒有相關的固件,基本上就不能恢復了,這樣如果我們想退回到之前的版本不可能了!於是升級方案還需要在改善一下。

2)IAP升級V2.0 

爲了解決V1.0提出的問題我們App分成了兩部分如下圖所示:

解析一下:上面兩張圖的原理是一樣的,都是把接收到的新App保存起來(如果你用於備份老的App也是可以的),圖1是通過把MCU內部Flash進行劃分,一部分用於存儲新App,另外一部分是原來運行的App區域,這樣的話,當我們通過bootloader接收完完整的新App進行校驗、解密處理以後便可以寫入到平時運行的App區域,從而防止了V1.0在升級過程中掉電、通信異常導致擦除了App的問題。

同時,我們也可以把上一版本App備份到我們預留的內部Flash或者外部存儲設備中,如果想還原系統即可直接通過PC發送相應命令進行恢復即可。

好了,又有小夥伴提出問題,大家都知道我們自己編寫的BootLoader是非常靈活的,可以支持多種通信協議的升級模式,不過在前期我們可能沒有考慮完善,後續想進一步完善相應功能就需要我們對Bootloader進行升級,那麼我們可以通過App對Bootloader進行升級操作,一般這種方式就可以滿足需求,不過如果在升級BootLoader過程中發生故障,那Bootloader全部被擦除導致整個MCU變成了個磚頭。好吧,是時候上V3.0版本的IAP程序了。

3)IAP升級V3.0 

爲了解決V2.0問題,作者設計了第三種升級方式:

解析一下:在V2.0的基礎上我們增加了Bootloader2,對於Bootloader1相當於固化在MCU中自定義的一種升級方式,而Bootloader2是可以根據我們啓動升級需求進行升級的區域,這樣即使在升級過程中擦除,我們也可以通過BootLoader1或者App2來進行恢復Bootloader2。

不過具體的實現過程會設計到較多的邏輯處理,大家在實現該方案的同時需要前期進行軟件上的設計和梳理。

免責聲明:本文轉自最後一個bug,版權歸原作者所有。如涉及作品版權問題,請與我聯繫刪除。

推薦閱讀:

幾種常見的校驗算法

爲什麼IoT設備的操作系統選用RTOS

分享一篇專治MCU各種 HardFault 的庫

關注微信公衆號『strongerHuang』,後臺回覆“1024”查看更多內容,回覆“加羣”按規則加入技術交流羣。

長按前往圖中包含的公衆號關注

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章