需求

前文中實現了一款簡單的 2nd Bootloader，能夠跳轉執行存儲在 QSPI Flash 中的應用程序，但 2nd Bootloader 如果僅僅只是用于跳轉執行程序的話，豈不是有些太簡單了？從本章開始，將會講解幾種 2nd Bootloader 進階設計，實現類似 ISP 更新固件的功能，以及在 OTA 升級時避免變“磚”等設計，以及講解一些 2nd Bootloader 的程序設計思路。

本文將以 Ymodem 協議獲取應用程序的二進制文件為例，實現類似 ISP 更新固件的功能。

需要注意：

下文中提到的 ISP 僅指由 2nd Bootloader 實現的定制 ISP，而非微控制器本身的 ISP。

上位機發送的文件是二進制（.bin）文件，而不是 Intel Hex 標準的 hex （.hex）文件。

目前僅考慮直接覆蓋的方式燒寫程序，即獲取到一段二進制數據后，直接寫入到 QSPI Flash 的對應位置。

Ymodem 介紹

Ymodem 協議是一個文件傳輸協議，通常用于在資源受限的設備中傳輸文件，它可以一次傳輸1024字節的信息塊，同時還支持傳輸多個文件。

Ymodem 協議有較多的變種，本文使用的是常用的 Ymodem-1K 協議。

通信時序

通訊時序如圖1：

圖1 Ymodem 通信時序

幀格式

Ymodem 有兩種幀格式：

幀頭為 SOH 時，信息塊長度為128字節，總長度133字節。

幀頭為 STX 時，信息塊長度為1024字節，總長度1029字節。

兩種幀的幀格式如表1所示：

表1 SOH / STX 幀格式

包號從0x00起始，每成功傳輸一幀數據后包號加1，計數到0xFF后，下一次包號重新從0x00開始計數。

包號反碼是包號取反的數值，如0x00的包號，包號反碼為0xFF，0x01的包號，包號反碼為0xFE。

信息塊是要傳輸的具體數據塊，起始幀包含了文件名和文件大小，數據幀包含了分段的數據內容。

校驗采用 CRC 校驗，僅校驗信息塊的內容。

除了兩種幀格式外，還有 ACK、NAK、CAN、EOT、字符 'C' 五種命令，長度僅有1字節。

起始幀、數據幀、結束幀

起始幀采用幀頭為 SOH 的幀格式傳輸，包號為 0x00，信息塊中包含文件名字符串和文件大小字符串 (十進制表示)，字符串以0x00結尾，信息塊剩余部分以0x00填充。

數據幀采用幀頭為 STX 的幀格式傳輸，包號從0x01開始計數，信息塊中包含分段的文件內容。

當最后一段要發送的數據塊大小超過128字節但小于1024字節時，采用幀頭 STX 的幀格式傳輸，信息塊結尾用 0x1A 填充。小于128字節，采用幀頭為 SOH 的幀格式傳輸，信息塊結尾依然用 0x1A 填充。

結束幀和起始幀一樣，唯一不同的是沒有文件名和文件大小，即信息塊的內容全為 0x00。

通訊指令

通訊指令如表2所示。

表2 Ymodem通訊指令

協議實現

CRC 校驗：

Ymodem 協議中提供了 CRC 校驗的 C 代碼片段，但由于該協議發布時的 C 標準不同于現在，因此不能直接使用，此處提供一份 CRC 校驗的實現代碼，通過調用 crc_calc() 來實現對信息塊內容的校驗：

staticuint16_tcrc_update(uint16_tcrc,uint8_tdata)
{
uint32_tcrc32=crc;
uint32_tdata32=data;

for(uint32_ti=0u;i

	

	當我們需要對一段數據進行 CRC 計算時，調用 crc_calc() 函數，傳入數據起始地址和數據長度即可計算出 CRC 校驗值。

	STX 包處理：

	通過對 Ymodem 協議的介紹可知，STX 包只在接收數據的過程中使用，因此收到 STX 包時，僅需要進行如下處理：

	CRC校驗信息塊。

	計算信息塊的有效數據長度（需要注意最后一幀數據的有效長度不定）。

	存儲數據。

	發送 ACK 指令或 NAK 指令。

	SOH 包處理：

	SOH 包的處理要比 STX 包的處理復雜，因為包含了起始幀和結束幀的處理。

	起始 / 結束幀和數據幀只能通過當前狀態來判斷，其中，除信息塊長度不同外，數據幀的處理同 STX 包的處理一致。

	由于 Ymodem 可以多文件傳輸的特性，處于該收到結束幀的狀態時也有可能收到起始幀，因此起始幀和結束幀需要進行一個判斷：信息塊第一個字節是否為 0x00。如果不是 0x00 則為起始幀，否則為結束幀。

	起始幀要攜帶文件名和文件大小，信息塊的第一個字節一定是一個可顯示的字符，當收到起始幀時，需進行如下處理：

	讀取文件名和文件大小。

	進入讀數據塊的狀態。

	發送 ACK。

	發送 字符 'C'。

	結束幀的信息塊全為0x00，收到結束幀時，需進行如下處理：

	發送 ACK。

	結束 Ymodem 傳輸。

	EOT 指令處理：

	EOT 代表本次文件傳輸結束（但不代表所有文件都已發送完畢），因此，收到 EOT 指令時，需將當前狀態調整為起始狀態，準備接收新的文件，具體處理如下：

	進入起始狀態。

	發送 ACK。

	發送字符 'C'。

	CAN 指令處理：

	CAN 是 cancel 的縮寫，當收到 CAN 指令后，表示后續的 Ymodem 傳輸終止，該指令是雙向的，既可以由 Host 發送， 也可以是 Device 發送，收到 CAN 指令后，具體操作如下：

	退出 Ymodem 傳輸。

	接收超時處理：

	Device 在接收數據前，會先向 Host 發送字符 'C'，但如果此時 Host還沒有將文件準備好，則會卡死在準備接收狀態。

	Device 在接收數據過程中，如果少接收到某個字節數據，信息不完整，則會卡死在接收數據的過程中。

	Device 發送某個指令后，Host 可能沒有收到指令，不會繼續下一幀數據的發送，Device 還是會卡死在接收的過程中。

	因此，需要引入接收超時的操作。

	當接收超時后，判斷狀態，如果是起始狀態，且沒有收到任何字節，則可能是 Host 還沒有準備發送文件，重新發送字符 'C'。

	如果數據沒有接收完整，則可能是少收到幾個字節的數據，發送 NAK，讓 Host 重新發送數據。

	如果沒有收到數據，則 Host 可能沒有收到回復的指令，重新發送上次發送的指令。

	軟件設計

	就像是計算機進入 BIOS 設置，需要用戶在開機的瞬間不停按下鍵盤上某個按鍵那樣，為了使 2nd Bootloader 知道自己是該跳轉執行應用程序，還是進入 ISP 等模式，需要外界有一個輸入：這個輸入可以是某個引腳的電平變化，也可以是在有限的時間里通過某種通信接口獲取到一段外界指令，當 2nd Bootloader 讀取到這個來自外界的輸入后，才能知道自己接下來要干什么。因此，除了實現 ISP 下載的功能外，我們還需要實現選擇工作模式的功能，如圖2所示：

	

	圖2 軟件設計

	Ymodem 只是獲取二進制文件的一種方式，除了 Ymodem，我們也可以采用 Xmodem，Zmodem協議，除了串口，還可以使用 CAN，甚至通過 USB 讀取 U 盤里的文件等方式。

	綜上所述，在設計 2nd Bootloader 時，不能綁死選擇工作模式的方式，也不能綁死 ISP 的工作方式，甚至，不能綁死 2nd Bootloader 只能在兩種工作模式下二選一（不要使用 if & else 的語句區分工作模式，而應使用 switch 語句區分工作模式），因此，2nd Bootloader 的頂層應用邏輯，只能是下面的設計：

	
intmain(void)
{
......
switch(get_run_mode())
{
caseEXEC_QSPI:
jump_to_app(QSPI_BASE);
break;
caseISP:
isp();
break;
......
default:
jump_to_app(QSPI_BASE);
break;
}
......
}


	

	如果我們期望從某種工作模式下切換到另一種工作模式，最好的做法是先讓外界輸入保持為目標工作模式的狀態，然后讓微控制器復位，再次進入 2nd Bootloader，這樣的做法是能夠保持微控制器切換工作模式后，仍然保持相對 “干凈” 的環境狀態，例如，微控制器前一次進入到了 ISP 模式，通過串口更新了應用程序，如果直接跳轉到應用程序，則發現串口依然保持打開的狀態，這對應用程序而言可能不是期望的結果，那提前關閉串口呢？還有 GPIO 引腳的配置沒有改動……最簡單省事的做法，其實就是直接讓微控制器復位，而串口和串口的 GPIO 引腳也就會在微控制器復位之后，處于默認相對比較 “干凈” 的狀態。這也是為什么圖x所示的流程圖，ISP 模式的下一步是復位微控制器。

	當然，如果在 get_run_mode() 的時候就用到了串口，那還是老老實實在 get_run_mode() 執行到 return 之前，就把串口和 GPIO 處理干凈。

	這里提一個比較“花”的設計方法，我們可以把 ISP 也做成應用程序，下載到片內 Flash 中 一塊確認好的位置（假設起始地址為 ISP_BASE），然后同樣使用 jump_to_app() 跳轉，只是輸入參數從 QSPI_BASE 變為了 ISP_BASE，這個做法會用在 USB DFU 模式上，因為一旦進入了 USB DFU 模式，USB 就不能再作為其它設備進行工作，當 USB 設備支持 USB DFU 時，就需要使用這種辦法單獨進入到 DFU 模式下。

	測試

	選擇工作模式：

	在這里，我們通過讀取指定引腳的電平狀態來確定該進入何種工作模式。

	
uint32_tget_run_mode()
{
......
if(GPIO_ReadInDataBit(BOARD_BOOT_GPIO_PORT,BOARD_BOOT_GPIO_PIN))
{
returnEXEC_QSPI;
}
else
{
returnISP;
}
......
}


	

	ISP 模式：

	當進入 ISP 模式后，開始使用 Ymodem 協議接收數據。
voidisp()
{
......
/*getnewappbin&writetoqspiflash.*/
ymodem_recv_start(&ym,100000);
while(0==(YMODEM_STATUS_DONE&ym.status))
{
ymodem_recv_byte_handler(&ym);
}

/*resetmcu.*/
__set_FAULTMASK(1);
NVIC_SystemReset();
}

	

	生成應用程序的二進制文件：

	我們仍然以 MindSDK 的 hello_world 樣例工程為例，修改其 Linker 文件并檢查代碼，使其成為一個可存儲在 QSPI Flash 上的應用程序，隨后在 MDK 工程中，點擊魔術棒（Options for Target...），點擊 User 列表，如圖3所示，在指定位置（紅框中的 User Command）加入下面這句話，并在前面打上對勾：

	fromelf.exe --bin -o "@L.bin" "#L"

	然后編譯工程，就能在工程文件所在的目錄下找到生成的 bin 文件。

	

	圖3 生成二進制文件

	本文使用 TeraTerm 軟件進行 Ymodem 傳輸文件，如圖4所示：

	

	圖4 TeraTerm Ymodem 發送文件

	但在測試時發現，當文件傳輸到 100% 時，TeraTerm 并沒有結束傳輸，但對 2nd Bootloader 的代碼進行分析后并沒有發現存在邏輯問題，因此對 TeraTerm 的 Ymodem 協議產生了懷疑，如圖5所示。

	

	圖5 TeraTerm 傳輸文件，總卡在 100% 處

	使用兩個 USB 串口模塊，將其 TXD 與 RXD 相連，其中一個串口模塊使用 TeraTerm 打開，另一個使用 SSCOM 打開（為了能夠發送和顯示一些非字符類的控制指令），使用 TeraTerm 的 Ymodem 協議發送文件， SSCOM 接收來自 TeraTerm 的數據，并按照 Ymodem 協議回復指令，模擬完整的 Ymodem 傳輸協議，如圖6所示。

	

	圖6 模擬 Ymodem 協議傳輸文件過程

	結果發現，TeraTerm 實現的 Ymodem 協議在發送單個文件的時候，存在以下問題：

	發送 EOT 指令后，需接收兩次 ACK 和字符 ‘C’。

	沒有發送 last block。

	因此，我們需要針對 TeraTerm 的問題，對 Ymodem 的實現做一些改動，或者使用其它軟件通過 Ymodem 傳輸二進制文件。修改后的時序圖如下：

	

	圖7 針對 TeraTerm 的 Ymodem 實現進行的改動

	刪去了對 last block 的接收，并且在收到 EOT 后，主動發送兩次 ACK 和 字符 ‘C’，經過修改后測試，TeraTerm 的 Ymodem 能夠按照傳輸完成的方式正常退出。

	下載程序，如圖8所示：

	

	圖8 下載應用程序

	運行應用程序，如圖9所示：

	

	圖9 運行應用程序

	結語

	本文在 2nd Bootlaoder 的基礎上實現了基于 Ymodem 協議的 ISP 功能，能夠通過復位后指定引腳的電平狀態來區分該執行應用程序還是進入 ISP 模式，進入 ISP 模式后，可以使用 TeraTerm 等軟件，通過串口，使用 Ymodem 協議將二進制文件下載到與微控制器連接的 QSPI Flash 中，實現固件更新的功能。

	但本文并沒有對固件更新過程中可能出現的意外進行處理，所以這種 ISP 的辦法不能直接用在 OTA 升級中，在下一章中，我們將會探討 OTA 升級時可能會出現的意外情況，并且進行處理。

	審核編輯：湯梓紅