：XMODEM協議的控制字元
上表中各個縮寫也是標準ASCII碼的一個字元，在XMODEM協議中需要使用這些字元來表達協議的狀態。而其基本含義如表中所述。
2.2資料幀格式與檔案分解
XMODEM協議每次傳送的資料幀長度為132位元組，其中檔案資料佔128位元組，其他4個位元組分別為開始標誌，塊序號，塊序號的補碼和校驗位元組。其中開始標誌，塊序號，塊序號的補碼位於資料塊開始，校驗位元組位於資料塊結尾，如：
偏移位元組數名稱描述說明
名稱數值(HEX)
01SOH01起始位元組標誌
11Seq1~FFh塊序號
21cmplFFH-seq塊序號的補碼
3128data?檔案內容資料
1311csum?垂直累加和校驗1：XMODEM協議允許使用2種校驗碼。2：校驗碼只從128位元組的資料進行計算後得出，頭部3個位元組不參加校驗和運算。
2CRC?16位迴圈冗餘校驗
圖表3：XMODEM協議的資料幀格式
如果檔案長度不是128位元組的整數倍，最後一個數據塊的有效內容必然小於幀長，剩下部分需要用其他資料來填充，XMODEM建議使用“CTRL-Z”(=26（01aH）)，這種情況下，接收方如何區別該幀中屬於檔案的內容和填充的內容呢？
如果傳送的檔案是隻包含字母、數字和可顯示符號的文字檔案（例如C程式原始碼檔案），那麼根據內容本身接收方是可以區分的（“26”不是字母或者數字的ASCII碼），如果傳送的是任意數值的二進位制檔案（如程式目標碼），則接收方是無法區分檔案內容和填充內容。
重要提示：XMODEM協議不能保證接收方接收的檔案長度和傳送方完全一致，接收方所接收的檔案資料長度總是128位元組的整數倍，比傳送檔案的實際長度要大1到127位元組。多出的內容位於檔案結尾處。
XMODEM協議的這種缺點對於用於嵌入式系統的程式程式碼下裝沒有實際影響，處理器不會將填充內容當作程式碼執行，只要程式儲存器的容量足夠，能儲存接收的所有資料就可以了。如果將XMODEM協議用於資料庫下裝，應當考慮多餘內容的影響，一般標準資料庫檔案中均有表示資料庫尺寸、欄位數、記錄數等資料庫結構引數，所以也不會把填充內容當作資料庫的記錄本身。
同樣，對於漢字型檔這種資料庫，使用XMODEM協議來下載也不會產生問題。
2.3校驗演算法
校驗碼是對傳送資料進行某種計算得到的編碼，為了防止資料在傳送途中某些位發生錯誤，各種資料通訊協議規定傳送方除了傳送應用資料外，還要傳送校驗碼，而資料接收方則根據同樣演算法從收到的應用資料中計算出校驗碼，並和傳送方傳送的校驗碼比較，如相等，才認為收到了正確的資料。
在XMODEM協議中，可使用垂直累加和或者CRC校驗，使用CRC校驗的通訊軟體可以自動從CRC校驗自動切換到累加和校驗模式。在本應用中，我們使用垂直累加和校驗。
累加和校驗碼是將所有傳送資料的和按位元組累加，保留其最低位元組作為校驗碼，例如，傳送的3個位元組資料分別為255（FFh）,5(05h),6(06h),則：
11111111FFH
0000010105H
0000011006H
100001010－>00001010
將高位丟棄後，得到累加和校驗碼為0Ah（10）。在上例中，如果原來資料在途中發生了變化，如FFH變為FEH,06H變為07H,05H未變，則接收方所計算的校驗碼為：
接收發送
11111110FEH
0000011107H
校驗碼也為0AH。可見，在資料中有2位改變時，接收方所計算的校驗碼仍然與傳送方一致，這種校驗方式不能檢測偶數位的誤碼。
XMODEM協議的校驗碼只對資料幀中的128位元組資料進行計算後得出，頭部3個位元組不參加校驗和運算。
2.4XMODEM協議的啟動
XMODEM協議開始是檔案接收方發出“NAK”位元組，檔案傳送方在收到該訊號後傳送資料幀，雙方開始正常通訊過程。而檔案傳送方進入XMODEN協議後，等待對方傳送”NAK”,如果等待時間超過60秒，則退出本次通訊。
接收方發出“NAK”後，如果10秒後對方還沒有傳送第一個資料幀，則重複傳送“NAK”，這種重複次數最多允許10次，仍然沒有收到第一個資料塊，則退出本次通訊。
（A）：傳送方軟體延遲100秒以上工作導致不能啟動協議
（B）：接收方軟體延遲60秒傳送”NAK”訊號導致不能啟動協議
圖表4XMODEM協議不能啟動的2種情況
在嵌入式系統透過PC機來下載軟體的應用中，嵌入式系統軟體是檔案接收方，PC機超級終端軟體是檔案傳送方。按照協議規定，嵌入式系統的通訊軟體進入XMODEM協議狀態後，PC機軟體必須在100秒內進入協議狀態（即執行超級終端的XMODEM檔案傳輸功能），反之，後者先進入協議狀態，前者必須在60秒內進入協議狀態，顯然，透過人工來操作，這種時間差有些緊張。解決辦法只有加長嵌入式系統載入軟體的啟動等待時間，這種修改不會引起協議理解的歧義。
重要提示：為了傳送和接收方能夠更容易啟動XMODEM協議，在設計中，將延長嵌入式系統下載軟體的啟動延時時間，在以下的程式碼中，將這種延時時間改為600秒（10分鐘）。或者將等待時間設定為無限長，一致發出”NAK”訊號，直到PC機上的超級終端軟體執行為止。
2.5XMODEM的正常傳輸過程
中給出了一次正常的XMODEM通訊中收發雙方的通訊過程。
圖5：沒有差錯的檔案傳輸過程
檔案接收方每收到一個數據幀後，如沒有校驗差錯、序號差錯等情況，均傳送一個“ACK”字元作為應答，傳送方在收到應答後才開始傳送下一個字元，如此反覆，直到檔案內容傳送完畢，傳送方傳送“EOT”字元表示傳送完成，傳送方收到後再次以“ACK”迴應，至此，整個檔案傳輸過程就結束了。
2.6XMODEM協議的中止
在通訊進行過程中，雙方中的任意一方如果希望中止本次通訊，可以傳送“CAN”字元給對方，現在很多XMODEM協議軟體要求傳送2個”CAN”字元來實現，
2.7XMODEM協議的異常處理
在通訊過程中，總是要出現各種異常情況，比如通訊線路的突然中斷，一方機器停電而導致軟體中止執行等；通訊軟體必須能夠檢測這些錯誤，並作出合理的處理。在前面的協議啟動一節中已經涉及到了錯誤檢測的問題，XMODEM對錯誤的規定很詳細，共計有8種情況，協議文字沒有說明是如何引起的，中給出了可能原因，
在嵌入式系統中，考慮到下載軟體一般均有人操作的，也可不考慮錯誤處理，這樣實現實現程式碼會減小。在本文中，考慮到協議的完整性，考慮了各種錯誤的處理。
2.8CRC校驗與累加和校驗方式的切換
XMODEM協議要求支援CRC校驗的通訊軟體也能支援累加和校驗，這樣就可以和那些只支援累加和校驗的軟體進行通訊，如果檔案接收方只支援累加和，而傳送方可支援CRC，接收方傳送啟動訊號為“NAK”，傳送方收到後自動按累加和方式傳送資料幀；如果相反，接收方支援CRC，而傳送方支援累加和，接收方首先發出字母“C”來作為啟動訊號，這時接收方應不理睬此訊號，傳送方在3秒後繼續傳送訊號“C”，共三次未收到應答後，改為傳送“NAK”訊號，表示使用累加和方式進行通訊了。
如果通訊雙方均採用CRC校驗，上述通訊握手訊號“NAK”用字母“C來代替，其他過程同上。
因為PC機超級終端軟體支援CRC模式，嵌入式系統作為檔案接收方，只要傳送“NAK”訊號就能使對方自動按照校驗和方式通訊了。
3協議分層與層間介面
3.1協議分層
我們將協議程式碼分成3層：物理層，鏈路層和協議應用層。物理層用於控制UART器件，鏈路層處理XMODEM協議，應用層負責將收到的單個128位元組資料塊組合成一個完成的資料塊，並寫入程式儲存器緩衝區。這種分層，在程式移植時只要修改和硬體相關的物理層、應用層程式碼，無需修改實現XMODEM協議的鏈路層程式碼。
層與層之間透過訊息來通訊，XMODEM協議沒有規定分層結構和層間訊息格式，這裡將鏈路層與應用層之間、鏈路層和物理層之間的訊息格式統一規定如下：
typedefstruct{
intlen;/*訊息內容長度，即Message中的內容位元組數*/
charmType;/*層間訊息型別,*/
charMessage[MAX_MESSAGE_LEN];/*訊息內容,由傳送程序填寫*/
}MessageOfLayer;
考慮到XMODEM資料幀為132位元組，定義常量“MAX_MESSAGE_LEN”為132位元組，按OSI標準，層間訊息原語有資料請求、資料指示、響應、證實4種類型。給出了A方傳送資料，B方接收資料時的層間訊息型別圖6:單向資料傳送的層間訊息順序：①②③④
訊息1，2是承載實際資料的資料幀，訊息3，4是傳送過程中的應答幀，表明資料已經正確傳送，必須說明的是，在傳送資料的證實訊息3不是從對方發出的，物理層在傳送出資料後，立即向上一層發出證實訊息。
在實際應用中，處理正常的資料傳送所需要的訊息外，也需要定義一些控制管理訊息，下面具體說明層間訊息型別和作用。
3.2鏈路層和物理層間的介面
n資料請求：該訊息用於向物理層傳送XMODEM幀資料，包括132位元組的檔案資料幀和NAK,ACK，CAN單位元組訊號幀等，下載軟體只是接收檔案，不需要傳送132位元組的檔案資料幀。
n資料證實：物理層收到鏈路層的資料請求幀後，送到UART的緩衝器中，等傳送緩衝器為空後，表明該位元組資料傳送完成，向鏈路層傳送證實訊息，鏈路層接收到此訊息後，就可以傳送下一個位元組，實際上物理層傳送是一個無連線，證實訊息不是由接收方產生的，不能表明對方已經正確接收到資料，而只表明已經發出資料。物理層協議一般也不提供有應答的傳輸機制。
n資料指示：物理層在接收緩衝器滿後，將資料傳送給鏈路層。
除了以上3個訊息外，物理層和應用層之間還有以下2個訊息：
n啟動電路：由鏈路層向物理層發出，物理層在收到該協議後將串列埠進行初始化。
n電路出錯：由物理層向鏈路層發出，用於報告物理層在資料傳送過程中的錯誤。
“資料響應”訊息在本應用中不使用。
3.3鏈路層和應用層間的介面
鏈路層和應用層之間的資料傳輸訊息有二個：
n資料塊指示：由鏈路層收到一個XMODEM協議幀（128位元組）後向應用層發出，應用層收到資料幀後寫入flashmemory（PC版本寫入檔案）。
n資料塊塊響應：應用層收到XMODEM資料幀後，並寫入flashmemory（PC版本寫入檔案）後向鏈路層發出的響應訊號。鏈路層收到響應後，向檔案傳送方發出“ACK”訊號。
其他管理控制訊息定義了3個：
n協議啟動：應用層通知鏈路層啟動XMODEM協議。
n通訊結束：鏈路層在收到對方的EOT訊號後向應用層發出，應用層收到此訊息後，可以轉入應用程式入口，從而執行應用程式。
n通訊中止：鏈路層因為各種情況無法繼續進行XMODEM傳輸時嚮應用層傳送該訊息，應用層收到此訊息後，丟棄已經收到的資料，發出通訊錯誤指示。
4分層協議實現
4.1協議的OS平臺
為了實現分層協議，使用中的非搶先式作業系統作為軟體平臺，各層分別作為一個程序。
4.2應用層軟體實現
嵌入式系統下載軟體只接收程式碼檔案，對於協議中作為檔案傳送方的處理程式碼可不編寫，應用層的任務是接收鏈路層的資料包，根據收到資料包的先後次序寫入程式儲存器，在PC機上模擬實現時，我們將資料存放在一個緩衝區內，完成後寫入檔案中，使用windiff軟體和傳送檔案進行比較，以判斷程式碼的是否正確。
應用層的程序初始化程式碼的作用是：
n擦除程式儲存器所使用的FLASHMEMORY(在本例中按29F010來編寫程式碼)。
n啟動一個10秒定時器，10秒後通知鏈路層啟動XMODEM協議。
n
：XMODEM協議的控制字元
上表中各個縮寫也是標準ASCII碼的一個字元，在XMODEM協議中需要使用這些字元來表達協議的狀態。而其基本含義如表中所述。
2.2資料幀格式與檔案分解
XMODEM協議每次傳送的資料幀長度為132位元組，其中檔案資料佔128位元組，其他4個位元組分別為開始標誌，塊序號，塊序號的補碼和校驗位元組。其中開始標誌，塊序號，塊序號的補碼位於資料塊開始，校驗位元組位於資料塊結尾，如：
偏移位元組數名稱描述說明
名稱數值(HEX)
01SOH01起始位元組標誌
11Seq1~FFh塊序號
21cmplFFH-seq塊序號的補碼
3128data?檔案內容資料
1311csum?垂直累加和校驗1：XMODEM協議允許使用2種校驗碼。2：校驗碼只從128位元組的資料進行計算後得出，頭部3個位元組不參加校驗和運算。
2CRC?16位迴圈冗餘校驗
圖表3：XMODEM協議的資料幀格式
如果檔案長度不是128位元組的整數倍，最後一個數據塊的有效內容必然小於幀長，剩下部分需要用其他資料來填充，XMODEM建議使用“CTRL-Z”(=26（01aH）)，這種情況下，接收方如何區別該幀中屬於檔案的內容和填充的內容呢？
如果傳送的檔案是隻包含字母、數字和可顯示符號的文字檔案（例如C程式原始碼檔案），那麼根據內容本身接收方是可以區分的（“26”不是字母或者數字的ASCII碼），如果傳送的是任意數值的二進位制檔案（如程式目標碼），則接收方是無法區分檔案內容和填充內容。
重要提示：XMODEM協議不能保證接收方接收的檔案長度和傳送方完全一致，接收方所接收的檔案資料長度總是128位元組的整數倍，比傳送檔案的實際長度要大1到127位元組。多出的內容位於檔案結尾處。
XMODEM協議的這種缺點對於用於嵌入式系統的程式程式碼下裝沒有實際影響，處理器不會將填充內容當作程式碼執行，只要程式儲存器的容量足夠，能儲存接收的所有資料就可以了。如果將XMODEM協議用於資料庫下裝，應當考慮多餘內容的影響，一般標準資料庫檔案中均有表示資料庫尺寸、欄位數、記錄數等資料庫結構引數，所以也不會把填充內容當作資料庫的記錄本身。
同樣，對於漢字型檔這種資料庫，使用XMODEM協議來下載也不會產生問題。
2.3校驗演算法
校驗碼是對傳送資料進行某種計算得到的編碼，為了防止資料在傳送途中某些位發生錯誤，各種資料通訊協議規定傳送方除了傳送應用資料外，還要傳送校驗碼，而資料接收方則根據同樣演算法從收到的應用資料中計算出校驗碼，並和傳送方傳送的校驗碼比較，如相等，才認為收到了正確的資料。
在XMODEM協議中，可使用垂直累加和或者CRC校驗，使用CRC校驗的通訊軟體可以自動從CRC校驗自動切換到累加和校驗模式。在本應用中，我們使用垂直累加和校驗。
累加和校驗碼是將所有傳送資料的和按位元組累加，保留其最低位元組作為校驗碼，例如，傳送的3個位元組資料分別為255（FFh）,5(05h),6(06h),則：
11111111FFH
0000010105H
0000011006H
100001010－>00001010
將高位丟棄後，得到累加和校驗碼為0Ah（10）。在上例中，如果原來資料在途中發生了變化，如FFH變為FEH,06H變為07H,05H未變，則接收方所計算的校驗碼為：
接收發送
11111110FEH
0000010105H
0000011107H
100001010－>00001010
校驗碼也為0AH。可見，在資料中有2位改變時，接收方所計算的校驗碼仍然與傳送方一致，這種校驗方式不能檢測偶數位的誤碼。
XMODEM協議的校驗碼只對資料幀中的128位元組資料進行計算後得出，頭部3個位元組不參加校驗和運算。
2.4XMODEM協議的啟動
XMODEM協議開始是檔案接收方發出“NAK”位元組，檔案傳送方在收到該訊號後傳送資料幀，雙方開始正常通訊過程。而檔案傳送方進入XMODEN協議後，等待對方傳送”NAK”,如果等待時間超過60秒，則退出本次通訊。
接收方發出“NAK”後，如果10秒後對方還沒有傳送第一個資料幀，則重複傳送“NAK”，這種重複次數最多允許10次，仍然沒有收到第一個資料塊，則退出本次通訊。
（A）：傳送方軟體延遲100秒以上工作導致不能啟動協議
（B）：接收方軟體延遲60秒傳送”NAK”訊號導致不能啟動協議
圖表4XMODEM協議不能啟動的2種情況
在嵌入式系統透過PC機來下載軟體的應用中，嵌入式系統軟體是檔案接收方，PC機超級終端軟體是檔案傳送方。按照協議規定，嵌入式系統的通訊軟體進入XMODEM協議狀態後，PC機軟體必須在100秒內進入協議狀態（即執行超級終端的XMODEM檔案傳輸功能），反之，後者先進入協議狀態，前者必須在60秒內進入協議狀態，顯然，透過人工來操作，這種時間差有些緊張。解決辦法只有加長嵌入式系統載入軟體的啟動等待時間，這種修改不會引起協議理解的歧義。
重要提示：為了傳送和接收方能夠更容易啟動XMODEM協議，在設計中，將延長嵌入式系統下載軟體的啟動延時時間，在以下的程式碼中，將這種延時時間改為600秒（10分鐘）。或者將等待時間設定為無限長，一致發出”NAK”訊號，直到PC機上的超級終端軟體執行為止。
2.5XMODEM的正常傳輸過程
中給出了一次正常的XMODEM通訊中收發雙方的通訊過程。
圖5：沒有差錯的檔案傳輸過程
檔案接收方每收到一個數據幀後，如沒有校驗差錯、序號差錯等情況，均傳送一個“ACK”字元作為應答，傳送方在收到應答後才開始傳送下一個字元，如此反覆，直到檔案內容傳送完畢，傳送方傳送“EOT”字元表示傳送完成，傳送方收到後再次以“ACK”迴應，至此，整個檔案傳輸過程就結束了。
2.6XMODEM協議的中止
在通訊進行過程中，雙方中的任意一方如果希望中止本次通訊，可以傳送“CAN”字元給對方，現在很多XMODEM協議軟體要求傳送2個”CAN”字元來實現，
2.7XMODEM協議的異常處理
在通訊過程中，總是要出現各種異常情況，比如通訊線路的突然中斷，一方機器停電而導致軟體中止執行等；通訊軟體必須能夠檢測這些錯誤，並作出合理的處理。在前面的協議啟動一節中已經涉及到了錯誤檢測的問題，XMODEM對錯誤的規定很詳細，共計有8種情況，協議文字沒有說明是如何引起的，中給出了可能原因，
在嵌入式系統中，考慮到下載軟體一般均有人操作的，也可不考慮錯誤處理，這樣實現實現程式碼會減小。在本文中，考慮到協議的完整性，考慮了各種錯誤的處理。
2.8CRC校驗與累加和校驗方式的切換
XMODEM協議要求支援CRC校驗的通訊軟體也能支援累加和校驗，這樣就可以和那些只支援累加和校驗的軟體進行通訊，如果檔案接收方只支援累加和，而傳送方可支援CRC，接收方傳送啟動訊號為“NAK”，傳送方收到後自動按累加和方式傳送資料幀；如果相反，接收方支援CRC，而傳送方支援累加和，接收方首先發出字母“C”來作為啟動訊號，這時接收方應不理睬此訊號，傳送方在3秒後繼續傳送訊號“C”，共三次未收到應答後，改為傳送“NAK”訊號，表示使用累加和方式進行通訊了。
如果通訊雙方均採用CRC校驗，上述通訊握手訊號“NAK”用字母“C來代替，其他過程同上。
因為PC機超級終端軟體支援CRC模式，嵌入式系統作為檔案接收方，只要傳送“NAK”訊號就能使對方自動按照校驗和方式通訊了。
3協議分層與層間介面
3.1協議分層
我們將協議程式碼分成3層：物理層，鏈路層和協議應用層。物理層用於控制UART器件，鏈路層處理XMODEM協議，應用層負責將收到的單個128位元組資料塊組合成一個完成的資料塊，並寫入程式儲存器緩衝區。這種分層，在程式移植時只要修改和硬體相關的物理層、應用層程式碼，無需修改實現XMODEM協議的鏈路層程式碼。
層與層之間透過訊息來通訊，XMODEM協議沒有規定分層結構和層間訊息格式，這裡將鏈路層與應用層之間、鏈路層和物理層之間的訊息格式統一規定如下：
typedefstruct{
intlen;/*訊息內容長度，即Message中的內容位元組數*/
charmType;/*層間訊息型別,*/
charMessage[MAX_MESSAGE_LEN];/*訊息內容,由傳送程序填寫*/
}MessageOfLayer;
考慮到XMODEM資料幀為132位元組，定義常量“MAX_MESSAGE_LEN”為132位元組，按OSI標準，層間訊息原語有資料請求、資料指示、響應、證實4種類型。給出了A方傳送資料，B方接收資料時的層間訊息型別圖6:單向資料傳送的層間訊息順序：①②③④
訊息1，2是承載實際資料的資料幀，訊息3，4是傳送過程中的應答幀，表明資料已經正確傳送，必須說明的是，在傳送資料的證實訊息3不是從對方發出的，物理層在傳送出資料後，立即向上一層發出證實訊息。
在實際應用中，處理正常的資料傳送所需要的訊息外，也需要定義一些控制管理訊息，下面具體說明層間訊息型別和作用。
3.2鏈路層和物理層間的介面
n資料請求：該訊息用於向物理層傳送XMODEM幀資料，包括132位元組的檔案資料幀和NAK,ACK，CAN單位元組訊號幀等，下載軟體只是接收檔案，不需要傳送132位元組的檔案資料幀。
n資料證實：物理層收到鏈路層的資料請求幀後，送到UART的緩衝器中，等傳送緩衝器為空後，表明該位元組資料傳送完成，向鏈路層傳送證實訊息，鏈路層接收到此訊息後，就可以傳送下一個位元組，實際上物理層傳送是一個無連線，證實訊息不是由接收方產生的，不能表明對方已經正確接收到資料，而只表明已經發出資料。物理層協議一般也不提供有應答的傳輸機制。
n資料指示：物理層在接收緩衝器滿後，將資料傳送給鏈路層。
除了以上3個訊息外，物理層和應用層之間還有以下2個訊息：
n啟動電路：由鏈路層向物理層發出，物理層在收到該協議後將串列埠進行初始化。
n電路出錯：由物理層向鏈路層發出，用於報告物理層在資料傳送過程中的錯誤。
“資料響應”訊息在本應用中不使用。
3.3鏈路層和應用層間的介面
鏈路層和應用層之間的資料傳輸訊息有二個：
n資料塊指示：由鏈路層收到一個XMODEM協議幀（128位元組）後向應用層發出，應用層收到資料幀後寫入flashmemory（PC版本寫入檔案）。
n資料塊塊響應：應用層收到XMODEM資料幀後，並寫入flashmemory（PC版本寫入檔案）後向鏈路層發出的響應訊號。鏈路層收到響應後，向檔案傳送方發出“ACK”訊號。
其他管理控制訊息定義了3個：
n協議啟動：應用層通知鏈路層啟動XMODEM協議。
n通訊結束：鏈路層在收到對方的EOT訊號後向應用層發出，應用層收到此訊息後，可以轉入應用程式入口，從而執行應用程式。
n通訊中止：鏈路層因為各種情況無法繼續進行XMODEM傳輸時嚮應用層傳送該訊息，應用層收到此訊息後，丟棄已經收到的資料，發出通訊錯誤指示。
4分層協議實現
4.1協議的OS平臺
為了實現分層協議，使用中的非搶先式作業系統作為軟體平臺，各層分別作為一個程序。
4.2應用層軟體實現
嵌入式系統下載軟體只接收程式碼檔案，對於協議中作為檔案傳送方的處理程式碼可不編寫，應用層的任務是接收鏈路層的資料包，根據收到資料包的先後次序寫入程式儲存器，在PC機上模擬實現時，我們將資料存放在一個緩衝區內，完成後寫入檔案中，使用windiff軟體和傳送檔案進行比較，以判斷程式碼的是否正確。
應用層的程序初始化程式碼的作用是：
n擦除程式儲存器所使用的FLASHMEMORY(在本例中按29F010來編寫程式碼)。
n啟動一個10秒定時器，10秒後通知鏈路層啟動XMODEM協議。
n