(蘇州大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，江蘇 蘇州 215006)

隨著人工智能的進(jìn)一步發(fā)展，數(shù)據(jù)的價值變得彌足珍貴。萬物互聯(lián)的時代即將來臨，物聯(lián)網(wǎng)正在引發(fā)第四次工業(yè)革命，各種物聯(lián)網(wǎng)創(chuàng)新應(yīng)用也在不斷涌現(xiàn)[1]。嵌入式設(shè)備作為物聯(lián)網(wǎng)技術(shù)的重要物理載體，其功能的穩(wěn)定性和適應(yīng)性面臨著巨大挑戰(zhàn)，隨之也帶來了頻繁的程序更新需求。

傳統(tǒng)的程序更新操作是通過基于JTAG協(xié)議的調(diào)試器完成的。JTAG(聯(lián)合測試工作組)協(xié)議是IEEE(電氣和電子工程師協(xié)會)于1990年對1149.1-1990號文檔標(biāo)準(zhǔn)化得到的國際標(biāo)準(zhǔn)測試協(xié)議，主要用于芯片內(nèi)部測試和程序調(diào)試[2]。該方法可以很好地提供程序燒錄和調(diào)試功能，但是有如下缺點(diǎn)：① 需要有調(diào)試器支持，價格昂貴；② 傳輸距離有限；③ 更新過程不可控，若燒錄的程序存在問題，設(shè)備可能直接死機(jī)。

為避免這些缺點(diǎn)，目前主要是利用MCU的Flash存儲器在線編程功能[3]，采用在BootLoader程序中增加數(shù)據(jù)通信驅(qū)動，并實(shí)現(xiàn)數(shù)據(jù)接收和燒錄的功能。BootLoader程序?yàn)镸CU上電之后運(yùn)行的一小段程序，可由編程人員自行編寫。BootLoader程序中的數(shù)據(jù)通信方式主要有兩種：有線通信和無線通信，無線通信由于脫離了線的束縛，可以做到傳輸距離更遠(yuǎn)和密封性更好，但是，由于無線通信存在抗干擾能力弱、信息出錯概率大、易遭受攔截和篡改、安全性差和信息傳輸可能需要付費(fèi)等缺點(diǎn)，故選擇了有線通信作為研究對象。有線通信方式包括：串口通信、SPI通信、I2C通信、CAN通信等。幾乎所有的MCU都提供串口通信功能，而且通信速度、容錯性、安全性都很好，在搭配了RS485或RS232之后，還可以實(shí)現(xiàn)遠(yuǎn)距離傳輸。因此，本文提出了一種基于串行通信技術(shù)的嵌入式終端程序更新技術(shù)。

1 系統(tǒng)框架介紹

提出并實(shí)現(xiàn)了一套基于串口通信的遠(yuǎn)程更新系統(tǒng)，可大大延長更新終端程序的限制距離，而且無需購買專門的調(diào)試器。串口更新系統(tǒng)的整體框架主要包括3個部分:終端(UE)、信息郵局(MPO)和上位機(jī)管理(HCM)，它們的對應(yīng)關(guān)系如圖1所示。

圖1 串口更新系統(tǒng)框架

本系統(tǒng)的硬件部分為基于KL36芯片自行設(shè)計(jì)的開發(fā)板。KL36芯片為恩智浦公司開發(fā)的一款A(yù)RM Cortex-M0+內(nèi)核的微控制器，主頻可達(dá)48 MHz[4]。軟件部分包括終端程序的BootLoader程序和User程序，以及上位機(jī)的串口更新程序HCM。

圖1中，User程序?yàn)橛脩舫绦?，設(shè)備為用戶提供的所有功能均在該程序中實(shí)現(xiàn)。因此，對用戶來說，終端程序更新即為User程序更新。BootLoader程序中包含終端設(shè)備的基礎(chǔ)硬件驅(qū)動，它通過串口接收上位機(jī)管理HCM程序發(fā)送來的更新數(shù)據(jù)，并使用Flash存儲器在線編程技術(shù)覆蓋原有的User程序，從而完成串口更新操作。

2 終端程序設(shè)計(jì)

BootLoader程序?yàn)楣袒贔lash中，是不容更改的程序，向User程序提供最底層、最直接的硬件配置和控制接口，并提供更新User程序的功能。User程序?yàn)榍度胧浇K端的功能程序，負(fù)責(zé)實(shí)現(xiàn)嵌入式終端所需的功能。在存儲上，BootLoader和User通過劃分存儲區(qū)域，實(shí)現(xiàn)共存。終端的Flash和RAM存儲映像如圖2所示。

圖2 終端Flash和RAM存儲映像

2.1 BootLoader程序

MCU上電之后至執(zhí)行main函數(shù)的流程為：在MCU上電之后，芯片內(nèi)部機(jī)制將把Flash中0x00000000～0x00000003地址的4個字節(jié)內(nèi)容賦給內(nèi)核寄存器SP(堆棧指針)，然后把Flash中0x00000004～0x00000007地址的4個字節(jié)內(nèi)容賦給內(nèi)核寄存器PC(程序計(jì)數(shù)器)。Flash中0x00000004～0x00000007地址中一般存儲啟動函數(shù)的地址，具體內(nèi)容查詢芯片的啟動文件，本系統(tǒng)中的啟動文件為“startup_MKL36Z4.S”。至此，PC寄存器中的內(nèi)容為啟動函數(shù)地址，因此，MCU會執(zhí)行啟動函數(shù)。啟動函數(shù)中一般將執(zhí)行如下操作：① 根據(jù)設(shè)置開關(guān)看門狗；② 初始化系統(tǒng)時鐘；③ 開啟GPIO(通用輸入輸出)端口時鐘門；④ 將Flash中的初始化數(shù)據(jù)(一般存儲在data段)拷貝至RAM中；⑤ 清零未初始化的bss段；⑥ 跳轉(zhuǎn)到main函數(shù)或_START函數(shù)(_START函數(shù)為系統(tǒng)函數(shù)，會自動跳轉(zhuǎn)到main函數(shù))。至此，MCU啟動完成，并進(jìn)入了main函數(shù)[5]。

由圖2可知，MCU上電之后默認(rèn)執(zhí)行的程序?yàn)锽ootLoader程序，該程序的執(zhí)行流程如圖3所示。

BootLoader程序首先進(jìn)行初始化操作，之后將會判斷當(dāng)前Flash中是否已經(jīng)燒錄了User程序。User程序與BootLoader程序在物理上是分開的，BootLoader程序很難判斷User程序是否存在并且完整。但是，經(jīng)過研究發(fā)現(xiàn)，可以通過判斷User程序的MSP指針(該指針位于程序起始地址的第4～7個字節(jié))是否正確來判斷是否有User程序。

若存在User程序，則需要判斷User程序是否需要更新。判斷是否需要進(jìn)行程序更新的方法有很多種，如：① 文獻(xiàn)[6]和文獻(xiàn)[7]提出了重啟時等待更新命令一段時間的方法，該方法需要手動重啟，且每次上電均需要等待一段時間，既不方便操作，也大大增加了開機(jī)時間；② 文獻(xiàn)[8]提出了通過讀取引腳狀態(tài)決定是否需要程序更新的方法，該方法需要在更新前設(shè)置好引腳狀態(tài)，不方便應(yīng)用；③ 文獻(xiàn)[9]提出了基于CAN總線的程序升級方法，但CAN總線功能僅部分終端支持，不具有普適性。

圖3 BootLoader程序執(zhí)行流程圖

基于對以前文獻(xiàn)等資料的總結(jié)和實(shí)踐經(jīng)驗(yàn)，提出了基于RAM在熱復(fù)位時數(shù)據(jù)不丟失特點(diǎn)實(shí)現(xiàn)的在線串口更新方法。由圖2可知，0x1FFF_F800～0x1FFF_F80B是一段既不屬于BootLoader程序又不屬于User程序的RAM。因此，在熱復(fù)位時，該段數(shù)據(jù)可以保存。當(dāng)終端UE接收到上位機(jī)管理程序HCM更新命令之后,將更新命令寫入該段RAM并重啟，在重啟的時候只需要判斷該段RAM中的數(shù)據(jù)是否為更新命令即可知道是否需要更新程序。

至此，BootLoader程序完成了串口更新所需要的功能。下面將闡述技術(shù)的實(shí)現(xiàn)方案：終端的外設(shè)驅(qū)動都已經(jīng)包含在BootLoader程序的工程中，因此，在燒錄BootLoader程序之后，這些驅(qū)動將會被存儲在終端的Flash中。為了在User程序中可以使用燒錄在Flash中的驅(qū)動程序，需要在BootLoader程序中將這些驅(qū)動的接口(即入口函數(shù))存儲在Flash的指定區(qū)域中。User程序?qū)腇lash中的該區(qū)域?qū)⑦@些驅(qū)動的接口讀出并轉(zhuǎn)化為函數(shù)指針，然后User程序即可通過函數(shù)指針使用固化在Flash中的驅(qū)動。

2.2 User程序

上電之后，在BootLoader程序處理完相應(yīng)操作后將會跳轉(zhuǎn)至User程序。跳轉(zhuǎn)方法為：將當(dāng)前MSP指針更改為User程序的MSP指針，同時將User程序第4～7字節(jié)的數(shù)據(jù)作為函數(shù)指針并調(diào)用，該操作將使得MCU進(jìn)入User程序的復(fù)位函數(shù)中。User程序的執(zhí)行流程如圖4所示。

圖4 User程序的執(zhí)行流程

本系統(tǒng)實(shí)現(xiàn)了無需手動重啟的嵌入式終端串口更新功能。該功能是在串口中斷中實(shí)現(xiàn)的，串口中斷的服務(wù)例程位于BootLoader程序中，通過將中斷向量表拷貝至RAM的指定位置，使得User程序中觸發(fā)串口中斷時依然能夠進(jìn)入BootLoader程序區(qū)的中斷服務(wù)例程，從而觸發(fā)更新操作。

同時，利用函數(shù)指針，本系統(tǒng)將終端基礎(chǔ)硬件資源的驅(qū)動存儲在BootLoader程序區(qū)中，并對外提供簡單的調(diào)用方法，達(dá)到了降低User程序編程難度和防止驅(qū)動被惡意修改的目的。

3 上位機(jī)程序設(shè)計(jì)

在完成終端程序的編碼之后，通過編譯系統(tǒng)，可以將程序編譯生成HEX文件。程序的燒錄過程即為解析HEX文件的含義，并將指定的數(shù)據(jù)寫入到終端設(shè)備的指定Flash中。這一過程需要由計(jì)算機(jī)程序完成，即本系統(tǒng)中的上位機(jī)管理HCM程序。

HCM程序?qū)EX文件進(jìn)行解析，并按照與BootLoader程序約定好的數(shù)據(jù)幀協(xié)議進(jìn)行組幀，然后將數(shù)據(jù)逐幀發(fā)送至BootLoader程序，由BootLoader程序完成更新User程序的操作。HCM程序主要的執(zhí)行流程如圖5所示。

3.1 HEX文件解析

HEX文件是可以燒寫到單片機(jī)中，被單片機(jī)執(zhí)行的一種文件格式。HEX文件以行為單位，每行為一條HEX記錄，每條記錄以冒號開始，共包含6段數(shù)據(jù)，如表1所示[10]。

3.2 數(shù)據(jù)幀協(xié)議設(shè)計(jì)

由于通信過程的復(fù)雜性，使得數(shù)據(jù)通信過程中有一定概率造成數(shù)據(jù)的丟失、錯位和錯誤等情況。數(shù)據(jù)通信協(xié)議是為保證通信雙方能夠進(jìn)行有效且可靠的數(shù)據(jù)通信而制定的一系列約定[11]。本系統(tǒng)采用固定位置的通信協(xié)議，即固定位置的數(shù)據(jù)具有固定的意義。

圖5 上位機(jī)程序的執(zhí)行流程

字段長度/B內(nèi)容開始標(biāo)記1字符“:”數(shù)據(jù)長度1數(shù)據(jù)區(qū)字節(jié)數(shù)偏移量2數(shù)據(jù)區(qū)中數(shù)據(jù)應(yīng)存儲的空間地址,記錄類型為數(shù)據(jù)記錄時有效記錄類型100:數(shù)據(jù)記錄;01:文件結(jié)束記錄;02:擴(kuò)展段地址;03:開始段地址;04:擴(kuò)展線性地址;05:鏈接開始地址數(shù)據(jù)區(qū)n取決于記錄類型校驗(yàn)和1除開始標(biāo)記和校驗(yàn)和之外的所有字段的所有字節(jié)之和的補(bǔ)碼

為了保證協(xié)議的可復(fù)用性，本系統(tǒng)將通信協(xié)議分為兩部分：通用數(shù)據(jù)幀協(xié)議和更新數(shù)據(jù)幀協(xié)議。通用數(shù)據(jù)幀協(xié)議如表2所示。

表2 通用數(shù)據(jù)幀協(xié)議

本協(xié)議用于實(shí)現(xiàn)上位機(jī)管理程序HCM與終端UE之間的數(shù)據(jù)通信，為了防止數(shù)據(jù)在傳輸過程中出現(xiàn)錯誤導(dǎo)致誤操作，在協(xié)議中增加了CRC校驗(yàn)(循環(huán)冗余校驗(yàn))來保證數(shù)據(jù)的完整性。CRC是一種多用于同步通信方式中的差錯檢出方式。在這種方式中，將所傳數(shù)據(jù)序列看成為高次多項(xiàng)式G(x)，將此多項(xiàng)式用預(yù)先規(guī)定的生成多項(xiàng)式P(x)去除，再將其余數(shù)碼附加在所傳數(shù)據(jù)的尾部一并傳送。在接收方，用同樣的生成多項(xiàng)式去除，若除得的結(jié)果余數(shù)值為零，則說明接收到的數(shù)據(jù)是正確的[12]。

當(dāng)command為4時，發(fā)送的有效數(shù)據(jù)為更新數(shù)據(jù)，其幀協(xié)議如表3所示。

表3 更新數(shù)據(jù)幀協(xié)議

更新數(shù)據(jù)是通過通用數(shù)據(jù)幀協(xié)議進(jìn)行通信的，即更新數(shù)據(jù)幀的全部內(nèi)容為通用數(shù)據(jù)中的有效數(shù)據(jù)。

4 實(shí)驗(yàn)驗(yàn)證與性能評測

將所設(shè)計(jì)的串口更新系統(tǒng)應(yīng)用在KL36硬件平臺上，并進(jìn)行性能評測。本次評測的主要目的是檢測所設(shè)計(jì)系統(tǒng)的可靠性、穩(wěn)定性和更新速度。為了方便快捷地檢測本系統(tǒng)，編寫了一套自動燒錄1000次的上位機(jī)程序，程序界面如圖6所示。

上位機(jī)管理程序HCM主要有4個功能區(qū)，具體功能區(qū)的含義如表4所示。

表4 功能區(qū)功能表

基于該測試程序做了兩項(xiàng)測試：可靠性測試和更新速度測試，具體如下。

(1) 可靠性測試。取3個終端設(shè)備(命名為A,B,C)。其中，A放置于室內(nèi)環(huán)境中，B放置于潮濕的環(huán)境中，C放置于電磁干擾嚴(yán)重且周圍有大功率電器的環(huán)境中。分別使用本測試程序和JTAG調(diào)試器將User程序燒錄至設(shè)備。使用的User程序的HEX文件大小為57 KB，被上位機(jī)管理程序HCM切割為53幀。記錄燒錄的成功次數(shù)、失敗次數(shù)和成功率。測試結(jié)果如表5所示。

表5 可靠性測試結(jié)果

圖6 串口更新系統(tǒng)測試程序

由表5可知，本系統(tǒng)的可靠性要優(yōu)于JTAG調(diào)試器。本系統(tǒng)在3個終端設(shè)備上燒錄1000次，未出現(xiàn)任何失敗，而使用JTAG燒錄1000次會有燒錄失敗的情況。由此說明，本系統(tǒng)具有極高的可靠性，這得益于本系統(tǒng)設(shè)計(jì)的合理性以及多種防錯機(jī)制的結(jié)合。

(2) 更新速度測試。為了評測本系統(tǒng)的更新速度性能，使用JTAG調(diào)試器和本系統(tǒng)分別將同一User程序(與可靠性測試使用相同的User程序)燒錄至同一終端設(shè)備，并記錄燒錄使用的時間。測試結(jié)果如表6所示。

表6 更新速度測試結(jié)果

由表6可知，JTAG的更新速度要優(yōu)于本系統(tǒng)，這說明JTAG調(diào)試器在速度性能上存在一定優(yōu)勢。但是，本系統(tǒng)的更新耗時在可承受范圍之內(nèi)，而且，本系統(tǒng)具有如下優(yōu)勢：① 省去額外購買硬件的開銷；② 傳輸距離更遠(yuǎn)，可實(shí)現(xiàn)遠(yuǎn)程更新；③ 更新過程可控，能保證程序的穩(wěn)定性和可靠性；④ 硬件驅(qū)動固化在BootLoader程序中，減少了User程序的代碼量。因此，速度的犧牲是值得的。

5 結(jié)束語

為了解決使用JTAG調(diào)試器燒錄程序所存在的弊端，設(shè)計(jì)并實(shí)現(xiàn)了一套基于串口通信的程序更新系統(tǒng)。該系統(tǒng)在物理結(jié)構(gòu)上將終端程序分為BootLoader和User。BootLoader固化在Flash中，不對外提供源代碼，User實(shí)現(xiàn)用戶需要的功能并對外提供源代碼。BootLoader提供了通過串口更新User的功能，并集成了終端設(shè)備基礎(chǔ)硬件資源的驅(qū)動，使得用戶可以直接通過接口進(jìn)行調(diào)用，而不用知道其源代碼和實(shí)現(xiàn)過程。這既保證了串口更新的可靠性，又保證了基礎(chǔ)硬件資源的驅(qū)動不會被惡意修改。本系統(tǒng)已經(jīng)在本實(shí)驗(yàn)室的PLC遠(yuǎn)程監(jiān)控系統(tǒng)項(xiàng)目中得到了成功應(yīng)用，目前，該項(xiàng)目運(yùn)行良好，更新系統(tǒng)工作正常。