基于COFF文件分析提取器的DSP下載文件生成

　　在基于DSP的嵌入式系統中，軟件更新通常需要借助仿真器將最新的可執行程序下載到目標板上，然后提取出可執行二進(jìn)制程序并寫(xiě)入非易失存儲器中?；蛘唠x線(xiàn)進(jìn)行二進(jìn)制文件的提取，然后再由DSP自己或主機芯片完成文件的燒結。

在此，有必要簡(jiǎn)單介紹一下TI DSP可執行程序(目標文件)的結構。TI代碼產(chǎn)生工具CCS在經(jīng)過(guò)編譯、鏈接之后，產(chǎn)生的目標文件是一種模塊化的文件格式——COFF格式。程序中的代碼和數據在COFF文件中是以段的形式組織。

在此基礎上，再來(lái)討論上面兩種方法的弊端。前者只要程序有變化，就會(huì )造成新生成目標文件各段的大小和運行地址的變化，其系統引導程序也需要作相應的改動(dòng)。如果需要對大量的DSP系統進(jìn)行軟件更新或經(jīng)常需要軟件更新的情況下，這種方法的效率非常低下，缺乏靈活性。后者的通常做法是先用工具軟件hex6x先將編譯器生成的目標文件轉換成多個(gè)TI格式的.hex文件，再逐一分析.hex文件，手工去掉其中的一些標志信息，并根據需要對文件進(jìn)行必要的分割合并，最后調用TI提供的工具軟件hexbin將各個(gè).hex文件轉換成二進(jìn)制文件，生成文件的數目隨應用而變化。這種方法因為涉及到手工操作費時(shí)費力不說(shuō)且很容易出錯。同樣也存在著(zhù)靈活性差的弊端，遇到有大量增減以及配置文件有修改的時(shí)候就會(huì )導致生成文件數目的增減，需要修改DSP或主機boot程序以適應這種改變。通過(guò)對目標文件結構的分析，可以直接提取可供下載的二進(jìn)制文件。

　　1 目標文件結構分析

　　DSP的源程序——C代碼或匯編代碼在編譯后生成的COFF文件包含多個(gè)段，默認的情況下，COFF文件包含3個(gè)段：.text：通常包含可執行代碼;.data：通常包含已初始化的數據;.bss：通常為未初始化的數據保留空間。

　　當然匯編器和鏈接器允許自己建立和鏈接自定義的塊，這些塊與以上的3個(gè)段類(lèi)似。所有的段分為兩大類(lèi)：已初始化段和未初始化段。這兩類(lèi)段的最大區別就在于是否出現在加載文件中。

　　下面來(lái)分析COFF文件的結構，COFF文件從上到下中依次是文件頭、可選的文件頭、段頭信息表、段頭信息表對應的段數據、重定位信息、行號入口表、符號表、字符串表，如圖1所示。其中第3～6項包含多個(gè)數據區，前4項與加載文件密切相關(guān)。

　　由于前4項與加載文件相關(guān)，下面對這4項逐一分析一下：

　　(1)文件頭：顧名思義，就是COFF文件的頭，用來(lái)保存COFF文件的基本信息，如段數目、時(shí)間戳、符號表位置等。從文件的0偏移處開(kāi)始，用C的結構描述如下：

　　文件頭中的標記包含了諸如大小端模式、COFF是否為可執行文件等信息，具體解釋見(jiàn)參考文獻。

　　(2)可選頭：可選頭接在文件頭的后面，也就是從COFF文件的Ox0014偏移處開(kāi)始。長(cháng)度可以為O。不同平臺的可選頭，長(cháng)度和結構都不相同，TI DSP采用的可選頭長(cháng)度為28 B，用C的結構描述如下：

　　(3)段頭：段頭緊跟在可選文件頭的后面(如果可選文件頭的長(cháng)度為0，它緊跟在文件頭后)，一般COFF包含多個(gè)段頭，數目就是文件頭中的usSection—Counter。它的長(cháng)度為48 B，用C的結構描述如下：

　　段頭可以說(shuō)是最重要的頭，文件分析提取器的核心就是用它來(lái)描述它的。一個(gè)COFF文件可以不要其它的節，但文件頭和段頭這兩節是必不可少的。有必要詳述一下它的成員：

　　cName用來(lái)保存段名，常用的段名有.text，.da—ta，.bss等。對于用戶(hù)自定義長(cháng)度超過(guò)8 B的段名，則為指向符號表的指針。

　　uiVirtAddr是段數據載入或連接時(shí)的虛擬地址。對于可執行文件，這個(gè)地址是相對于它的地址空間而言。當可執行文件被載入內存時(shí)，這個(gè)地址就是段中數據的第一個(gè)字節的位置。大多數情況下與uiPhyAddr相同。

　　uiSecSize是段中數據的實(shí)際長(cháng)度，在讀取段數據時(shí)就由它來(lái)確定要讀多少字節。

　　uiSecPointer是段數據在COFF文件中的偏移量，以絕對地址標識。

　　uiRelPointer是該段重定位信息的絕對地址，它指向了重定位表的1個(gè)記錄。

　　uiLNOffset是該段行號表的絕對地址，它指向的是行號表中的1個(gè)記錄。

　　uiRelSize是重定位信息的記錄數，從uiRelPointer指向的記錄開(kāi)始，到第ulNumRel個(gè)記錄為止，都是該段的重定位信息。

　　uiLNSize和uiRelSize相似，不過(guò)它是行號信息的記錄數。

　　uiFlags是該段的屬性標識，與下載相關(guān)的標識如表1所示。

　　其余定義請見(jiàn)參考文獻。

　　(4)段數據：保存各個(gè)段的數據，在目標文件中這些數據都以原始數據(Raw Data)形式存在，只有需要下載的數據段才存在該區域。

　　2 COFF文件分析提取器的工作流程

　　首先讀入目標文件，該文件擴展名為out，以二進(jìn)制形式讀入。分析.out文件的文件頭以確定有多少個(gè)段，然后逐段分析段信息頭，根據段屬性標識以確定是否需要下載，段頭中的絕對地址、段數據長(cháng)度等信息作為升級文件的一部分。與需下載的段數據合并成最終的下載文件，為了適應自動(dòng)化升級的需要，下載文件頭部還保留了COFF文件的時(shí)戳。值得注意的是因為T(mén)MS320C6000 DSP為32位處理器，需要對段落頭中段數據長(cháng)度信息進(jìn)行32位整型對齊，在此采用Ceil對齊——不足的字節以O補齊。具體流程如圖2所示。

　　而COFF文件中的重定位信息、行號入口表、符號表、字符串表等數據區，對于下載文件的制作沒(méi)有直接聯(lián)系，可以不做分析。當然，如果在PC上制作可視化工具的話(huà)，另當別論，限于篇幅在此不做討論。

　　3 COFF文件分析提取器的應用

　　開(kāi)發(fā)的DSP應用系統一般采用HOST—SLAVE模式，即DSP是作為系統的信號處理協(xié)處理單元，HOST保存有所有處理器的下載文件。COFF文件分析提取器在做離線(xiàn)使用時(shí)，提取出的下載文件由H0ST負責保存、上電加載。HOST的引導程序在上電時(shí)讀取已經(jīng)構建好的二進(jìn)制文件，根據段數目、每段大小以及目標數據的下載地址等相關(guān)信息即可完成對目標代碼的自動(dòng)下載。COFF文件分析提取器在線(xiàn)使用時(shí)，時(shí)間戳就作為版本是否更新的依據，HOST一旦偵測到版本服務(wù)器有新版本的COFF文件并得到用戶(hù)升級確認后，就可啟動(dòng)文件提取器。

　　目前，這種利用COFF文件分析提取器生成DSP下載文件的方式，已經(jīng)在中興通訊多個(gè)產(chǎn)品線(xiàn)廣泛應用，大大提高了產(chǎn)品的可測試性和易維護性。

　　4 結 語(yǔ)

　　在此討論的方法基于對COFF文件結構的分析，讀取DSP編譯器生成的.out文件，根據文件本身攜帶的信息，直接提取生成可供下載的二進(jìn)制文件。最終生成的二進(jìn)制文件中包含有與.out文件相同的信息，在下載時(shí)利用這些信息即可完成對DSP芯片的加載。