CLA(Control Law Accelerator)控制率加速器是一個獨立可編程的32位浮點數(shù)字處理單元，為快速觸發(fā)響應及數(shù)學運算而設計。CLA獨立于C28x CPU工作，時鐘頻率與CPU相同，可執(zhí)行算法以及周期性的計算工作。通過增加平行的處理單元CLA，拓展了C28x CPU的性能。當前C2000系列產(chǎn)品共有3種類型的CLA， 不同的C2000型號對應不同的CLA類型， 各類型的差別及對應的C2000器件型號詳情如圖1所示。Type 2型的CLA可直接讀取ADC 結果寄存器，極大減小ADC采樣至輸出的延時，提高系統(tǒng)的響應并允許系統(tǒng)以更高的頻率運行；并且可直接操作所有的Epwm，HRPWM，eCAP，eQEP，CMPSS，DACSDFM，PGA，SPI，LIN，F(xiàn)SI，PMBUS，CLB和GPIO數(shù)據(jù)寄存器；CLA可獨立地響應外設中斷。利用CLA執(zhí)行一些周期性任務可以解放CPU，使其工作于其他系統(tǒng)任務。

圖1 CLA類型及對應C2000器件

CLA的使用包括初始化設置和任務定義。初始化由CPU完成，包括程序內存和數(shù)據(jù)內存分配，任務的觸發(fā)配置；Type 2型CLA提供 8個獨立的任務（也可配置為7個獨立的任務和1個底層持續(xù)運行的任務），這些任務類似中斷服務函數(shù)，由中斷觸發(fā)并運行至任務結束，并且可配置在任務完成時產(chǎn)生中斷， CLA 框圖如圖2所示。

圖2 CLA框圖

CLA可訪問RAMLS0-LS7 區(qū)塊的內存，并且每個塊可以配置為CPU專用或CPU與CLA之間共享數(shù)據(jù)。這些內存塊復位時默認分配給CPU，需要由CPU初始化后才可用于與CLA共享數(shù)據(jù)。如果這些內存塊被配置為數(shù)據(jù)共享的，則可進一步配置為程序內存或數(shù)據(jù)內存，程序內存用于存放CLA的程序代碼，數(shù)據(jù)內存用于存放供CLA程序使用的變量和系數(shù)，并且有專用的消息內存MSG RAMs用于在CPU和CLA之間傳遞數(shù)據(jù)， CLA的Memory及寄存器操作方式描述如圖3所示。

圖3 CLA Memory及寄存器操作

CLA的初始化是在軟件初始化期間由CPU執(zhí)行，主要包括6個步驟：

從Flash中復制CLA 任務代碼至CLA 程序內存中

分配CLA數(shù)據(jù)內存

配置CLA寄存器：包括使能CLA時鐘；分配CLA任務函數(shù)地址；選擇任務觸發(fā)源；根據(jù)需要使能軟件觸發(fā)任務；映射CLA程序內存和數(shù)據(jù)內存到CLA空間

在PIE中配置CLA任務完成中斷的服務函數(shù)

在MIER寄存器中使能CLA任務觸發(fā)

初始化觸發(fā)源外設，使其能觸發(fā)CLA任務

在CLA開發(fā)過程中，工程師往往專注于代碼層面對CLA初始化，CLA_task的配置以及算法設計，忽略了更為底層的問題——CMD文件中CLA內存分配問題。不合理的內存分配可能會導致編譯報錯及內存溢出。

本博文將舉例使用TI的TMS320F280049進行CLA開發(fā)時，由于內存分配錯誤導致的具體報錯。

本例中在完成了CLA初始化，CLA_task的中斷函數(shù)配置后，點擊編譯CCS報43個“#17003-D” warnings，如圖4：

圖4 #17003-D Warning

Description Resource Path Location Type：

#17003-D relocation to symbol "CLAscratch_end" overflowed; the 6-bit relocated address 0xee is too large to encode in the 16-bit unsigned field (type = 'R_ABS16_OC' (107), file = "../xxxxxxx", offset = 0x00000312, section = "Cla1Prog")

警告顯示CLAscratch_end內存溢出，問題定位至CMD文件，檢查CMD中與scratch相關的內存分配， 如圖5。

圖5 CMD文件scratchpad描述

發(fā)現(xiàn)僅有.scrathpad分配至RAMLS1，并未找到CLAscratch_end以及對CLA_SCRATCHPAD_SIZE的定義。

于是，打開.map文件判斷是否分配了__cla_scratchpad_end/start，在.map文件中搜索scratchpad，如圖6所示。

圖6 .map文件中cla_scratchpad_end描述

如圖6，在.map中僅僅找到__cla_scratchpad_end，可以判斷工程使用了scratchpad，但是并沒有__cla_scratchpad_start的內存分配。

至此找到了問題原因，解決方案就是需要在CMD文件中對scratchpad進行相關配置， 如圖7所示。

參考配置如下：

①在CMD文件的頭部添加以下代碼，如圖所示

CLA_SCRATCHPAD_SIZE=0x100;

--undef_sym=__cla_scratchpad_end

--undef_sym=__cla_scratchpad_start

圖7 scratchpad配置

②在CMD文件的SECTIONS{}代碼部分的末尾添加以下代碼

CLAscratch:

{*.lib(CLAscratch)

.+=CLA_SCRATCHPAD_SIZE;

*.lib(CLAscratch_end)}>RAMLS1,

PAGE=1

再次編譯，#17003-D警告已經(jīng)消失，編譯通過，結果如圖8所示。

圖8 修改CMD后編譯結果

此時，再次查看.map文件，發(fā)現(xiàn)__cla_scratchpad_end/start以及CLA_SCRATCHPAD_SIZE已經(jīng)成功分配，如圖9所示。

圖9 修改CMD文件編譯生成.map文件圖

以上就是關于“#17003-D warning”的解決方案，希望通過這個例子，讓廣大工程師在CLA開發(fā)時能夠注意到CMD對CLA內存正確配置的重要性，防止在實際開發(fā)時遇到問題，難以排查。

審核編輯：郭婷