關於DSP的boot mode / boot loader /上電順序 /在線升級等問題的總結

使用器件 ti dsp c2000 2837x

一、dsp的上電過程和boot mode以及boot loader

 

1）dsp的上電順序，

對於雙核系統而言 ， 他的上電啓動順序以下所示：

 

系統復位或者從新上電以後：

 

cpu2系統從新上電以後，一直處於復位狀態

 

cpu1系統會自動跳轉到地址0x3fffc0中獲取復位向量，福爲向量的目的就是爲了使得系統自動跳轉到0X3F8000地址上，開始執行boot ROM 段中存儲的boot loader代碼段；

 

對於cpu1而言，cpu1的boot ROM段中的boot loader程序首先會從TI - OTP內存段中獲取設備的配置自，並配置好器件。

 

完成以後，boot loader 開始執行DCSM 和OTP JTAGLOCK流程：DCSM流程：1）讀取OTP中的Zx_poinyer；2）解碼指針值；3）度去除TI-OTP中的SECDC;4）讀取Zx BOOT模式；5）讀取ZX DCSM模塊

 

完成以後，boot loader檢測FUSEERR寄存器中是否存在錯誤標誌位，並採起錯誤處理機制

 

以後初始化RAM和內存端的ECC/PARITY

 

完成以後cpu1將引導CPU2系統跳出復位操做，以後便無論cpu2的運行狀態

 

以後CPU1系統的boot loader將會根據外部的GPIO 和XRST（通常連接下載器纔會有） 來肯定程序的啓動方式是從flash啓動仍是ram啓動，或者是在XRST爲低的狀況下，更具PIE向量表（地址爲0xd00）的第一個32位的值來肯定啓動方式（通常是連接了下載器的狀況）；

 

肯定完以後，CPU1的boot loader代碼段會將各類信息都更新到指定的RAM段中，以便於CPU1的程序去讀取這些狀態字。

 

此時按照啓動方式開始跳轉程序，若是是flash啓動則將程序指針跳轉到0x80000（flash的其實地址），若是是ram啓動則將程序指針跳轉到0x00000（ram段的起始地址），同時結束boot loader並進入CPU1的主程序。

 

若是此時的啓動方式是外設啓動，那麼boot loader則會等待外部程序按照必定的格式將程序加載到ram中，程序代碼傳輸完成以後，跳轉到運行指針開始運行程序代碼段。

 

此時cpu1的boot loader 完成使命，已退出，並開始執行CPU1中的用戶程序。

 

此時的CPU2系統知識退出了復位狀態，任然在等待啓動模式肯定，須要cpu1的用戶程序來引導cpu2的引導，若是是cpu2也要從flash啓動，則經過ipc command便可觸發，可是若是cpu2也須要從外設啓動，那麼須要cpu1的應用首先設置好外設的引腳，以後在觸發cpu2開始接受程序。

 

關於連接下載器的xrst爲低是的系統啓動過程參考手冊

關於外設啓動的代碼輸入格式也能夠參考手冊

 

//--------------------------------------------------------------------------------------------

 

二、實如今線升級的個些方案 ： 

次方案是用 ： 升級代碼 + 用戶應用程序的方式來實現

 

升級代碼的用途是下載到DSP中上電就開始運行的代碼段，主要功能是上電以後首先監測是否有升級指令發出，若是有則進入升級流程，若是沒有則經過(LB )的跳轉指令跳轉到指定的程序運行其實處。

 

假設 ： 將用戶應用程序的其實地址定義爲0XC0000;當監測到須要升級的指令，則升級代碼經過外設將上位機輸送過來的代碼經過DSP的flash API寫入到以0XC0000爲起始地址的FLASH sector中，當全部的數據所有書寫完成以後，經過跳轉指令，將程序指針跳轉到0XC0000上，便開始執行用戶程序。

 

數據格式 ： 上位機輸送給升級代碼的格式就是bin文件當中的內容，dsp將.out文件轉化爲bin文件，而後dsp接受到這個文件直接寫入到flash中就能夠，緣由是 ：將同一個程序的.out文件下載到dsp中，而後經過uniflsh去查看內部代碼段的內容和bin文件的內容是同樣的。

 

至於爲何bin文件和.out文件的格式和datasheet上的數據流內容不同，我還沒找到緣由