設(shè)備OTA空中升級原理
1. 背景
沒有完美的軟件,因為設(shè)計缺陷、業(yè)務(wù)需求更新,軟件始終都在不斷升級完善。新軟件如何替換正在運行的舊軟件就是本文關(guān)注的重點,尤其是針對電子產(chǎn)品,設(shè)備空中升級OTA,受限于硬件資源,需要選擇不同的方案進行軟件升級。
2. 空中升級流程
在線升級流程,簡化就是設(shè)備運行舊軟件的同時,獲取新軟件包,再執(zhí)行特殊操作使用新軟件覆蓋舊軟件,最后運行新軟件。圖片根據(jù)硬件資源和系統(tǒng)整體框架,選擇不同的升級方案,方案需要結(jié)合實際選擇最佳的,技術(shù)層面是次要的。
3. 空中升級的方案
3.1. 整包升級
以STM8單片機升級為例,單片機最小系統(tǒng)運行流程如下:圖片要加入在線升級功能,就需要將主應(yīng)用程序拆分,類似有2套程序在設(shè)備內(nèi)運行,標準稱呼是bootload+app,其中bootload始終不變,它接收新軟件包并覆蓋app區(qū)域。
硬件限制 | 解決方案 |
---|---|
單片機自身沒有網(wǎng)絡(luò)連接功能,只能基于外掛的網(wǎng)絡(luò)模塊從遠端服務(wù)器下載新軟件包,再通過串口傳輸給單片機 | 由外掛主機下載新軟件包,并通知單片機進入升級模式 |
單片機內(nèi)部RAM小,不能進行復(fù)制運算或者緩存大量數(shù)據(jù);單片EEPROM小,不能保存完整的新軟件包 | 只能在Bootload期間分段接收新軟件并立刻寫入flash |
整體方案如下圖:
難點與風(fēng)險
單片機在app收到升級請求,需要重啟進入bootload,對于以單片機為主控的設(shè)備,需要保證單片機重啟期間網(wǎng)絡(luò)模塊不斷電,所以因升級進入bootload要立刻恢復(fù)網(wǎng)絡(luò)模塊主機供電,必要時需要硬件支持。
單片機ram和rom有限,采用分段接收新軟件包,直接寫入flash,因此在應(yīng)用層協(xié)議上需要確保數(shù)據(jù)包不會錯誤或遺漏或重發(fā),目前采用Ymodem協(xié)議居多。升級包需要轉(zhuǎn)成bin文件,單片機接收后寫到app的起始地址。
單片機分段接收后寫入flash,整個過程需要10秒以上,期間如果斷電,單片機軟件的app處于損壞狀態(tài),需要單片機有超時機制重啟,再次開啟升級并主動要求網(wǎng)絡(luò)模塊重傳新軟件包。
一般PC軟件無需考慮內(nèi)存和存儲空間,也是采用整包升級,兩個文件同時保存。例如app.exe運行時下載新的app_new.exe,下載校驗后,app.exe自毀刪除自身,然后將app_new.exe重命名為app.exe并啟動。
3.2. 差分升級
差分升級軟件框架同整包升級一樣,區(qū)別在于新軟件包的提供方式不同。
單片機軟件一般不超過50KB,復(fù)雜微處理器的軟件一般都比較大,但其RAM也大,下載完整的新軟件包耗時長且浪費流量,因此可以基于新舊兩版軟件的差異,將差異文件傳給設(shè)備,由設(shè)備運算還原出新軟件包升級。
難點與風(fēng)險
差分包的制作與還原算法驗證,在bootload還原出新軟件包時考慮到RAM,差分包是按塊生成,還原也是按塊執(zhí)行,每塊新軟件寫入前,需要先備份舊塊,防止異常斷電無法還原。圖片萬一出現(xiàn)異常,重啟還是進入bootlaod,查詢上次已經(jīng)還原到第幾塊,繼續(xù)后面操作。有些為了再次減小差分包大小,還會對文件進行壓縮,還原前先解壓。
升級時,必須保證生成的差分包是基于當(dāng)前設(shè)備內(nèi)運行的版本,如設(shè)備運行V01,但是提供的差分包卻是基于V02到V03的,則會導(dǎo)致異常?;蛘咴谖募蓄A(yù)設(shè)特殊版字符,版本匹配才進行差分還原升級。而整包沒有該缺點,只要bootlaod正常,任意app軟件版本可以互相升級。
3.3. 動態(tài)加載
動態(tài)加載在PC軟件中很常見,多個exe可執(zhí)行文件共用dll庫文件,這樣exe文件很小,缺點是要保證exe正常運行,需要在指定的路徑下存放dll文件。圖片對嵌入式平臺,動態(tài)加載的可以理解為始終保持底層基礎(chǔ)框架不變,修改或替換不同的上層業(yè)務(wù)邏輯,實現(xiàn)不同的效果。為保證底層和上層之間調(diào)用關(guān)系,必須固定部分接口地址,也就是兩者中間的接口映射,主要通過鏈接實現(xiàn)。圖片嵌入式軟件從源碼到可下載到設(shè)備的映像文件,需要經(jīng)過的步驟:圖片動態(tài)加載就是在鏈接階段,將上層代碼obj編譯成axf可動態(tài)加載的文件,而不是直接與其他obj合并成可執(zhí)行文件。主要是使用armlink配置-entry指定映像文件的初始入口點或者在代碼中使用#pragma arm section code關(guān)鍵字,保證動態(tài)的上層有固定的入口地址。凡是上層調(diào)用的底層接口,在編譯階段函數(shù)體指針都賦為空指令保證編譯,后續(xù)再指向底層的真實地址。圖片
其作用發(fā)生在系統(tǒng)啟動階段,從flash加載到內(nèi)存,整個文件內(nèi)的接口相對地址不變,整體偏移。這樣,軟件還是可以計算獲取動態(tài)映像文件的入口地址。加載到內(nèi)存區(qū)域,需確保該區(qū)域不會被占用,否則內(nèi)存覆蓋肯定會導(dǎo)致異常。
底層啟動后,只能查到動態(tài)加載文件的入口函數(shù),但實際底層與上層交互的接口肯定不止一個,而且上層也必然會調(diào)用底層接口,這就需要在第一個明確地址的函數(shù)體內(nèi)實現(xiàn)上下層地址映射。這里有2種方案,一種是函數(shù)指針賦值,一種是根據(jù)字符串查找。底層需要給上層調(diào)用的接口,底層映射接口函數(shù)指針表,按固定順序賦值給上層函數(shù)指針;或者底層只提供上層一個函數(shù),但是改函數(shù)體內(nèi)查字符串獲取函數(shù)指針。這樣實現(xiàn)上層調(diào)用事先固定的底層接口。
上層給底層提供的接口,也是提前固定的函數(shù)指針,也用上面的方法對接。接口映射的核心是動態(tài)加載塊有一個函數(shù)的地址是鏈接時指定的,在這個函數(shù)內(nèi)實現(xiàn)上下層函數(shù)映射。除函數(shù)外,全局變量也是同樣的使用指針傳遞。
難點與風(fēng)險
前面2種使用bootload+app的方案,屬于比較常規(guī)的方案,其本質(zhì)是一塊芯片運行2套互不干擾的軟件,而動態(tài)加載的上下層之間有固定的接口,不能使用接口以外的交互。
動態(tài)加載對鏈接和arm底層要求高,在升級方向應(yīng)用較少,因為對軟件開發(fā)接口使用存在限制,但動態(tài)加載實現(xiàn)了上下層隔離,避免代碼調(diào)用混亂,也為跨平臺、多語言開發(fā)提供了基礎(chǔ)。
4. 結(jié)論
在線升級為了產(chǎn)品在不召回的情況下,以較低的成本解決售后問題;升級是為了解決問題,但是一旦失敗則可能導(dǎo)致設(shè)備變磚。前期測試應(yīng)選擇不同設(shè)備模擬升級異常,如強制斷電或軟件包異常,設(shè)備必須有自我恢復(fù)的機制。
本文轉(zhuǎn)載自微信公眾號「嵌入式系統(tǒng)」,可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系嵌入式系統(tǒng)公眾號。