本發(fā)明屬于工業(yè)自動化領域，涉及基于Ymodem協(xié)議的TI C2000 DSP串口在線升級方法。本發(fā)明具有較大的可移植性，可以用在C2000系列DSP處理器的各種電子設備中。
背景技術：
TI C2000 DSP是TI公司推出的在自動控制和信號處理領域具有定/浮點處理能力的數(shù)字信號處理器，廣泛應用于工業(yè)控制、移動通信，軍事安全領域。
隨著電子技術的發(fā)展和用于需求的提升，對已經投入使用的DSP嵌入式設備軟件的維護更新就越來越平凡，當進行程序升級的時候，要擦除芯片內容并重新燒寫新的程序代碼和數(shù)據(jù)，通常使用TI公司的CCS燒寫插件并通過仿真器JTAG口對片上Flash進行編程。雖然該方法簡單易用，但一般只在程序的開發(fā)和調試階段使用，然而在復雜的工作環(huán)境下，直接取下設備，連接仿真器都有極大的困難，或者現(xiàn)場還存在不能拆開設備的情況。此外，TI芯片自帶的BootROM還提供了基于其他設備接口(如SCI，SPI，CAN，I2C)的在線升級，這些通信接口需要配合第三方的軟件對芯片進行在線加載與升級。雖然提供了便利，但是基于TI提供的在線加載，需要外部專用引腳的事先配置，這給系統(tǒng)的設計帶來了困難，尤其是當模塊整合到整機系統(tǒng)之后，硬件外部引腳的實現(xiàn)配置存在困難。為此需要一種不依賴JTAG口仿真器，尤其是不需要芯片外部引腳提前配置的系統(tǒng)在線升級方法，同時不局限于上電加載在線升級和不依賴TI自帶的一級Bootloader的方法。
技術實現(xiàn)要素：
本發(fā)明的目的在于提供基于Ymodem協(xié)議的TI C2000 DSP串口在線升級方法。解決了嵌入式TI C2000系列DSP處理器在線升級的不方便的問題。本發(fā)明不采用JTAG仿真器，不借助芯片一級Bootloader交互，不需要提前配置芯片外專用引腳，不需要上下電重啟，不需要硬件系統(tǒng)提交外擴存儲空間支持。
為了實現(xiàn)上述目的，本發(fā)明采用的技術方案如下：
基于Ymodem協(xié)議的TI C2000 DSP串口在線升級方法，該方法主要是將已實現(xiàn)Ymodem協(xié)議的自定義二級Bootloader程序預先燒寫到DSP Flash內部，之后無需配置任何外部借助于該Bootloader完成用戶需要升級的可執(zhí)行文件的可靠傳輸，待鏡像文件通過CRC校驗之后，將其燒寫入DSP Flash內部，完成用戶程序的在線更新。用戶可以在任何時刻發(fā)送在線升級指令，系統(tǒng)將跳轉到自定義Bootloader程序輔助完成應用程序的在線升級。由于程序代碼的在線升級最后一步都是需要調用Flash API完成應用程序對應Flash存儲空間的讀、擦、寫、驗證等基本功能函數(shù)完成應用程序鏡像的固化。一般不同系列和批次芯片的Flash API時序有差異，并且要求嚴格，所以相對的Flash API均是由芯片官方提供，比如TI為TMS320F281x與TMS320F282xx/3xx，以及TMS320F2837x均提供了對應的Flash API。
具體包括如下步驟：
S1、上位機根據(jù)Ymodem通信協(xié)議通過對應的串行通信接口SCI，將應用程序的鏡像文件以數(shù)據(jù)幀的形式加載/緩存到目標系統(tǒng)DSP；這個過程中不需要芯片外部引腳提前配置，同時不局限于上電加載在線，也不使用TI自帶的Bootloader提供的交互協(xié)議。
S2、目標系統(tǒng)DSP CRC校驗接收數(shù)據(jù)幀，并完成鏡像文件數(shù)據(jù)拼幀操作，得到完整的應用程序鏡像文件，然后調用C2000系列芯片對應的TI Flash API完成應用程序鏡像文件的燒錄固化。
在線升級前期應用程序鏡像文件的加載與緩存，分別需要對應通信接口、通信協(xié)議以及鏡像緩存存儲區(qū)域支持，在本發(fā)明中，通信接口選用串行通信接口SCI，可以根據(jù)現(xiàn)場環(huán)境的惡劣情況配合整機系統(tǒng)選擇不同的接口電平，包括RS232，RS422，RS485，LVDS等。通信協(xié)議使用Ymodem協(xié)議，Ymodem協(xié)議是一種發(fā)送并等待的協(xié)議，即發(fā)送方發(fā)送一個數(shù)據(jù)包以后，都要等待接收方的確認，包括每一個數(shù)據(jù)包的CRC校驗，如果是ACK信號，則可以發(fā)送新的包；如果是NAK信號，則重發(fā)或者錯誤退出。對于鏡像緩存則根據(jù)系統(tǒng)硬件設計是否外擴存儲器來選擇是否緩存完整的鏡像。由于實際應用程序的鏡像不小是不固定的，可以小至幾KB，也可大至幾百KB，根據(jù)不同系列的DSP存儲空間的配置和應用場景的需求，可以選擇使用DSP芯片內部的存儲區(qū)或者外擴存儲區(qū)作為鏡像的緩存區(qū)，所以可以每一次緩存部分鏡像數(shù)據(jù)并校驗之后寫入芯片內Flash，如果硬件已經外擴了存儲空間SDRAM/SRAM，也可以選擇緩存完完整的鏡像數(shù)據(jù)，校驗之后再燒寫入芯片內Flash。
所述步驟S1的具體實現(xiàn)過程如下：
a1、上位機首先向目標系統(tǒng)DSP發(fā)送在線升級指令，等待目標系統(tǒng)確認；
a2、目標系統(tǒng)DSP接收并確認命令后從應用程序跳轉至自定義Bootloader中使用Ymodem協(xié)議等待接收應用程序鏡像文件；
a3、上位機讀取需要升級的應用程序鏡像.out文件，轉換為目標系統(tǒng)DSP需要的bin文件；
a4、上位機使用Ymodem協(xié)議將應用程序鏡像.bin文件向目標系統(tǒng)DSP分幀發(fā)送，每一幀伴隨CRC校驗值，上位機首先傳送應用程序鏡像文件的文件名并等待目標系統(tǒng)回顯；
a5、上位機接收目標系統(tǒng)DSP確認之后，開始將應用程序鏡像文件數(shù)據(jù)分幀發(fā)送，并等待目標系統(tǒng)DSP每一個分幀的ACK確認；
a6、上位機連續(xù)分幀發(fā)送應用程序鏡像文件，并顯示發(fā)送進度與速度；
a7、上位機發(fā)送完完整的應用程序鏡像文件，發(fā)送結束指令EOT，目標系統(tǒng)DSP確認后回應ACK。
進一步地，所述步驟a4中，應用程序鏡像.bin文件每一幀發(fā)送128字節(jié)或者1024字節(jié)。
更進一步地，所述步驟a5中，上位機如果接收NAK，啟動重傳直到超出重傳次數(shù)上限，并報告失敗。
所述步驟S2的具體實現(xiàn)過程為：
b1、目標系統(tǒng)DSP上電之后執(zhí)行正常的應用程序服務；
b2、目標系統(tǒng)DSP接收到上位機的升級請求，回復確認，CPU跳轉到預定義的Bootloader執(zhí)行，并使用Ymodem協(xié)議監(jiān)聽上位機的數(shù)據(jù)傳送；否則視為非法指令，直接忽略；
b3、目標系統(tǒng)DSP接收到上位機將要發(fā)送的應用程序鏡像文件的文件名，并回顯鏡像文件名給上位機；
b4、目標系統(tǒng)DSP接收到上位機發(fā)送的分幀數(shù)據(jù)，對每一幀數(shù)據(jù)進行CRC校驗，通過校驗則回復ACK數(shù)據(jù)包，通知上位機繼續(xù)傳送下一分幀，否則回復NAK，并丟棄當前分幀，并等待上位機重傳；
b5、目標系統(tǒng)DSP根據(jù)硬件設計選擇是否緩存所有分幀直到鏡像文件接收完畢，如果目標系統(tǒng)只能緩存一幀，則選擇步驟b6，否則選擇步驟b7；
b6、目標系統(tǒng)DSP首先調用Flash API將原鏡像區(qū)域擦除，并在接收到通過校驗的每一分幀數(shù)據(jù)后，立即燒錄到DSP Flash，直到所有的分幀數(shù)據(jù)傳送完畢和燒錄完畢；
b7、目標系統(tǒng)DSP將校驗完整的鏡像文件，確認無誤之后，調用Flash API燒錄到DSP Flash；
b8、目標系統(tǒng)DSP接收到上位機發(fā)送的傳送結束指令EOT，目標系統(tǒng)DSP回應ACK完成鏡像文件的完整接收，握手結束。
進一步地，在執(zhí)行完步驟b8后，跳轉到已經升級的應用程序，開始執(zhí)行新升級的應用程序。
所述步驟b7中，目標系統(tǒng)DSP將完整的鏡像文件緩存于目標系統(tǒng)DSP外擴的存儲空間SDRAM/SRAM。
與現(xiàn)有技術相比，本發(fā)明具有以下有益效果：
(1)本發(fā)明將已實現(xiàn)Ymodem協(xié)議的自定義二級Bootloader程序預先燒寫到DSP Flash內部，之后無需配置任何外部專用引腳，只是通過指令完成升級引導，通過串口SCI實現(xiàn)用戶需要升級的可執(zhí)行文件的可靠傳輸，待鏡像文件通過CRC校驗之后，將其燒寫入DSP Flash內部，用戶可以在任何時刻發(fā)送在線升級指令，且無需芯片硬件外部提前配置，不依賴芯片TI一級BootLoader。
(2)本發(fā)明使用通信接口串口SCI實現(xiàn)程序的在線升級，無需外部JTAG仿真器的支持，連線少，簡單易實現(xiàn)，可以根據(jù)現(xiàn)場環(huán)境的惡劣情況選擇不同的接口電平，包括RS232，RS422，RS485，LVDS等，特別適合在整機系統(tǒng)以及復雜環(huán)境下中給單機模塊的升級。
附圖說明
圖1為本發(fā)明-實施例的流程圖。
具體實施方式
下面結合實施例和附圖對本發(fā)明作進一步說明，本發(fā)明的實施方式包括但不限于下列實施例。
實施例
如圖1所示，基于Ymodem協(xié)議的TI C2000 DSP串口在線升級方法，實現(xiàn)方式包含了上位機系統(tǒng)和目標系統(tǒng)DSP兩部分。上位機系統(tǒng)需要實現(xiàn)升級程序鏡像.bin生成及數(shù)據(jù)分包發(fā)送與目標系統(tǒng)DSP的握手發(fā)送，并控制數(shù)據(jù)幀的可靠傳送。目標系統(tǒng)DSP需要實現(xiàn)升級指令的接收，升級程序跳轉，升級鏡像數(shù)據(jù)的接收，完整性校驗和Flash燒入。
具體包括如下步驟：
S1、上位機根據(jù)Ymodem通信協(xié)議通過對應的串行通信接口SCI，將應用程序的鏡像文件以數(shù)據(jù)幀的形式加載/緩存到目標系統(tǒng)DSP；這個過程中不需要芯片外部引腳提前配置，同時不局限于上電加載在線，也不使用TI自帶的Bootloader提供的交互協(xié)議。
S2、目標系統(tǒng)DSP CRC校驗接收數(shù)據(jù)幀，并完成鏡像文件數(shù)據(jù)拼幀操作，得到完整的應用程序鏡像文件，然后調用C2000系列具體芯片對應的TI FlashAPI完成應用程序鏡像文件的燒錄固化。
上位機系統(tǒng)
上位機與目標系統(tǒng)DSP的通信協(xié)議使用的Ymodem協(xié)議。Ymodem協(xié)議是一種發(fā)送并等待的協(xié)議。即發(fā)送方發(fā)送一個數(shù)據(jù)包以后，都要等待接收方的確認，包括每一個數(shù)據(jù)包的CRC校驗，如果是ACK信號，則可以發(fā)送新的包；如果是NAK信號，則重發(fā)或者錯誤退出。利用Ymodem協(xié)議可以實現(xiàn)上位機PC與目標系統(tǒng)DSP的可靠雙向數(shù)據(jù)傳輸。
目標系統(tǒng)DSP在線升級程序鏡像是二進制可執(zhí)行文件，而默認情況下TI CCS軟件生成的.out的數(shù)據(jù)格式，該格式主要用于JTAG仿真器下載，不適用于本發(fā)明，所以需要將.out文件轉換為.bin格式的二進制可執(zhí)行文件。Out轉Bin可以首先通過TI的hex2000.exe轉換為hex格式，然后用hex2bin轉換文bin格式。
具體實現(xiàn)步驟如下：
a1、上位機首先向目標系統(tǒng)DSP發(fā)送在線升級指令，等待目標系統(tǒng)確認，該過程中不需要對目標系統(tǒng)DSP進行任何額外的引腳配置；
a2、目標系統(tǒng)DSP接收并確認命令后從應用程序跳轉至自定義Bootloader中使用Ymodem協(xié)議等待接收應用程序鏡像文件；
a3、上位機讀取需要升級的應用程序鏡像.out文件，轉換為目標系統(tǒng)DSP需要的bin文件；
a4、上位機使用Ymodem協(xié)議將應用程序鏡像.bin文件向目標系統(tǒng)DSP分幀發(fā)送，每一幀伴隨CRC校驗值，上位機首先傳送應用程序鏡像文件的文件名并等待目標系統(tǒng)回顯；
a5、上位機接收目標系統(tǒng)DSP確認之后，開始將應用程序鏡像文件數(shù)據(jù)分幀發(fā)送，并等待目標系統(tǒng)DSP每一個分幀的ACK確認；
a6、上位機連續(xù)分幀發(fā)送應用程序鏡像文件，并顯示發(fā)送進度與速度；
a7、上位機發(fā)送完完整的應用程序鏡像文件，發(fā)送結束指令EOT，目標系統(tǒng)DSP確認后回應ACK。
進一步地，所述步驟a4中，應用程序鏡像.bin文件每一幀發(fā)送128字節(jié)或者1024字節(jié)。
更進一步地，所述步驟a5中，上位機如果接收NAK，啟動重傳直到超出重傳次數(shù)上限，并報告失敗。
目標系統(tǒng)
目標系統(tǒng)DSP程序鏡像分為兩塊，一塊是預先配置的自定義Bootloader，其支持Ymodem協(xié)議和串口SCI升級指令。另一塊是用戶應用程序，在正常情況下，系統(tǒng)上電之后直接跳轉到用戶程序執(zhí)行。在用戶需要在線升級的時候，上位機下發(fā)升級指令，目標系統(tǒng)DSP確認之后將會跳轉到預先配置的自定義Bootloader執(zhí)行，并基于Ymodem協(xié)議等待接收在線升級鏡像。目標系統(tǒng)DSP可以使用兩種方式來緩存數(shù)據(jù)。
方式一是每次緩存一幀，由于Ymodem協(xié)議支持分幀CRC校驗，所以數(shù)據(jù)通過CRC校驗之后，可以直接燒入到DSP Flash，該方式由于只需要緩存一幀，對目標系統(tǒng)DSP的存儲空間的要求較低，數(shù)據(jù)幀大小小于等于1024字節(jié)，一般是不需要外擴存儲器的硬件支持。
方式二是目標系統(tǒng)DSP不斷接收數(shù)據(jù)，緩存下所有的數(shù)據(jù)幀，待鏡像文件所有數(shù)據(jù)接收完畢之后，再一次進行鏡像的校驗，確認無錯誤之后，再燒入到DSP Flash中。
方式二比方式一雖然可靠性更高，但是需要目標系統(tǒng)硬件配置至少比燒入的二進制鏡像存儲容量大的隨機讀取存儲器，硬件要求高，例如外擴SDRAM或者SRAM。用戶可以根據(jù)硬件實現(xiàn)選擇方式一或者方式二。本實施例重點描述方式一。
具體實現(xiàn)步驟為：
b1、目標系統(tǒng)DSP上電之后執(zhí)行正常的應用程序服務；
b2、目標系統(tǒng)DSP接收到上位機的升級請求，回復確認，CPU跳轉到預定義的Bootloader執(zhí)行，并使用Ymodem協(xié)議監(jiān)聽上位機的數(shù)據(jù)傳送；否則視為非法指令，直接忽略；
b3、目標系統(tǒng)DSP接收到上位機將要發(fā)送的應用程序鏡像文件的文件名，并回顯鏡像文件名給上位機；
b4、目標系統(tǒng)DSP接收到上位機發(fā)送的分幀數(shù)據(jù)，對每一幀數(shù)據(jù)進行CRC校驗，通過校驗則回復ACK數(shù)據(jù)包，通知上位機繼續(xù)傳送下一分幀，否則回復NAK，并丟棄當前分幀，并等待上位機重傳；
b5、目標系統(tǒng)DSP根據(jù)硬件設計選擇是否緩存所有分幀直到鏡像文件接收完畢，如果目標系統(tǒng)只能緩存一幀，則選擇步驟b6，否則選擇步驟b7；
b6、目標系統(tǒng)DSP首先調用Flash API將原鏡像區(qū)域擦除，并在接收到通過校驗的每一分幀數(shù)據(jù)后，立即燒錄到DSP Flash，直到所有的分幀數(shù)據(jù)傳送完畢和燒錄完畢；
b7、目標系統(tǒng)DSP將校驗完整的鏡像文件，確認無誤之后，調用Flash API燒錄到DSP Flash；
b8、目標系統(tǒng)DSP接收到上位機發(fā)送的傳送結束指令EOT，目標系統(tǒng)DSP回應ACK完成鏡像文件的完整接收，握手結束。
進一步地，在執(zhí)行完步驟b8后，跳轉到已經升級的應用程序，開始執(zhí)行新升級的應用程序。
所述步驟b7中，目標系統(tǒng)DSP將完整的鏡像文件緩存于目標系統(tǒng)DSP外擴的存儲空間SDRAM/SRAM。
按照上述實施例，便可很好地實現(xiàn)本發(fā)明。值得說明的是，基于上述結構設計的前提下，為解決同樣的技術問題，即使在本發(fā)明上做出的一些無實質性的改動或潤色，所采用的技術方案的實質仍然與本發(fā)明一樣，故其也應當在本發(fā)明的保護范圍內。