應用以太網總線的嵌入式軟件遠程升級系統設計及實現

李浩, 張亞琳, 關冰

(1.中國運載火箭技術研究院， 北京 100076；2.北京時代民芯科技有限公司， 北京 100076)

0 引言

隨著物聯網和5G等技術的發展，嵌入式軟件的應用場景也越來越廣泛，承擔的功能也越來越復雜，軟件交付后也可能需要進行功能升級[1-2]。以DSP(digital signal processing)為代表的嵌入式軟件開發，通常采用基于JTAG(joint test action group)的仿真器連接升級模式[3]，這種方法在實驗室環境下應用比較方便，但是在軟件固化到嵌入式硬件平臺后維護比較復雜，操作非常不便，必須將硬件平臺進行拆裝后再進行升級，明顯增加了運維的成本。

本文針對嵌入式軟件遠程升級的需求，設計基于以太網總線的遠程升級系統，只需要1臺筆記本就可以在不拆裝硬件平臺的前提下實現軟件升級?？紤]嵌入式軟件升級過程的可靠性與穩定性，設計指令-回令確認及三次重傳機制解決升級過程中可能出現的丟幀、錯幀和亂幀問題，設計有限狀態機及分區存儲機制保證升級失敗系統也可以正常啟動，在保證軟件升級速度的同時顯著提升可靠性。此外，設計上位機軟件對升級過程進行可視化監控，操作更加便捷。

1 總體方案設計

基于以太網總線的嵌入式軟件遠程升級系統由上位機、交換機和下位機3部分組成，拓撲結構見圖1。系統的通信中樞是交換機，用于上位機與不同下位機之間指令、回令的傳輸。系統的發起方是上位機，通過參數配置后開始嵌入式軟件的遠程升級，并對升級的過程進行實時監控。系統的接收方是下位機，接收到上位機的升級指令后進行狀態遷移、指令校驗和升級實現。

圖1 遠程升級系統拓撲結構

需要說明的是下位機運行的嵌入式硬件平臺中至少有一個版本的下位機軟件，遠程升級系統才能正常運行。當某下位機嵌入式軟件需要升級時，上位機軟件選擇最新版本的軟件，通過交換機將軟件分包傳輸到下位機，下位機校驗通過后將軟件存儲到Flash中。升級后系統可以選擇將固化到Flash的軟件回讀到上位機，用于進一步的校核確認。系統重啟后，如果升級成功,下位機將運行最新版本的軟件，否則將運行上一版本的軟件，基于以太網總線的遠程升級過程如圖2所示。

圖2 基于以太網總線的遠程升級過程

系統中上位機、交換機及每一個下位機都具有獨一無二的IP地址和端口，在系統中作為唯一的ID用于身份識別，本文設計的系統中有1個上位機、4個下位機及1個交換機。具體分配的IP地址及端口如表1。

表1 遠程升級系統地址分配表

2 總線協議設計

設計上位機與下位機之間的通信協議，采用實時性更高、基于無連接服務的UDP通信協議，除了幀內容區中包含有效數據外，還增加了幀頭、幀尾、校驗和等確認位域以實現對總線通信鏈路錯誤的檢測，采取指令-回令的協議應答機制作為超時重傳的通信協議基礎，采用分包機制對大數據量的二進制文件進行傳輸。以太網協議的指令格式見表2，回令格式見表3。

(a) 幀頭：固定幀頭為0x5A5A5A5A，用于判斷幀的開始；

(b) 幀長度：本幀的數據長度；

(c) 幀類型：本幀的數據類型，其中0表示升級第一幀，1表示升級中間數據幀，2表示升級最后一幀,3以上標識其他類型；

表2 以太網協議-指令

表3 以太網協議回令

(d) 二進制文件的大?。捍壾浖拇笮?，單位是B，幀類型的值為0～2時有效；

(e) 二進制文件的時間：待升級軟件的最后修改時間，比如2107151057表示2021年7月15日10點57分，幀類型的值為0～2時有效；

(f) 二進制文件的類型：待升級軟件的類型，0表示Core0軟件，1表示Core1軟件，以此類推，幀類型的值為0～2時有效；

(g) 二進制文件的CRC：待升級軟件的校驗碼，本文采用CRC16的方式進行校驗，幀類型的值為0～2時有效；

(h) 幀號：當前幀的編號，幀類型的值為0～2時有效；

(i) 幀內容區：通信協議幀的具體內容，幀類型的值為1時有效，固定長度1 200 B，采用分包傳輸的方式傳輸二進制文件，最后一幀不滿1 200 B的部分填充為0,回令的幀內容區含義為對指令的內容和升級的過程進行判斷，固定長度是4 B，狀態碼的具體含義見表4；

(j) 幀校驗和：對本幀數據前N-4個字節進行CRC校驗，采用CRC16的方式進行校驗；

(k) 幀尾：固定幀尾為0x6B6B6B6B，用于判斷幀的結束。

表4 狀態碼設計

3 上位機軟件設計

3.1 界面設計

利用LabWindows/CVI開發平臺設計上位機監控軟件，該平臺的優點是控件資源豐富，具備很好的虛擬儀器工具支持，支持C語言開發，廣泛應用于測控領域[4]。上位機界面主要由以下幾部分組成：初始化基本設置、XML配置、文件選擇、運行狀態、接受內容、發送內容、數量統計、返回上級。上位機軟件界面如圖3所示。

圖3 上位機軟件界面示意圖

(a) 初始化基本設置主要完成上位機IP地址和端口、下位機IP地址和端口、Internet地址族和傳輸層協議棧的設置；

(b) XML配置用于遠程升級總線協議的加載、修改和保存，通過配置XML文件可以在不改變軟件代碼的情況下實現通信協議的改變，XML的部分內容如下：

〈Number id="01"〉

〈Name〉幀頭〈/Name〉

〈Length〉4〈/Length〉

〈DefaultValue〉5A5A5A5A〈/DefaultValue〉

〈/Number〉

(c) 文件選擇用于待升級的軟件和需要回傳的軟件絕對目錄的選擇；

(d) 進度條是對遠程升級的進度進行監控；

(e) 運行狀態是對遠程升級的狀態進行監控；

(f) 接受內容是對接收的協議數據進行顯示；

(g) 發送內容是對發送的協議數據進行顯示；

(h) 數量統計是對發送的協議幀和接收的協議幀數量進行顯示；

(i) 返回上級是返回上級目錄。

3.2 流程設計

當用戶完成嵌入式軟件的文件選擇，點擊裝訂按鈕后，主要執行如下流程：

(a) 打開嵌入式軟件的二進制文件，獲取軟件的大小、時間、類型及CRC信息，讀取文件中的二進制數據到緩存區；

(b) 根據第2節設計的總線通信協議完成第一幀的組幀，采用超時重傳的方式發送第一幀，確保傳輸的可靠性，具體重傳過程見圖4；

(c) 開始中間數據幀的組幀和發送，發送方式與第一幀相同；

(d) 開始最后一幀的組幀和發送，發送方式與第一幀相同；

(e) 升級過程中異常信息在狀態欄進行打印，升級的進度條根據當前發送的幀數實時更新。

圖4 基于以太網的指令-回令-結果超時重傳流程圖

4 下位機軟件設計

4.1 有限狀態機設計

采用有限狀態機的設計理念描述下位機嵌入式軟件的工作流，利用有限狀態機的事件觸發轉移機制，根據不同的測試指令完成狀態的遷移[5]，設計下位機軟件的工作過程。狀態機實現的過程要點如下：

(a) 狀態：軟件當前所處的階段稱為狀態，包括初始狀態、終止狀態及其他可能處于的階段；

(b) 事件：觸發狀態發生遷移的條件稱為事件，當事件發生時，軟件會響應事件，發生狀態遷移，從當前狀態遷往新狀態；

(c) 動作：軟件狀態遷移后執行的工作稱為動作，動作執行完畢后，可保持當前狀態，也可以遷移到新狀態；

(d) 狀態機：從初始狀態開始，到終止狀態停止，連接軟件的所有中間狀態，并標注事件和動作，這樣的狀態轉移過程稱為狀態機。

根據下位機嵌入式軟件的系統功能，設計實現了5個動作、7個事件、5種狀態，并形成1個狀態機，具體內容如圖5所示。

圖5 下位機軟件狀態機

(a) 動作1：進行軟件及硬件初始化；

(b) 動作2：進行以太網指令解析；

(c) 動作3：進行業務邏輯處理；

(d) 動作4：執行下位機軟件的升級；

(e) 動作5：進行異常處理和狀態上報；

(f) 事件1：動作1完成；

(g) 事件2：以太網指令解析結果是非升級指令；

(h) 事件3：業務邏輯后T，本軟件設置為120 s；

(i) 事件4：以太網指令解析結果是升級指令；

(j) 事件5：與事件4相同；

(k) 事件6：檢測到系統異常，如棧溢出、內存越界訪問等；

(l) 事件7：與事件6相同；

(m) 初始狀態：下位機軟件啟動后的狀態，執行動作1，檢測到事件1時遷移到空閑狀態；

(n) 空閑狀態：下位機軟件等待工作指令的狀態，執行動作2，檢測到事件2時則遷移到工作狀態，檢測到事件4時則遷移到升級狀態；

(o) 工作狀態：下位機軟件執行業務邏輯的狀態，執行動作3，檢測到事件3時則遷移到空閑狀態，檢測到事件5時則遷移到升級狀態，檢測到事件6時則遷移到終止狀態；

(p) 升級狀態：下位機軟件進行軟件升級的狀態，執行動作4，檢測到事件7時則遷移到終止狀態，為了保證升級過程中不被干擾，軟件進入升級狀態時只執行升級動作，不進行業務處理，只能遷移到終止狀態，不能遷移到工作狀態和空閑狀態；

(q) 終止狀態：下位機軟件出現異常時的狀態，執行動作5，終止狀態不進行任何狀態的遷移；

(r) 狀態機：上述的狀態、事件、動作及狀態轉移過程。

下位機軟件開發時可以采用基于裸機或者基于實時操作系統的設計模式:如果是基于裸機，在以太網中斷中獲取信息并進行判斷，通過置標志的方式實現主循環不同狀態的遷移；如果是基于實時操作系統，在以太網任務中獲取信息并進行判斷，通過信號量或者消息隊列等方式實現不同狀態任務的遷移。

4.2 主備分區設計

嵌入式軟件升級的Flash分區有2種方案：第一種是直接覆蓋，第二種是主備分區。第一種方案在進行軟件升級時，先把二進制文件緩存在到DDR存儲器上，完成校驗后燒寫到Flash，并將上一版本的二進制文件覆蓋。該方案的優點是占用存儲空間少、流程簡單，但是也存在可靠性不高的問題：如果在軟件升級過程中因為外部干擾導致升級異常，在重新上電后嵌入式軟件將無法正常啟動，并無法與上位機通信，只能用傳統JTAG(joint test action group)掛接仿真器的方式升級軟件，帶來額外的工作。第二種方案是在進行軟件升級時，先把二進制文件緩存到DDR存儲器上，完成校驗后燒寫到Flash，但是保留上一版本的二進制文件，將最新的軟件燒寫到備分區。該方案的確定占用存儲空間大、流程復雜，但是能夠在升級出錯的情況下正常啟動，可靠性顯著提高。

對2種方案的優劣勢進行分析，本文采用主備分區的方案對存放二進制文件的Flash空間進行了重新編排,如圖6所示。在Flash存儲區之后設計了3個二進制文件存儲區，其中:一個存儲區用于存放當前要啟動的最新二進制文件，稱為主分區；一個存儲區用于存放上一版本的二進制文件，稱為備分區；一個存儲區用于存放第一次燒寫的二進制文件，稱為零分區。主分區和備分區存放內容不是一成不變的，將隨著軟件的更新而動態交替變化。此外，單獨設計一個參數存儲區，供Boot Loader程序識別哪個是主分區，哪個是備份區，是否需要啟用零分區，便于嵌入式軟件的引導。

圖6 下位機FLASH存儲布局

當Boot Loader引導主分區文件失敗后，將尋找備分區的文件進行引導，如果再次引導失敗，將尋找零分區的文件進行引導。通過主備分區、異常檢測及主動回滾機制，當嵌入式軟件升級過程遇到了異常時，也可以正常實現軟件的引導，顯著提高了軟件遠程升級的可靠性。

4.3 升級流程設計

下位機軟件進入到升級狀態后，工作流程如下：

(a) 軟件收到每一幀數據后根據第3節通信協議進行校驗。如果校驗通過則執行發送回令，并執行(b)，如果校驗不通過則執行(f)。

(b) 判斷該幀類型。如果是第一幀，轉到(c);如果是中間數據幀，轉到(d);如果是最后幀，轉到(e);如果是其他幀，執行(f)。

(c) 如果是第一幀，讀取幀協議中的二進制文件長度、時間及類型信息，并將這些信息寫到Flash中，并根據幀協議中的長度大小擦出Flash的扇區。

(d) 如果是中間數據幀，讀取本幀的長度，并將內容緩存到DDR3中。

(e) 如果是最后幀，將DDR3中緩存的數據寫到Flash的相應區域中，對Flash中的數據進行CRC校驗，與最后幀中的CRC結果進行比對。

(f) 判斷當前出錯的類型：幀頭校驗錯誤、Flash讀異常、Flash寫異?；蛘逨lash擦異常等，并發送到上位機監控軟件。

5 試驗結果

本設計試驗驗證的下位機軟件運行環境是TMS320C6678開發板，TMS320C6678是一款多核DSP處理器芯片，片內集成8個C66x內核[6]，本系統中主要運行下位機嵌入式軟件，掛接一路網口用于與上位機監控軟件的通信。交換機采用工業級交換機，上位機軟件運行在商用筆記本。

對嵌入式軟件1進行遠程升級測試，上位機監控升級過程如圖7所示，Wireshark監控升級過程如圖8所示。測試結果表明上位機界面結果顯示正常，以太網軟件升級方法經驗證有效可行。

圖7 上位機監控遠程升級過程示意圖

6 總結

本文針對嵌入式軟件固化后升級流程復雜的問題，提出了一種基于以太網總線的遠程升級方案，對通信協議、升級流程、上位機及下位機軟件的可靠性增強設計，顯著地降低升級難度，提高升級的效率和可靠性。本文提出的方法在基于TMS320C6678 DSP的嵌入式軟件升級系統中進行了驗證，實驗結果表明方法設計正確，具有一定的通用性和實操性，可以推廣到其他嵌入式系統中。