基于UART 總線Ymodem 協(xié)議的Bootloader 設(shè)計(jì)與實(shí)現(xiàn)

李媛媛

（南京康尼機(jī)電股份有限公司， 江蘇 南京 210013）

0 引言

為了避免在進(jìn)行程序更新、 升級過程中拆除門控器，通過仿真器將應(yīng)用程序更新到處理器中的這種繁瑣、費(fèi)時、耗力的工作，需要研究通過串行總線、USB 口或其它總線以及相應(yīng)的通訊協(xié)議實(shí)現(xiàn)在線升級。 在更新過程中，可靠性是開發(fā)過程中首要考慮因素。為了應(yīng)對程序更新出錯的意外狀況，采取在開始更新、更新過程中以及更新完成后讀寫同一塊地址不同標(biāo)志的策略增強(qiáng)程序的可靠性。

本文著重研究基于TMS570LS0714 處理器UART 總線Bootloader 的設(shè)計(jì)與實(shí)現(xiàn)， 采用Ymodem 協(xié)議實(shí)現(xiàn)文件傳輸， 通過實(shí)驗(yàn)說明設(shè)計(jì)的Bootloader 可以實(shí)現(xiàn)應(yīng)用程序在線更新。

1 Bootloader 工作原理

應(yīng)用Flash 程序存儲器的一種編程方式稱為在線應(yīng)用編程IAP（In-Application Programming），它能夠在應(yīng)用程序正常運(yùn)行過程中， 借助特定的IAP 程序讀/寫另一段程序的Flash 空間，甚至可以讀/寫某段、某頁甚至某個字節(jié)， 這使得程序的在線升級和數(shù)據(jù)存儲有了很大的便捷性和靈活性[1]。

為了實(shí)現(xiàn)IAP 功能， 通常Flash 內(nèi)部要劃分為兩塊，一塊叫做Boot 區(qū)，專門用來存儲Bootloader 程序，一塊稱為存儲區(qū)，用來存儲應(yīng)用程序。 處理器TMS570 上電之后首先在Boot 區(qū)運(yùn)行，如果有滿足外部改寫程序的條件，則先擦除原有程序數(shù)據(jù)， 并通過UART 總線下載待升級程序到Flash，再拷貝到RAM 中運(yùn)行；如果不滿足改寫程序的條件，則程序指針跳轉(zhuǎn)到存儲區(qū)，執(zhí)行應(yīng)用程序，這就是IAP 功能實(shí)現(xiàn)原理[2]。

2 TMS570LS0714 內(nèi)存分配

2.1 TMS570LS0714 簡介

TMS570LS0714 處理器， 是TI 公司的一款安全控制芯片，符合功能安全要求的微控制器，具有雙核校驗(yàn)、RAM和FLASH 的ECC 校驗(yàn)等系統(tǒng)可靠性保障手段，可以識別出系統(tǒng)運(yùn)行過程中的各類異常并執(zhí)行用戶預(yù)置的異常處理程序[3]。

2.2 內(nèi)存分配

TMS570LS0714 對用戶可操作的Flash 范圍是0x0000_0000～0x000B_FFFF，共768K[3]。 通常會安排Bootloader 代碼處于Flash 的開始區(qū)域0x0000_0000， 而應(yīng)用程序代碼緊隨其后。Bootloader 實(shí)現(xiàn)的功能就是升級加載應(yīng)用程序，應(yīng)本著可靠、簡化的原則，占用的存儲空間不應(yīng)過大， 本文分配Bootloader 存放地址為0x0000_0000～0x0001_FFFF，共128K。剩下的Flash 空間用0x0000_0000～0x000B_FFFF 來存放應(yīng)用程序。

3 基于UART 的Ymodem 協(xié)議設(shè)計(jì)

本模塊通過UART 接口使用Ymodem 通信協(xié)議傳輸文件。 Ymodem 協(xié)議在發(fā)送方發(fā)送完成一包數(shù)據(jù)之后，需要等待接收方的確認(rèn)，如果發(fā)生方收到“ACK”信號，則可以發(fā)送新的數(shù)據(jù)包，如果收到“NAK”信號，則需要重發(fā)或者錯誤退出。

3.1 Ymodem 協(xié)議簡介

Ymodem 協(xié)議是廣泛使用的異步文件傳輸協(xié)議之一，它是Xmodem 的改進(jìn)版協(xié)議，相較于Xmodem 協(xié)議，Ymodem 協(xié)議允許批處理文件傳輸，傳輸效率、可靠性更高，一幀可以傳輸128*8bite 或1024*8bite， 一次傳輸可發(fā)送或接收幾個文件，使用CRC 校驗(yàn)技術(shù)對發(fā)送數(shù)據(jù)包進(jìn)行數(shù)據(jù)校驗(yàn)確保數(shù)據(jù)傳輸正確性。每發(fā)送一個數(shù)據(jù)包后，會等待接收端回應(yīng)，直到接收到“ACK”信號后，下一個數(shù)據(jù)包才會繼續(xù)傳輸，確保數(shù)據(jù)被接收完成。

3.2 UART 通訊格式

本模塊定義的傳輸波特率是115200bit/s，8 個數(shù)據(jù)位，1 個停止位，偶校驗(yàn)。

3.3 標(biāo)識符定義

本協(xié)議接收方和發(fā)送方約定的收發(fā)過程中的一些標(biāo)記信號定義見表1。

表1 收發(fā)過程約定符號定義

3.4 文件傳輸過程

文件傳輸過程為[4]：

（1） 開啟是由接收方的處理器發(fā)送一個大寫字母“C”開啟傳輸，之后等待發(fā)送方發(fā)送“SOH”，如果接收不到回應(yīng)，則一直向上位機(jī)發(fā)送“C”，若超過5S 上位機(jī)還沒有回應(yīng)，則處理器會向上位機(jī)連續(xù)發(fā)送兩個“CAN”，然后超時退出。

（2）發(fā)送方開始時處于等待過程中，等待“收到“C”以后，發(fā)送文件名數(shù)據(jù)包，然后進(jìn)入等待“ACK”狀態(tài)。

（3）接收方收到數(shù)據(jù)包之后，對數(shù)據(jù)包進(jìn)行CRC 校驗(yàn)，校驗(yàn)成功則發(fā)送“ACK”信號。 發(fā)送方接收到“ACK”，又重新進(jìn)入等待“C”的狀態(tài)。

（4）至此文件名數(shù)據(jù)包傳輸完成，此后文件傳輸正式開啟，Ymodem 支持每個數(shù)據(jù)包以128 字節(jié)以“SOH”開始或者1024 字節(jié)以 “STX” 開始， 本文規(guī)定每個數(shù)據(jù)包為1024 字節(jié)。

接收方開始準(zhǔn)備接收文件又發(fā)出一個“C”信號，然后進(jìn)入等待“STX”狀態(tài)。

（5）發(fā)送接收到“C”以后，發(fā)送數(shù)據(jù)包（詳見3.5 章節(jié)數(shù)據(jù)格式），等待接收方的“ACK”信號。

（6）發(fā)送方發(fā)出“EOT”信號表示文件發(fā)送完成，接收方回應(yīng)“ACK”信號。

緊接著發(fā)送方發(fā)出一個全“0”數(shù)據(jù)包，接收方回應(yīng)“ACK”，正式結(jié)束此次通訊。

3.5 接收數(shù)據(jù)格式

Ymodem 通信協(xié)議接收數(shù)據(jù)格式，第一包數(shù)據(jù)只是傳輸文件的文件名和文件大小信息， 之后傳輸?shù)臄?shù)據(jù)包才是文件的內(nèi)容。 若最后一包內(nèi)容不足1024 字節(jié)， 則以0補(bǔ)齊。 具體傳輸格式如下：

第一包：

圖1 第一包發(fā)送數(shù)據(jù)格式

第二包：

圖2 第二包發(fā)送數(shù)據(jù)格式

之后每一包依次類推下去。

3.6 發(fā)送數(shù)據(jù)格式

接收方以一個大寫字母“C”開啟傳輸，收到發(fā)送來的數(shù)據(jù)以后，CRC 校驗(yàn)滿足，則發(fā)送“ACK”應(yīng)答信號，CRC 校驗(yàn)不滿足，則連續(xù)發(fā)送兩個“CAN”信號，表示取消該次傳輸。

接收方接收數(shù)據(jù)成功以后， 開始寫入flash 操作，如果寫入失敗，則連續(xù)發(fā)送兩個“CAN”信號，如果寫入成功，則發(fā)送一個“ACK” 應(yīng)答信號。

接收數(shù)據(jù)過程中，如果連續(xù)收到兩個“CAN”信號，則表示取消傳輸，發(fā)送方以發(fā)送“ACK”應(yīng)答；如果連續(xù)到一個“EOT”信號，則表示文件傳輸結(jié)束，發(fā)送方以發(fā)送“ACK”應(yīng)答。

4 Bootloader 軟件實(shí)現(xiàn)

4.1 CMD 文件配置

配置Bootloader 的CMD 文件是應(yīng)用程序能否被正確升級的關(guān)鍵，CMD 文件的兩大主要功能是通過MEMORY偽指令來指示存儲空間和通過SECTIONS 偽指令來分配段到存儲空間，CMD 文件就是由這兩部分內(nèi)容構(gòu)成的。

在控制器復(fù)位以后， 啟動程序?qū)⒀b載引導(dǎo)程序的Flash API 從FLASH 中復(fù)制到RAM 中， 并在RAM 中執(zhí)行裝載引導(dǎo)程序?？梢栽贑MD 文件中劃分一段用以設(shè)置RAM 的載入和運(yùn)行地址，定義輸出段將被裝載到哪里的關(guān)鍵字、輸出段從哪里開始運(yùn)行的關(guān)鍵字、API 從哪里開始下載、API 從哪里開始運(yùn)行以及API 的長度等信息[5]。

4.2 串口IAP 設(shè)計(jì)流程

串口IAP 的實(shí)現(xiàn)流程見圖3 所示，控制器復(fù)位以后，首先是在Flash 起始地址運(yùn)行Bootloader 程序。Bootloader程序執(zhí)行的任務(wù)就是檢測是否升級應(yīng)用程序， 通過判斷Flash EEPROM block1 上的值是否是約定標(biāo)志A，若block1 上的值不是A， 則表示要進(jìn)行更新， TMS570 向上位機(jī)發(fā)送請求執(zhí)行代碼升級函數(shù)， 同時驅(qū)動數(shù)碼管顯示“CC”。

圖3 IAP 實(shí)現(xiàn)流程

若block1 中的值滿足約定條件， 則說明分配的應(yīng)用程序地址空間（0x0002_0000～0x000B_FFFF）里有完整的應(yīng)用程序， 不需要進(jìn)行升級操作， 直接跳轉(zhuǎn)到用戶代碼段，即起始地址0x0002_0000 執(zhí)行應(yīng)用程序。

定義運(yùn)行Bootloader 程序， 門控器數(shù)碼管顯示“CC”指示Flash 中沒有應(yīng)用程序，數(shù)碼管顯示“FE”指示正在升級，數(shù)碼管顯示“FF”指示升級完成。

4.3 出錯防護(hù)

在程序升級過程中，為了防止誤升級錯誤的文件，或者是升級過程中出現(xiàn)意外導(dǎo)致升級失敗， 升級標(biāo)志在不同階段寫不同值。

即在正常運(yùn)行應(yīng)用程序時，收到上位機(jī)的升級請求，應(yīng)用程序首先向Flash EEPROM block1 寫需要升級標(biāo)志B，然后關(guān)閉定時器引起復(fù)位操作，CPU 復(fù)位后進(jìn)入Bootloader，重復(fù)4.1 節(jié)的操作，進(jìn)入升級流程，在升級流程里，首先讀取block1 中的標(biāo)志是否是B，若是B，則向block1中寫正在升級標(biāo)志C，然后正式啟動升級操作。 升級完成后，跳轉(zhuǎn)到應(yīng)用程序段執(zhí)行應(yīng)用程序，應(yīng)用程序在執(zhí)行正常功能之前，先讀block1 中的標(biāo)志是否是A，按照上述思路，這個時候block1 中存放的是標(biāo)志C，而不是A，這時候CPU 立即向block1 中寫標(biāo)志A，然后復(fù)位重啟，重復(fù)4.1 節(jié)操作。

這樣略顯繁瑣的操作， 恰好能規(guī)避誤升級錯誤文件的操作。 若正常升級過程出現(xiàn)意外導(dǎo)致升級失敗， 重啟CPU，Bootloader 上電檢測block1 無標(biāo)志A， 再次進(jìn)入升級流程升級即可。

5 實(shí)驗(yàn)

本章節(jié)設(shè)計(jì)了四個試驗(yàn)，通過配套上位機(jī)軟件發(fā)送應(yīng)用APP 程序數(shù)據(jù)流到TMS570 并運(yùn)行， 測試上文設(shè)計(jì)的Bootloader 能否實(shí)現(xiàn)預(yù)期的升級功能。 該APP 程序運(yùn)行起來后循環(huán)檢測有無升級請求， 并控制數(shù)碼管顯示“00”，輸出口O0 紅色指示燈以1HZ 頻率閃爍， 以方便用戶觀察APP 程序是否得以正確并完整升級，是否能夠正常運(yùn)行。

5.1 Flash 中只有Bootloader 升級APP

Flash 中只有Bootloader，應(yīng)用程序段是空的，啟動上位機(jī)發(fā)送升級請求， 觀察升級過程中數(shù)碼管及指示燈情況見表2。 表中的數(shù)碼管及指示燈顯示情況表明該升級過程沒有出現(xiàn)數(shù)據(jù)丟失情況，Bootloader 能完整的解碼上位機(jī)發(fā)送的數(shù)據(jù)并寫到相應(yīng)Flash 上，升級成功。

表2 Flash 中只有Bootloader 升級APP

5.2 Flash 中有Bootloader 和APP 升級APP

繼5.1 節(jié)之后，控制器輸出口O0 閃爍過程中， 啟動上位機(jī)發(fā)送升級請求， 觀察升級過程中數(shù)碼管及指示燈見情況見表3。

表3 Flash 中有Bootloader 和APP 升級APP

該試驗(yàn)結(jié)果表明設(shè)計(jì)的Bootloader 能夠?qū)崿F(xiàn)過程升級。

5.3 Flash 中有Bootloader 和APP 升級了錯誤APP

繼5.1 節(jié)之后，控制器輸出口O0 閃爍過程中，啟動上位機(jī)發(fā)送升級請求，但是發(fā)送的不是和Bootloader 配套的APP 程序， 該APP 程序沒有實(shí)時檢測升級的功能，也沒有點(diǎn)亮輸出口的功能，即錯誤APP。觀察升級過程中數(shù)碼管及指示燈情況見表4。

表4 升級錯誤APP

該實(shí)驗(yàn)表明升級了錯誤APP 后，Bootloader 不會跳轉(zhuǎn)到錯誤APP 程序執(zhí)行，會一直等待升級， 直到升級了正確APP 后，才會跳轉(zhuǎn)執(zhí)行APP 程序，能有效防護(hù)誤升級錯誤APP。

5.4 升級APP 過程出錯

在升級過程中，斷開上位機(jī)與控制器的連接，制造升級過程出錯的現(xiàn)象，觀察上位機(jī)顯示升級超時出錯，重啟控制器，數(shù)碼管顯示“CC”，指示Flash 中沒有APP 程序。該實(shí)驗(yàn)表明Bootloader 能夠有效防護(hù)升級過程出錯。

6 結(jié)論

本文設(shè)計(jì)并實(shí)現(xiàn)了基于Ymodem 協(xié)議的Bootloader，在開發(fā)過程中增加防錯處理， 有效防止升級錯誤的執(zhí)行文件及升級失敗。經(jīng)過試驗(yàn)證明Bootloader 能正確引導(dǎo)程序運(yùn)行，下載數(shù)據(jù)完整、無誤、快速，沒有出現(xiàn)數(shù)據(jù)丟失、錯誤等現(xiàn)象。