網關控制器BootLoader系統設計

孫 瑞， 徐建國， 馬 偉， 楊玉柱

(上海采埃孚轉向系統有限公司, 上海 201821)

在某款車用網關控制器的開發過程中，為了方便實現網關控制器的實車調試和程序更新，需要設計出一種通過CAN總線即可刷寫應用程序的軟件.CAN(Controller Area Network)總線是一種主流的車用現場總線，具備標準化的通信格式，其信號傳輸的實時性、可靠性和準確性等優點使其獲得汽車行業內的廣泛認可.因此，CAN總線成為本文設計BootLoader系統的首選通信介質.在CAN總線協議與S19文件協議的基礎上，本文又引入了一個自定義的通信協議，以實現BootLoader與上位機之間的命令和狀態傳遞.該BootLoader系統簡單、可靠，無需應用程序本身做任何適應性更改，因此同樣適用于以XET256為平臺的其他控制器開發項目.

1 BootLoader設計思路

Bootloader稱為系統的引導加載程序，是系統加電或復位后執行的第一段代碼[1]，其主要作用是實現應用程序的更新以及引導應用程序的執行.基于這一基本思路，在設計BootLoader時首先要考慮的問題是BootLoader與應用程序在Flash中應如何劃分，以保證二者所占用的存儲空間不能相互沖突.其次，控制器上電后，應該首先執行BootLoader，由BootLoader決定是進行程序的更新還是進入應用程序執行.然后，在控制器上電后，BootLoader開始執行時，應以操作員即上位機的指令為判斷依據，來控制程序執行的方向.在應用程序刷寫過程中，還應對上位機的命令及命令執行情況進行反饋，以使操作員明確應用程序是否成功更新.最后，BootLoader應能夠根據規定好的協議，將通過CAN總線接收到的應用程序數據準確地寫入.

2 Flash與RAM劃分

2.1 PRM中P-Flash與RAM劃分

設計BootLoader時需充分考慮對ECU存儲器的分配[2]，在飛思卡爾編譯器CodeWarrior中，程序和數據存儲空間的劃分工作是在prm文件中完成的.以關鍵字SEGMENTS和END為標志.Flash存儲空間的關鍵字為READ_ONLY.

XET256中P-Flash地址范圍為0x4000～0xFFFF[3].其中，0xFF0F～0xFFFF為中斷向量區，0xFF00～0xFF0E為Flash配置區，主要用于P-Flash寫保護等功能.剩下的地址范圍0x4000～0xFEFF開放給用戶，用于存儲用戶程序代碼.受限于16位尋址能力，P-Flash被分為非分頁區(unpagedFlash)和分頁區(paged Flash).非分頁區(0x4000～0x7FFF與0xC000～0xFFFF)可直接用16位地址尋址.而分頁區(0x8000～0xBFFF)則必須用24位地址尋址.

為了給網關控制器應用程序提供更多的代碼空間，以及便于實現BootLoader寫保護等目的，將BootLoader程序安排在從0xFEFF開始往上數的一段區域，其大小可根據具體代碼量調整，本文將其定義為3.75K，即地址范圍為0xF000～0xFEFF.

在對P-Flash擦除與寫入操作的時候，不允許同時對其進行讀取，否則可能導致Flash的損壞[4].本著這一原則，對Flash的擦除、寫入以及CAN中斷信號的處理代碼，應復制到RAM中運行.這一功能可通過關鍵字RELOCATE_TO實現.因此，在劃分Flash的同時也應對RAM進行劃分，以實現這一功能.定義RAM的關鍵字為READ_WRITE.P-Flash與RAM的實際劃分如圖1和圖2所示.

圖1 P-Flash劃分圖

圖2 RAM劃分圖

2.2 全局地址表示方式

如前所述，非分頁區Flash的地址唯一，可直接采用16位邏輯地址進行尋址.但0x8000～0xBFFF這一分頁區共由14頁組成，具體尋址到哪一頁取決于PPAGE寄存器.其地址變為了8位頁地址加16位具體地址，即24位地址.如PPAGE寄存器的默認值為0xFE，則邏輯地址0xFE_8000表示0xFE這一頁的0x8000地址.

由于存在以上地址表示方式的不同(16位與24位)，在對Flash進行擦寫時，如果直接采用邏輯地址，不僅關系復雜，而且容易出錯.而采用全局地址，可使表示方式單一，容易尋址.所謂全局地址是由頁寄存器PPAGE的值以及邏輯地址按一定關系組成的24位地址.這種表示方式使得Flash存儲單元的地址線性且唯一，便于操作.邏輯地址轉換為全局地址的關系式為

GA=0x400000|((((dword)(PA))<<14)|

(LA&0x3FFF))

(1)

式中，LA表示邏輯地址，PA表示PPAGE寄存器值，GA表示全局地址.當邏輯地址位于0x4000～0x7FFF時，PA的值為0xFD；當邏輯地址位于0xC000～0xFFFF時，PA的值為0xFF；當邏輯地址位于分頁區時，PA的值取決于具體頁，默認值為0xFE.

采用全局地址后，Flash在全局地址表示方式下的劃分如圖3所示.由于劃分Flash時只需關注分界線，因此，在prm文件中，依然采用邏輯地址進行劃分.從圖3可以看出，XET256的256K Flash是由不連續的兩個Block(0/1)組成的，每一個Block為128K.

圖3 全局地址表示下的Flash劃分

3 中斷地址分配

飛思卡爾16位單片機在復位后總是從優先級最高的中斷向量地址0xFFFE處取第一條執行指令[4].因此，BootLoader可執行代碼的首地址應安排在此處，以保證上電后BootLoader的首先執行.這可以通過在prm文件中定義VECTOR 0來實現，即將VECTOR 0定義為BootLoader程序的入口地址.然而，網關應用程序在編寫時也會對VECTOR 0進行定義，以實現在單片機上電后直接執行應用程序的目的.由于存在這一中斷資源沖突，因此，BootLoader在刷寫時需要對網關應用程序的中斷向量表進行重新分配.

默認情況下，XET256的中斷向量表位于0xFF0F～0xFFFF區間[3].這一特性是由中斷向量基址寄存器IVBR在上電后總是默認為0xFF所確定的.一條可執行的中斷向量地址是由基址(IVBR寄存器的值)加偏移組成的.如復位中斷向量地址0xFFFE，即表示IVBR的值為0xFF，該中斷向量的偏移為0xFE.在一款特定的單片機中，任一硬件中斷向量相對于基址的偏移總是確定的.因此，通過改變IVBR寄存器的值，即可實現中斷向量表的更改.本文設計的BootLoader在引導進入應用程序之前將應用程序中斷向量表基址IVBR更改為0xEF，即經過BootLoader重新分配后，應用程序中斷向量表位于0xEF0F～0xEFFF.在刷寫應用程序時，若BootLoader檢測到地址為0xFF0F～0xFFFF的代碼數據，則將其地址更改為0xEF0F～0xEFFF，然后在新的地址上將數據寫入.由于存在這一安排，應用程序非中斷向量代碼的存儲不得位于0xEF0F以下，這也是本文設計的BootLoader對應用程序的唯一要求.

在對P-Flash進行擦除與寫入的過程中，所使用的硬件資源CAN通道依然在進行正常工作，當其接收到有效數據后，即可使單片機自行進入中斷處理服務.單片機將從所選CAN通道的中斷服務地址處讀取CAN中斷服務代碼的首地址.如前所述，P-Flash在擦除過程中不允許對其進行讀取，因此，這種由CAN通道中斷所導致的操作應加以避免.本設計采取的解決方案是BootLoader進入刷寫程序后，在擦除與寫入P-Flash之前將中斷向量表更改至RAM中.本文將IVBR更改為0x3F，即在BootLoader執行刷寫程序時，實際中斷向量表為0x3F00～0x3FF0.

4 應用程序更新

4.1 通信協議

為實現BootLoader與上位機之間的命令和狀態傳輸，本文在標準的CAN協議基礎上，定義了一套簡單的通信協議.該協議中所使用的命令和狀態均以報文ID表示，即每一個ID代表一個特定的命令或狀態.根據本文所涉及項目的相關要求，刷寫過程中使用的報文ID不能與整車網絡中其他節點用到的ID相同，因此本協議報文ID的選擇范圍為0x500～0x5FF.具體選擇報文ID及協議見表1.

表1通信協議表

4.2 應用程序更新流程

在系統上電后，BootLoader將初始化堆棧、配置系統時鐘，并初始化所選CAN通道.當CAN通道正常工作后，BootLoader將等待20ms，如果在這段時間內接收到上位機進入刷寫程序的指令或檢測到應用程序不存在，則執行應用程序更新操作；否則，跳轉至應用程序執行.如直接跳轉至應用程序執行，則應首先配置中斷寄存器基址，然后，將單片機指針更改為應用程序復位向量地址，本文設計為0xEFFE.采用這一策略無需應用程序配合，但要求操作員如需更新應用程序，則應在系統上電前將上位機啟動，以保證BootLoader能接收到相應指令.BootLoader工作流程如圖4所示.

圖4 BootLoader工作流程圖

若執行應用程序更新操作，首先應配置P-Flash時鐘，使其工作頻率為用戶手冊推薦的0.8～1.05MHz[3]，這可以通過設置FCLKDIV寄存器的值來實現.P-Flash的時鐘源為外部晶振，本文所選的外部晶振頻率為16MHz，查用戶手冊將FCLKDIV寄存器的值設置為0x0F.然后，將P-Flash中定義好的BootLoader擦/寫/中斷處理代碼拷貝至RAM中劃分好的區間0x3D00～0x3EFF處.接著，將中斷向量表配置到RAM中.當所有BootLoader更新應用程序所需的環境都準備好后，就可以對P-Flash進行擦除與寫入操作.應用程序更新操作流程圖如圖5所示.

圖5 應用程序更新流程圖

4.3 應用程序擦除

應用程序擦除代碼存儲在P-Flash中，在執行時拷貝到RAM中執行.XET256支持將P-Flash以Sector(每個Sector的大小為1K)和Block為單位進行擦除.對于Block1(0x78_0000～0x79_FFFF)可按Block為單位整體擦除.而對于Block0應只擦除屬于應用程序的部分，即0x7E_0000～0x7F_EFFF的區間，此處應以Sector為單位進行擦除.擦除過程如圖6所示，首先等待其它Flash命令執行完畢，然后清除Flash狀態寄存器中的故障碼，之后即可通過配置Flash控制寄存器FCCOB的值來選擇擦除命令與擦除區域.

圖6 應用程序擦除操作

Flash控制寄存器FCCOB由6個字組成，通過選擇寄存器FCCOBIX可分別對6個字進行配置[3].其中，FCCOB第1個字的高8位代表具體Flash命令，如0x09表示執行按Block擦除命令；0x0A表示執行按Sector擦除命令；0x06表示寫Flash命令.FCCOB第1個字的低8位代表全局地址的高8位.FCCOB第2個字表示全局地址的低16位.FCCOB的第3到第6個字則用于存放需要寫入的數據，擦除操作時不需要，但執行寫入操作時需要.Flash控制寄存器配置好后，即可通過將Flash狀態寄存器的最高位寫1來執行FCCOB中存儲的命令和數據.之后，利用Flash狀態寄存器來判斷操作是否成功執行完畢.

4.4 應用程序寫入

BootLoader成功將P-Flash擦除后，即向上位機發送成功擦除信號，通知上位機發送新的應用程序數據.上位機傳輸給BootLoader的數據格式采用S19文件協議，而且每一個地址或數據等信息均以字符的形式發送.

4.4.1 S19協議解析

S19文件是飛思卡爾推薦使用的標準程序下載文件，該文件格式由記錄類型、記錄長度、存儲地址、代碼數據和校驗碼5個部分組成[5].S19文件的每一行總是以“S”開始，其后的一位數字表示該行記錄的類型.如S0表示該行記錄為說明性信息，非程序數據；S1表示該行記錄為程序數據且地址為16位地址，S2則表示該行記錄為程序數據且地址為24位地址；S9表示該行為整個S19文件的結束行.由于本文在擦、寫時采用全局地址，所以經式(1)轉化后的S19文件只包括S0、S2和S9.記錄類型之后的一個字節表示其后該行記錄所包含的字節長度.緊接著的3個字節表示目標地址，之后是寫入目標地址的數據.最后一個字節為該行記錄的校驗碼，校驗碼加代表信息長度、目標地址、寫入目標地址數據的所有字節的和為0xFF.

BootLoader通過CAN中斷接收到ID為0x50F的S19數據幀后，會將數據依次存入指定緩存中，然后周期性地對緩存數據進行組織和解析.由于上位機發過來的數據全部為字符的形式，因此，首先應將字符轉化為16進制數，然后整理成以字節為單位的有效數據.如在解析信息長度時，應連續讀取兩個字符，將其分別轉化為16進制數后，第1個數左移4位加第2個數，這樣即可整理為一個有效的字節數據.

在對S19文件進行解析時，首先判斷接收到的第一個字節是否為'S'以及第二個字節是否為'0'、'2'或'9'，如果不符合則舍棄該條信息.若符合則開始對信息長度、地址、數據和校驗碼的解析，然后按照S19協議對校驗碼進行校驗，如果校驗結果為有效則將目標地址、寫入目標地址的數據放到相應的緩存中.至此，一條S19信息被成功解析.

4.4.2 P-Flash數據寫入

當一條有效的S19信息被接收并成功解析后，還應對該信息做進一步判斷.如果接收的是S9或接收過程中有錯誤，則直接退出數據寫入程序；如果是S0，則予以忽略；如果是S2，則按照解析出的目標地址，將程序數據寫入.

在數據寫入之前，應對目標地址進行判斷.若目標地址位于中斷向量區，則首先按第3節所述對其進行更改，然后再執行數據寫入程序；若目標地址不位于中斷向量區，但超出了第2節所規定的應用程序區域，則拒絕執行寫入程序.

Codewarrior編譯器生成的S19文件連續地址之差為32的整數倍，即每一條S19信息涵蓋32個字節的P-Flash數據信息，即使轉化成全局地址后，這一規則依然不變.FCCOB寄存器中有4個字，即8個字節用于存放程序數據.因此，每一條S19信息中的數據可以分4次寫入，每一次的寫入方法如4.3所述.

5 上位機設計

BootLoader系統中的上位機基于Labview開發，其基本工作原理是：首先讀取S19文件，然后按行將S19文件中的十六進制數轉換為相應的字符串數組，并補以行結束符.整合好的字符串數組會以8個字符為一組通過PEAK CAN工具轉成CAN信號發送給網關控制器(最后一次不足8個的字符串發送實際字符長度).

由于本文設計的BootLoader系統無需應用程序做適應性更改，因此，上位機必須在跳轉到應用程序之前啟動.上位機啟動后即向網關控制器發送握手指令，若后者沒有反饋，上位機將連續10s發送該指令.這一策略要求操作員應在啟動上位機后10s內將網關控制器上電或復位.若BootLoader接收到握手指令，并成功進行反饋，上位機將退出握手環節，并進入等待刷寫環節.握手成功后，BootLoader將自行進入環境配置及擦除P-Flash過程，擦除成功后將向上位機發送擦除成功信號.上位機接收到該信號即退出等待，逐條發送S19文件.BootLoader接收并解析S19文件，寫入成功后向上位機發送寫入成功信號.若上位機在發送完最后一條S19信息后一段時間內沒有接收到寫入成功信號，則默認為本次程序更新失敗.程序更新成功后，需操作員手動復位網關控制器，從而執行新的應用程序.整個操作過程及系統狀態均會在上位機中實時顯示.BootLoader系統上位機工作流程如圖7所示.

圖7 BootLoader系統上位機工作流程

6 結束語

本文設計的BootLoader系統幾乎無需應用程序做任何適應性更改，因此可直接在其他以XET256為平臺的產品上運行.試驗證明，該系統操作方便、實現簡單、運行可靠，能夠正確地實現網關應用程序更新，從而大大方便了網關控制器的實車調試，加快了項目進度.

[1] 王伏，張忠能，杭勇.基于CAN總線的電控單元程序引導加載功能開發[J].微型電腦應用,2011，27(2):30-32.

[2] 奚英澤，于健楠，徐鳳.基于飛思卡爾MPC5634M單片機的Bootloader設計[C]//中國汽車工程學會.2013中國汽車工程學會年會論文集.北京:中國學術期刊電子出版社,2013:566-569.

[3] Freescale.MC9S12XEP100RMV1(1.25)[M/OL].(2013-02)[2014-03-28]. http://www.freescale.com/files/microcontrollers/doc/data sheet/MC9S12XEP100RMV1.pdf.

[4] 羅峰，孫澤昌.汽車CAN總線系統原理、設計與應用[M].北京:電子工業出版社,2010.

[5] 張夕杰，李清政，王喬.MPC5534單片機在線程序更新系統研制[J].國外電子測量技術,2013(12):49-52.