基于CAN 通信實(shí)現(xiàn)MBD 代碼下載的DSP Bootloader 開發(fā)*

郭毅鋒 郭世成 黃麗敏 張 栗

（①廣西科技大學(xué)自動化學(xué)院，廣西 柳州 545026；②成都大學(xué)機(jī)械工程學(xué)院，四川 成都 610106；③四川省技術(shù)轉(zhuǎn)移中心，四川 成都 610095）

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

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

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

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

1 方法介紹

該方法的整體結(jié)構(gòu)如圖1 所示，包括CAN 調(diào)試卡、上位機(jī)、Boot 程序和MBD 程序。Boot 程序和MBD 程序是兩個獨(dú)立的工程，Boot 程序預(yù)先通過JTAG 接口與仿真器連接下載到DSP 的Flash 中，實(shí)現(xiàn)與上位機(jī)的通信、擦除Flash、燒寫程序、引導(dǎo)程序等功能。在Simulink 中搭建程序模型，自動生成代碼后，導(dǎo)入CCS 中，修改MBD 代碼底層文件，編譯轉(zhuǎn)換生成MBD 程序的.bin 文件，將.bin 文件傳輸?shù)缴衔粰C(jī)中，準(zhǔn)備進(jìn)行燒寫操作。重啟設(shè)備，上位機(jī)調(diào)用CAN 調(diào)試卡，將MBD 程序通過CAN通信協(xié)議燒寫到目標(biāo)設(shè)備的指定Flash 區(qū)域。傳輸完成后，Boot 程序執(zhí)行引導(dǎo)功能，跳轉(zhuǎn)到MBD 程序所在的Flash 區(qū)域開始運(yùn)行。通過這一流程，MBD代碼便可成功通過CAN 通信下載到TMS320F28335嵌入式系統(tǒng)中并運(yùn)行，滿足了實(shí)際應(yīng)用中的需求。

圖1 方法結(jié)構(gòu)圖

2 MBD 程序分析與設(shè)定

2.1 MBD 代碼結(jié)構(gòu)分析

將Simulink 中搭建的模型進(jìn)行自動代碼生成后，導(dǎo)入到CCS 中，整個目標(biāo)程序的結(jié)構(gòu)如圖2 所示，主要分為三部分。

圖2 MBD 代碼結(jié)構(gòu)圖

（1）.c 類文件中包含了由模型生成的代碼以及主程序，還包括使用到的ADC、CAN、eCAP 等功能函數(shù)，這些文件負(fù)責(zé)實(shí)現(xiàn)系統(tǒng)的邏輯功能和算法。

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

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

2.2 Boot 程序與MBD 程序的內(nèi)存分配方案

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

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

圖3 默認(rèn)內(nèi)存劃分

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

圖4 修改后內(nèi)存劃分

2.3 程序格式轉(zhuǎn)換

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

圖5 程序格式

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

內(nèi)存分配完成之后，需設(shè)計相應(yīng)的Boot 程序與上位機(jī)程序。Boot 程序完成程序跳轉(zhuǎn)、燒寫程序等功能。上位機(jī)程序要與CAN 通訊設(shè)備配套，完成程序解析、指令發(fā)送等功能。

3.1 程序流程

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

圖6 程序流程

如果定時器時間未超時且接收到上位機(jī)的更新命令，則Boot 程序進(jìn)入Boot 模式，并向上位機(jī)返回成功信息。上位機(jī)發(fā)送擦除MBD 程序區(qū)的指令，Boot 程序利用Flash_Erase() 函數(shù)擦除MBD 程序所在區(qū)域，并返回擦除成功信息。上位機(jī)解析MBD程序的bin 文件，并將程序分包發(fā)送。Boot 程序接收到程序數(shù)據(jù)后返回接收成功標(biāo)志。然后上位機(jī)發(fā)送CRC 校驗(yàn)碼，Boot 程序進(jìn)行CRC 校驗(yàn)。如果校驗(yàn)成功，Boot 程序?qū)⒊绦驅(qū)懭腩A(yù)分配的MBD 程序Flash 區(qū)域，并返回寫入完成信息給上位機(jī)。上位機(jī)判斷是否發(fā)送完整個程序，如果未發(fā)送完畢，則重復(fù)執(zhí)行分包-校驗(yàn)-發(fā)送指令的過程。如果發(fā)送完畢，則發(fā)送跳轉(zhuǎn)指令。Boot 程序利用jump 函數(shù)跳轉(zhuǎn)至MBD 程序的BEGIN 區(qū)，然后通過調(diào)用_c_int00函數(shù)進(jìn)入MBD 程序。

為了確保Bootloader 功能的安全性，程序中對Flash 的操作需放到RAM 中運(yùn)行。將Flash 操作代碼加載到RAM 中可以避免更新操作覆寫B(tài)oot 程序自身的風(fēng)險，并提高執(zhí)行速度和效率。然而，將Flash 操作代碼加載到RAM 中會占用一定的RAM空間。因此，在將應(yīng)用程序?qū)懭隖lash 存儲器時，需要將程序分成多個包進(jìn)行傳輸，以適應(yīng)可用的RAM 大小。

通過以上步驟和安全策略，實(shí)現(xiàn)了利用CAN通信燒寫MBD 程序并跳轉(zhuǎn)到MBD 程序入口點(diǎn)的功能，完成了板子的固件升級和功能擴(kuò)展。

3.2 錯誤處理

在Bootloader 更新過程中，需要進(jìn)行錯誤處理。如圖7 所示，Boot 程序?qū)崿F(xiàn)了一系列故障處理流程，以確保安全和可靠的固件更新。

圖7 故障處理流程

如果在擦除MBD 程序區(qū)時出現(xiàn)失敗，Boot 程序會發(fā)送一條報文返回上位機(jī)擦除失敗的信息，并提示相應(yīng)的故障信息。上位機(jī)會接收并顯示此信息，表示更新失敗。這樣可以及時通知上位機(jī)發(fā)生了擦除錯誤，避免繼續(xù)更新過程，以保護(hù)設(shè)備免受潛在風(fēng)險。

在接收程序過程中，Boot 程序會進(jìn)行CRC 校驗(yàn)，以驗(yàn)證寫入的程序數(shù)據(jù)的完整性和準(zhǔn)確性。若某段程序的CRC 校驗(yàn)失敗，上位機(jī)會重新發(fā)送相應(yīng)的數(shù)據(jù)段。如果連續(xù)三次校驗(yàn)失敗，則判定數(shù)據(jù)可能存在嚴(yán)重錯誤，終止程序更新，并向上位機(jī)提示CRC 校驗(yàn)失敗。這樣可以避免持續(xù)嘗試更新錯誤的數(shù)據(jù)，防止設(shè)備損壞或產(chǎn)生不穩(wěn)定的行為。

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

3.3 關(guān)鍵函數(shù)分析

jump 函數(shù)是實(shí)現(xiàn)Bootloader 功能中關(guān)鍵的跳轉(zhuǎn)函數(shù)，如下所示，聲明一個名為jump 的函數(shù)，接收一個uint32_t 類型的參數(shù)Addr，表示需跳轉(zhuǎn)的地址。

在函數(shù)內(nèi)部，通過將傳入的地址強(qiáng)制類型轉(zhuǎn)換為函數(shù)指針類型，然后調(diào)用該函數(shù)指針，實(shí)現(xiàn)了跳轉(zhuǎn)到指定地址的功能。通過這樣的方式，jump 函數(shù)可以實(shí)現(xiàn)跳轉(zhuǎn)到指定地址。根據(jù)給定的地址，將控制權(quán)轉(zhuǎn)移到該地址處的程序代碼，實(shí)現(xiàn)從引導(dǎo)程序跳轉(zhuǎn)到應(yīng)用程序。在引導(dǎo)程序中，可以使用此代碼來加載并執(zhí)行應(yīng)用程序，實(shí)現(xiàn)固件升級或切換應(yīng)用程序的功能。

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

圖8 跳轉(zhuǎn)流程

3.4 通信報文格式規(guī)范

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

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

表1 報文格式

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

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

4 實(shí)驗(yàn)驗(yàn)證

4.1 功能性驗(yàn)證

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

圖9 測試環(huán)境1

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

圖10 測試程序

（2）將代碼導(dǎo)入到CCS 中編譯轉(zhuǎn)換生成.bin文件。

（3）將.bin 文件導(dǎo)入到上位機(jī)中。

（4）系統(tǒng)板上電，上位機(jī)發(fā)送更新命令，按照流程把MBD 程序燒寫到劃分好的Flash 區(qū)中，燒寫完成后，自動跳轉(zhuǎn)到MBD 程序的起始地址，MBD 程序開始運(yùn)行。

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

圖11 測試結(jié)果1

圖12 測試結(jié)果2

Boot 程序預(yù)先刷寫完成后，如圖13 所示，MBD 程序的下載也可以在CCS 中選擇不擦除Boot程序的Flash 區(qū)，即可在保留Boot 程序的情況下將MBD 程序從JTAG 口燒寫進(jìn)去，方便程序開發(fā)與在線調(diào)試。下載完成后，程序運(yùn)行結(jié)果與CAN 下載后的效果一致。

圖13 JTAG 下載設(shè)置

4.2 可靠性驗(yàn)證

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

圖14 測試環(huán)境2

（1）無干擾情況

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

表2 無干擾測試

（2）有干擾情況

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

表3 干擾測試

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

5 結(jié)語

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