方 沖,任海蘭,王成麗
(武漢郵電科學研究院研究生院光纖通信技術和網絡國家重點實驗室,湖北 武漢 430074)
在嵌入式系統投入實際環境運行后,一旦用戶有新的需求或者原有系統出現問題時,就需要嵌入式系統在不斷電或保持系統正常運行的情況下,能夠通過外圍接口(JTAG口,網口或串口)實現對自身程序的更新,完成系統的在線升級。
隨著在線升級越來越多的應用到嵌入式系統中,一些在線升級方案逐漸被提出,當前嵌入式在線升級的方案主要有兩種典型的軟件架構:一是在Bootloader中嵌入通信模塊,對應用程序運行區直接進行更新[1-2],如圖1a所示;二是用兩個應用程序進行切換,即“雙系統”結構[3-4],如圖1b所示。其中第一種軟件架構的特點是結構簡單、易于實現但可靠性不高,第二種軟件架構的特點是可靠性高,但實現起來較為復雜,所占資源較多。結合這兩種解決方案的特點及其適用范圍,本文在第一種軟件架構的基礎上提出了一種可靠性好、靈活度高的在線升級解決方案,并給出了其具體的實現。

圖1 升級系統典型的軟件架構
為了適應對可靠性、靈活性要求較高的嵌入式應用系統,設計了一種改進的方案,其軟件架構由Bootloader工程和應用程序工程構成,如圖2所示。其與圖1a的主要區別如下:一是增加了應用程序的備份區,每次升級時首先拷貝至備份區,而不直接覆蓋運行區程序,這樣通信過程中出現錯誤不會導致破壞原有程序,提高了升級的可靠性;二是將升級過程劃分為兩個階段,第一階段將應用程序拷貝至備份區,第二階段完成備份區到運行區的拷貝,以便用戶靈活的控制升級傳輸與完成升級的時機,提高了升級的靈活性;三是將Bootloader劃分為不同的功能模塊,這樣只需要根據不同的硬件平臺完成相關的驅動及系統初始化模塊即可完成此系統的移植,提高了的通用性。

圖2 在線升級系統的軟件架構
此系統的主要工作流程為:1)Bootloader通過仿真器燒寫到MCU中,其作用是完成應用程序的升級及其引導;2)新的應用程序在用戶啟動升級后,通過Bootloader或原應用程序中的通信協議模塊拷貝到應用程序的備份區;3)對系統進行復位(跳轉到Bootloader的起始地址),由Bootloader中的升級模塊實現新應用程序對原應用程序的替換,并跳轉到應用程序執行區的起始地址,完成了應用程序的升級。
該系統的設計及實現是基于 Freescale MC9S12XD256[7-8]芯片,該芯片以S12 CPU為內核,帶有256 kbyte的片內Flash,4 kbyte的片內E2PROM,14 kbyte的RAM,其中256 kbyte的Flash劃分為16個Page,每個Page為16 kbyte,其邏輯地址為:

S12的CPU有一個Page寄存器,其尋址方式是Page寄存器(相當于基址)+PC寄存器(相當于偏移地址),完成邏輯地址到物理地址的映射。
該系統的軟件環境為CodeWarrior開發工具,采用C語言進行開發,經過CodeWarrior編譯出來的S19程序文件,其格式為ASCII編碼的S-record格式。為了方便下位機進行解析,可以把S19文件轉化為.bin文件,并自定義其格式,加入CRC校驗部分以保證傳輸的正確性,關于此部分細節,請讀者查閱相關的文獻,在此不作詳細闡述。
經過CodeWarrior編譯出來的代碼,其地址是不連續的,經過分析S19文件,可將生成的代碼分為代碼段(Code)、庫函數段(Lib)、中斷向量段(2nd ISR),其中系統自帶的中斷向量段地址是不變的(MYMFF00-MYMFFFF),為了方便升級,在此設計了二級中斷向量,完成系統中斷向量到自定義二級中斷向量的映射。根據以上分析,可對Flash作如下分割(邏輯劃分):

其中中斷向量是兩個工程所共用的,分配其存儲區時只需要劃分一組。
在此系統中,Bootloader劃分為4個模塊,系統初始化模塊、升級控制模塊、Xmodem通信模塊、命令行模塊,其流程圖如圖3所示。系統初始化模塊主要完成時鐘的初始化、串口的初始化、中斷的初始化以及定時器的初始化,為其他模塊的運行準備條件;升級控制模塊主要完成應用程序備份區到運行區拷貝的操作,以及應用程序的引導,當系統中只有Bootloader或者升級第二階段拷貝失敗時,會保持在Bootloader的主循環中運行;Xmodem通信模塊實現了系統同上位機的通信;命令行模塊提供給用戶靈活控制升級的接口,下面詳細介紹Xmodem通信模塊及命令行模塊的實現。
Xmodem協議是一種串口通信中廣泛用到的異步文件傳輸協議。分為標準Xmodem和1k-Xmodem兩種,前者以128字節塊的形式傳輸數據,后者字節塊為1 kbyte,并且每個塊都使用一個校驗和過程來進行錯誤檢測。Xmodem協議的格式如圖4所示。其中,SOH為幀頭(1字節);信息包序號為當前信息包號(1字節),范圍為0~255;信息包序號的補碼為當前信息包號的補碼(1字節);數據區段為數據區段的長度固定為128字節(如果是1k-Xmodem則為1024 字節);算術校驗和為1字節的算術校驗和,只對數據區段計算后對256取模(如果是1k-Xmodem則為CRC校驗)。

在此系統中,通過一個狀態機實現了Xmodem協議的接收端,發送端可用PC提供的超級終端,Xmodem狀態機如圖5所示。

圖5 Xmodem狀態機
其數據結構定義如下:


根據Xmodem的狀態機,用switch結構實現其主流程,并完成每個狀態下的處理函數,即可完成Xmodem協議的接受端。
命令行模塊是升級系統與用戶之間的接口,方便用戶靈活地控制升級時機,其至少需要提供兩個接口:1)啟動Xmodem進行文件傳輸的接口;2)提供對系統進行復位的接口。其中第一個接口配合Xmodem完成升級文件到應用程序備份區的拷貝,第二個接口是系統跳轉到Bootloader起始地址,完成程序的更新。
命令行可以實現為,通過匹配命令接口,然后調用其對應的回調方式,其數據結構定義如下:

通過實現命令處理函數CLI_ProcFWDL(VOID),CLI_ProcSWRST(VOID)即可完成命令行模塊的設計。
按照前面所述的硬件結構和軟件實現搭建好測試環境后,將1.0版本的 Bootloader燒寫到Flash,將1.0版本的應用程序通過PC機提供的超級終端下載至備份區并升級到運行區,如圖6所示。
1)功能性測試。由圖6可知,應用程序能夠成功的從1.0版本升級到1.1版本,Bootloader版本在必要時(一般不需要升級Bootloader)也能夠升級到1.1版本。
2)穩定性測試。在通信的過程中斷電或者取消Xmodem的傳輸,升級標志位不會被置,系統均能夠保持在應用程序的當前版本運行;在從備份區拷貝至執行區的過程中斷電,當前版本的應用程序被破壞,但系統能夠維持在Bootloader中的while(1)循環中運行,由于此過程所需時間很少(100 ms級),此種情況發生的概率很小,而且一旦出現,系統能夠通過再次升級,恢復至原應用程序。
3)靈活性測試。在此系統中用戶可以靈活地控制下載新程序,以及升級到新程序的時機,在新程序成功下載到備份區之后,只要用戶不發Boot命令或遇到異常重啟,系統均不會更新至新版本,而保持在當前版本運行。

圖6 在線升級系統測試結果
本文結合嵌入式產品的在線升級的需求,對比了兩種升級方案的實現,提出了一種改進的在線升級方案,由測試結果可以看出,該方案可靠性好、靈活度高、通用性強,設計達到了預期效果。該系統已成功應用于基于Freescale MC9S12XD系列單片機的嵌入式系統中,對實際的嵌入式應用有一定的參考意義。
[1]武國平,史儀凱.ARM7處理器Bootloader的設計與實現[J].微處理機,2010,31(5):103-106.
[2]鄧中亮,孫靜.嵌入式設備在線系統升級的設計與實現[J].計算機工程與設計,2009,30(13):3085-3087.
[3]尹恒,嚴華.一種針對嵌入式遠程升級安全的存儲解決方案[J].計算機應用,2011,31(4):992-994.
[4]王恒,王颋,王泉,等.基于Bootloader的可靠嵌入式軟件遠程更新機制[J].微計算機信息,2007,20:57-59.
[5]聶章龍,王宜懷.Freescale HC08系列MCU集成開發系統的若干關鍵技術[J].計算機工程與設計,2010,31(3):518-520.
[6]馬學文,朱名日,程小輝.嵌入式系統中Bootloader的設計與實現[J].計算機工程,2005,31(7):96-97.
[7]孫同景,陳桂友.Freescale 9S12十六位單片機原理及嵌入式開發技術[M].北京:機械工業出版社,2008.
[8]邵貝貝.單片機嵌入式應用的在線開發方法[M].北京:機械工業出版社,2004.