基于CAN 通信實現MBD 代碼下載的DSP Bootloader 開發*

郭毅鋒 郭世成 黃麗敏 張 栗

（①廣西科技大學自動化學院，廣西 柳州 545026；②成都大學機械工程學院，四川 成都 610106；③四川省技術轉移中心，四川 成都 610095）

DSP 處理器采用哈佛結構和流水線技術，其接口資源豐富，控制精度高，運算速度快，被廣泛應用在嵌入式系統的各類領域[1-2]。在DSP 嵌入式系統實際應用中，傳統手動編寫代碼方式靈活但耗時長，而基于MBD 的代碼開發方法因其便捷高效的特性被廣泛采用，形成了一套標準的開發流程[3]。然而，MBD 代碼在配合實現一些特殊功能，如Bootloader 時，其靈活性受到一定限制，不便開發。因此，如何在實際應用中實現MBD 代碼的快速便捷下載是一個重要問題。

目前，DSP 芯片最通用的程序下載方式是通過JTAG（joint test action group）接口連接仿真器，并配合使用TI 提供的CCS（code composer studio）集成開發環境實現。這種方式在初期開發和調試階段非常便利和高效[4-5]。但在實際應用中，嵌入式設備通常需要進行封裝保護。在下載程序時必須打開嵌入式設備，這給此過程帶來極大不便[6-7]。標準的JTAG 接口需要13 根引腳，不便于從封裝系統中引出。即便成功引出JTAG 接口，過長的JTAG線可能會導致信號干擾問題，降低了程序升級的可靠性，同時還需要額外的驅動電路，增加了硬件成本。同樣地，通過串口下載也面臨著這個問題，需要額外引出接口，十分不便。

在這一背景下，CAN 總線則成為較為理想的下載方式，尤其在汽車電子領域表現出色。CAN總線僅需2 根引腳，具有實時性強、傳輸距離遠、抗電磁干擾等優勢。在實際應用中，CAN 總線既可以用于不同設備間的通信又可以兼顧下載的功能，無需額外引出下載接口，是較為理想的下載方式。

本文以TMS320F28335 為例，針對嵌入式系統中在實際應用中MBD 代碼的下載需求，開發了一種適用于MBD 代碼的基于CAN 通信的Bootloader方案，解決了在實際應用和現場快速調試過程中，快速且便捷更新程序的問題。通過利用CAN 通信技術，實現對MBD 代碼的快速、穩定地下載。在方案設計過程中，對MBD 代碼的結構進行了深入分析?；诜治鼋Y果，設計了合理的Boot 程序和MBD 程序方案和內存劃分方案，減少了對MBD 代碼的大幅度改動，無需在程序更新時重復修改MBD 代碼，確保了程序下載的有效性和穩定性。在具體實現過程中，開發了相應的Boot 程序和上位機程序，詳細介紹了Bootloader 的實現流程，并對關鍵步驟函數進行了深入的分析與解釋。通過CAN 通信實現了對MBD 代碼的快速下載，實驗結果表明該方法穩定可靠且具有實用性。

1 方法介紹

該方法的整體結構如圖1 所示，包括CAN 調試卡、上位機、Boot 程序和MBD 程序。Boot 程序和MBD 程序是兩個獨立的工程，Boot 程序預先通過JTAG 接口與仿真器連接下載到DSP 的Flash 中，實現與上位機的通信、擦除Flash、燒寫程序、引導程序等功能。在Simulink 中搭建程序模型，自動生成代碼后，導入CCS 中，修改MBD 代碼底層文件，編譯轉換生成MBD 程序的.bin 文件，將.bin 文件傳輸到上位機中，準備進行燒寫操作。重啟設備，上位機調用CAN 調試卡，將MBD 程序通過CAN通信協議燒寫到目標設備的指定Flash 區域。傳輸完成后，Boot 程序執行引導功能，跳轉到MBD 程序所在的Flash 區域開始運行。通過這一流程，MBD代碼便可成功通過CAN 通信下載到TMS320F28335嵌入式系統中并運行，滿足了實際應用中的需求。

圖1 方法結構圖

2 MBD 程序分析與設定

2.1 MBD 代碼結構分析

將Simulink 中搭建的模型進行自動代碼生成后，導入到CCS 中，整個目標程序的結構如圖2 所示，主要分為三部分。

圖2 MBD 代碼結構圖

（1）.c 類文件中包含了由模型生成的代碼以及主程序，還包括使用到的ADC、CAN、eCAP 等功能函數，這些文件負責實現系統的邏輯功能和算法。

（2）.asm 文件用于編寫底層指令、優化性能、實現硬件接口和處理中斷等任務，通過直接控制DSP 處理器，開發人員能夠更加靈活地利用硬件資源，實現高效的數字信號處理。.asm 文件提供了對DSP 處理器的底層控制能力，從而滿足特定的系統需求。

（3）Include 文件夾中包含了一些必要的庫函數以及.cmd 文件，這些文件用于引用所需的庫函數和定義內存分配等信息，幫助實現系統功能的完整性和正確性[8-9]。

2.2 Boot 程序與MBD 程序的內存分配方案

Bootloader 的核心是把Boot 程序與MBD 程序燒寫到不同的Flash 空間中，Boot 程序與MBD 程序應是相互獨立的兩個功能[10-11]。因此要對Boot 程序與MBD 程序進行合理的功能與內存空間分配，保證兩者互不影響，同時減少對MBD 程序的改動。對于手動編寫的程序，只需要修改工程中的.cmd 文件即可對內存進行劃分，而對于MBD 自動生成代碼的程序來講，根據MBD 代碼結構分析，則需要在Includes 目錄下的C:ProgramDataMATLABSupport PackagesR2021b oolbox argetsupportpackages ic2000src（不同PC 安裝目錄不同）目錄下找到對應芯片的.cmd 文件。以TMS320F28335 芯片為例，對應的是c28335.cmd 文件，通過修改c28335.cmd 文件對Flash 空間進行分配。

根據c28335.cmd 里的信息，可以得知MBD 自動生成代碼后，不同于傳統的Flash 分配方式，將0x300000-0x33fff6 劃分為A-H 區（圖3a），MBD生成的代碼將Flash 空間劃分成了一個區域（圖3b）用于存儲應用程序，保證應用程序最大限度利用Flash 空間存放應用程序，并沒有考慮其他功能的擴展。0x33fff6-0x33fff8 則保持一致，被分配為應用程序的BEGIN 區。

圖3 默認內存劃分

圖4a 所示為經過修改后的MBD 程序的內存分配情況。與默認分區相比，修改后的分區把0×310000-0×310010 分配為應用程序信息區，用于存儲MBD 程序的版本等相關信息，以便上位機讀取當前應用程序版本；0×310010-0×310012 為應用程序的BEGIN 區，用于引導程序跳轉到應用程序入口；0×310012-0×33ff80 用于存儲應用程序。圖4b所示為Boot 程序的內存分配情況，MBD 程序未使用的區域0×300000-0×310000 被用來存儲Boot 程序；0×33fff6-0×33fff8 分配為Boot 程序的BEGIN 區。通過這樣的內存劃分方式，Boot 程序與MBD 程序以及它們各自的BEGIN 區完全隔離開來，位于不同的內存區域中，從而實現了兩部分程序之間的相互獨立，避免了彼此的干擾。

圖4 修改后內存劃分

2.3 程序格式轉換

CCS 進行編譯時，通常會生成.out 文件。.out文件是一個完整的可執行文件，包含了代碼、符號表和調試信息，用于在嵌入式系統上執行和調試，但不適用于直接燒寫。CCS 可以將.out 文件轉換生成.bin 文件，.bin 文件是目標代碼的二進制表示，沒有附加信息，通常用于直接燒錄到目標設備的存儲器中[12-13]。根據上述特性，如圖5 所示，對于Boot 程序來講，可直接利用仿真器通過JTAG 口下載.out 文件，對于MBD 程序來講，通過CAN 通信燒寫時則需要CCS 編譯程序并轉換成.bin 文件。

圖5 程序格式

3 Boot 程序與上位機程序設計

內存分配完成之后，需設計相應的Boot 程序與上位機程序。Boot 程序完成程序跳轉、燒寫程序等功能。上位機程序要與CAN 通訊設備配套，完成程序解析、指令發送等功能。

3.1 程序流程

實現完整的Bootloader 功能需要Boot 程序和上位機之間的協同配合。程序流程如圖6 所示。上電復位后，程序跳轉到Boot 程序的BEGIN 區，BEGIN區中存放著codestart 函數。該函數包含一個跳轉指令，將程序引導跳轉至_c_int00 處，而_c_int00 函數將程序引導跳轉至Boot 程序的main 函數。Boot程序完成CAN 通信初始化、系統初始化和中斷初始化等功能，然后進入等待狀態。定時器開始計時，如果定時器時間超時，則通過jump 函數直接跳轉到MBD 程序的BEGIN 區。同樣地，利用_c_int00函數將程序引導跳轉至MBD 程序的main 函數處。

圖6 程序流程

如果定時器時間未超時且接收到上位機的更新命令，則Boot 程序進入Boot 模式，并向上位機返回成功信息。上位機發送擦除MBD 程序區的指令，Boot 程序利用Flash_Erase() 函數擦除MBD 程序所在區域，并返回擦除成功信息。上位機解析MBD程序的bin 文件，并將程序分包發送。Boot 程序接收到程序數據后返回接收成功標志。然后上位機發送CRC 校驗碼，Boot 程序進行CRC 校驗。如果校驗成功，Boot 程序將程序寫入預分配的MBD 程序Flash 區域，并返回寫入完成信息給上位機。上位機判斷是否發送完整個程序，如果未發送完畢，則重復執行分包-校驗-發送指令的過程。如果發送完畢，則發送跳轉指令。Boot 程序利用jump 函數跳轉至MBD 程序的BEGIN 區，然后通過調用_c_int00函數進入MBD 程序。

為了確保Bootloader 功能的安全性，程序中對Flash 的操作需放到RAM 中運行。將Flash 操作代碼加載到RAM 中可以避免更新操作覆寫Boot 程序自身的風險，并提高執行速度和效率。然而，將Flash 操作代碼加載到RAM 中會占用一定的RAM空間。因此，在將應用程序寫入Flash 存儲器時，需要將程序分成多個包進行傳輸，以適應可用的RAM 大小。

通過以上步驟和安全策略，實現了利用CAN通信燒寫MBD 程序并跳轉到MBD 程序入口點的功能，完成了板子的固件升級和功能擴展。

3.2 錯誤處理

在Bootloader 更新過程中，需要進行錯誤處理。如圖7 所示，Boot 程序實現了一系列故障處理流程，以確保安全和可靠的固件更新。

圖7 故障處理流程

如果在擦除MBD 程序區時出現失敗，Boot 程序會發送一條報文返回上位機擦除失敗的信息，并提示相應的故障信息。上位機會接收并顯示此信息，表示更新失敗。這樣可以及時通知上位機發生了擦除錯誤，避免繼續更新過程，以保護設備免受潛在風險。

在接收程序過程中，Boot 程序會進行CRC 校驗，以驗證寫入的程序數據的完整性和準確性。若某段程序的CRC 校驗失敗，上位機會重新發送相應的數據段。如果連續三次校驗失敗，則判定數據可能存在嚴重錯誤，終止程序更新，并向上位機提示CRC 校驗失敗。這樣可以避免持續嘗試更新錯誤的數據，防止設備損壞或產生不穩定的行為。

如果在寫入Flash 的步驟中發生寫入錯誤，Boot 程序會通過相應的錯誤指令將錯誤信息返回給上位機。同時，上位機會終止更新程序，確保不會將錯誤的數據寫入設備。這樣可以保護設備免受寫入錯誤可能引發的問題。

3.3 關鍵函數分析

jump 函數是實現Bootloader 功能中關鍵的跳轉函數，如下所示，聲明一個名為jump 的函數，接收一個uint32_t 類型的參數Addr，表示需跳轉的地址。

在函數內部，通過將傳入的地址強制類型轉換為函數指針類型，然后調用該函數指針，實現了跳轉到指定地址的功能。通過這樣的方式，jump 函數可以實現跳轉到指定地址。根據給定的地址，將控制權轉移到該地址處的程序代碼，實現從引導程序跳轉到應用程序。在引導程序中，可以使用此代碼來加載并執行應用程序，實現固件升級或切換應用程序的功能。

_c_int00 是一個特殊的函數，它在啟動和重置過程中起到重要的作用。_c_int00 函數通常是由芯片廠商提供的匯編代碼實現，用于處理啟動和重置事件。如圖8 所示，在Boot 程序中可利用jump 函數跳轉到MBD 程序codestart 所在地址處，調用_c_int00 函數執行一系列系統初始化操作，為系統設置合適的初始狀態，并最終跳轉到MBD 程序的入口點。

圖8 跳轉流程

3.4 通信報文格式規范

考慮到現場中CAN 總線上一些報文的干擾情況，本文在報文幀定義中進行了一定處理，為了保證通信的可靠性和一致性，在Boot 程序與上位機程序之間的通信中，需要明確指定報文的ID，通過固定報文的ID，Boot 程序和上位機程序可以識別和過濾掉其他無關的報文，避免無效報文的干擾和誤解析，確保通信的可靠性和準確性[14-15]。

CAN 通信的8 個字節數據位的劃分，基本的指令可以按照表1 進行定義。對于上位機，第一字節代表指令CMD，用于發送更新、清除等命令的指令代碼；第二字節數據長度DA_LN 代表后續數據的長度，指示接收方應該讀取多少個數據字節；第三到第八字節D1-D6 包含實際的數據信息，根據數據長度來確定字節數。對于Boot 程序，第一字節狀態信息Status 返回Boot 程序執行狀態的信息，用于指示操作的結果或錯誤情況；第二字節數據長度與第三到第八字節數據字節與上位機報文定義一樣。

表1 報文格式

通過對報文的數據位的劃分，可以在CAN 通信中明確定義數據的含義和格式。上位機可以將指令和數據按照預定的格式發送給Boot 程序，而Boot 程序接收到數據后可以根據定義的格式解析和處理數據。

對于這段開關互市的歷史，在遼東滿族民眾的記憶中也有記載和表現。最有代表性的就是在桓仁地區采錄的《老杲子》[注]夏秋主編：《滿族民間故事·遼東卷》上卷，遼寧民族出版社，2010年，第12頁。，其內容如下：

4 實驗驗證

4.1 功能性驗證

TMS320F28335 中，提供了兩個CAN通道口CANA和CANB，選擇CANA 通道進行實驗，在Boot 程序中配置好通道口、波特率、幀類型、數據長度、發送和接收ID 等，然后按圖9 測試環境進行硬件連接。連接完成后，通過JTAG 口預先將Boot 程序下載到TMS320F28335 的Flash 中，之后開始驗證Bootloader 功能，操作步驟如下。

圖9 測試環境1

（1）如圖10 測試程序所示，在Simulink 中搭建任意一段CAN 通信的模型，實驗中實現的功能是，將CAN 通信收到的信息重新發送出來。模型搭建完成后，通過編譯自動生成代碼。

圖10 測試程序

（2）將代碼導入到CCS 中編譯轉換生成.bin文件。

（3）將.bin 文件導入到上位機中。

（4）系統板上電，上位機發送更新命令，按照流程把MBD 程序燒寫到劃分好的Flash 區中，燒寫完成后，自動跳轉到MBD 程序的起始地址，MBD 程序開始運行。

此時，可測試MBD 程序是否下載成功且運行，如圖11 所示，上位機發送ID 為1801D0D0，數據為00 11 22 33 44 55 66 77 的報文，TMS320F28335返回ID 為18F101D0，數據為00 11 22 33 44 55 66 77 的報文（圖11）。上位機再次發送數據為20 23 07 20 10 47 04 的報文，TMS320F28335 同樣可以返回發送的報文（圖12），證明程序通過CAN 通信燒寫成功，Bootloader 功能實現。

圖11 測試結果1

圖12 測試結果2

Boot 程序預先刷寫完成后，如圖13 所示，MBD 程序的下載也可以在CCS 中選擇不擦除Boot程序的Flash 區，即可在保留Boot 程序的情況下將MBD 程序從JTAG 口燒寫進去，方便程序開發與在線調試。下載完成后，程序運行結果與CAN 下載后的效果一致。

圖13 JTAG 下載設置

4.2 可靠性驗證

在嵌入式系統應用場景中，設備之間的通信普遍是近距離的，通常在數米范圍內，而CAN 總線中通常使用的波特率是500 kbps 或250 kbps。因此，如圖14 所示，可靠性測試選擇用3.3 m 的連接線連接到已裝上外殼封裝設備上，CAN 卡1 用于下載測試程序，CAN 卡2 用于總線上持續不斷地發送不同數量的報文，作為總線上的干擾。以250 kbps和500 kbps 波特率，分別在有無干擾情況下對32 kB和27 kB 的程序.bin 程序進行下載試驗測試，可以有效驗證大多數嵌入式系統的應用場景。下載時間不計DSP 芯片自身擦除Flash 區的時間，測試結果及測試環境如下。

圖14 測試環境2

（1）無干擾情況

為保證測試的準確性，下載時間均為連續實驗3 次記錄時間后的平均值。根據表2，下載32 kB的程序，在500 kbps 波特率的情況下，成功下載所需的時間約為7.527 s。且在不同情況下，平均下載速度約為4 kB/s，滿足了現場調試的實際需求。

表2 無干擾測試

（2）有干擾情況

32 kB 大小的程序在不同干擾情況下進行了下載測試，考慮了不同數量的干擾幀。結果顯示，程序在這些情況下都能夠成功下載，而與沒有干擾情況相比，下載時間只增加了約5%，見表3。即使在CAN 總線上連續發送最多12 個干擾幀的情況下，仍然能夠保持一定的下載速度，有效驗證了該方案的可靠性。

表3 干擾測試

通過實驗得出，本文的方案能夠在嵌入式系統中，在一定距離、不同波特率和總線受到干擾的情況下，實現對程序的穩定下載。且下載程序時，無需打開嵌入式設備，實現了在實際應用中的便捷快速下載，提高了現場調試以及實際開發中的效率和可靠性。

5 結語

本文提出了一種基于CAN 通信的Bootloader 方案，旨在解決DSP 嵌入式系統中MBD 開發方式下代碼的便捷下載需求。以TMS320F28335 為例，通過對MBD 代碼的結構進行分析，在保證對MBD代碼改動較小的情況下，設計了合理的Boot 程序和MBD 程序方案以及內存劃分方案，確保程序下載的有效性和穩定性，并且無需在更新MBD 程序時重復修改代碼；開發了相應的Boot 程序和上位機程序，詳細介紹了Bootloader 的實現流程，并對關鍵步驟函數進行了深入的分析與解釋。通過CAN通信成功實現了對MBD 代碼的快速下載，實驗結果表明該方法穩定可靠且具有實用性。并且具有一定的通用性，可運用到TI 的其他系列芯片中。