袁 鋒,丁元章,張 偉,蔡定江
(1.長三角新能源汽車研究院有限公司,江蘇 鹽城 224000;2.長三角電驅動科技鹽城有限公司,江蘇 鹽城 224000)
車輛網關(GateWay,GW)為純電動乘用車的重要零部件,在車輛數據協議實現與數據傳輸上起著關鍵作用。如果控制數據協議升級,車輛網關則需要相應的程序更新,傳統工具下載升級效率差,所以Bootloader的開發就顯得尤為重要[1-2]。Bootloader是固化在微處理器內部Flash特定位置的一段程序代碼。每次處理器啟動都會運行Bootloader,它會檢查是否有來自CAN總線的程序下載請求,如果有則進入Bootloader下載模式,進行程序下載,并校驗其完整性,最終完成應用程序的更新;如果沒有來自總線的程序下載請求,則跳轉至原有應用程序執行[3-5]。
本文采用NXP S32DS IDE集成開發環境S32 Design Studio for S32 Platform 3.4完成基于Cortex-M4F內核S32K148處理器CAN Bootloader軟件開發,程序調試器采用SUGGER JLlink V6.9。上位機開發采用Visual Studio 2010實現,通信CAN控制器采用USBCAN-E-mini實現。
Bootloader是車輛網關啟動時完成加載引導程序執行的代碼。Bootloader一般有兩種工作模式:①啟動加載模式,該模式下Bootloader作用是將之前存儲在存儲器中的應用程序加載到RAM中去執行;②下載模式,本文研究的重點,主要功能是下載應用程序,將程序先存在RAM中,再刷寫至Flash等固態存儲器中完成程序的下載。本文Bootloader系統采用的是基于上位機(PC作為上位機)、CAN控制器(USBCAN-E)和基于S32K148處理器的車輛網關(下位機)的結構,上位機發送的數據經CAN控制器傳送至車輛網關模塊。同樣,當網關模塊接收到應答后,會通過CAN控制器將數據發送至上位機,其結構如圖1所示。
程序進入Bootloader模式一般有以下兩種方式。
1)通過判斷處理器某個引腳電平的高低,識別電平高低狀態,軟件判斷執行應用程序或進入Bootloader下載模式。
2)通過設置標志位判斷,需要PC上位機與CAN控制器總線數據配合,識別特定的CAN數據格式、標識符和字節數據,軟件判斷執行應用程序或進入Bootloader下載模式。
本文采用方式2實現,該方式雖然在軟件處理上稍顯復雜,需要PC上位機與下位機之間的數據和時序的配合。但是相較于方式1,不需要引出單獨的引腳,可以減少使用一個I/O口,在整車應用上具有一定的便利性,且節省了I/O資源。

圖1 Bootloader結構圖
S32K148微處理器包含各種存儲器和內存映射外設,它們位于一個32位連續地址空間中,地址空間統一編址。該芯片具有3×512KB P-Flash空間,分配地址段為0x00000000~0x0017FFFF。Bootloader在此空間實現,分配地址0x00000000~0x00007FFF為Bootloader代碼存儲空間,大小為32KB,其余的P-Flash空間為應用程序使用。
S32K148處理器具有3個獨立的CAN模塊,可用來實現Bootloader的數據傳輸和狀態控制功能。其具有3路FlexCAN模塊,均可配置為CAN或CAN-FD工作模式。因目前車輛CAN總線大多還處于CAN工作模式,本文基于CAN模式采用CAN0 來實現。主要配置如下。
1)配置時鐘寄存器為外部16MHz晶振時鐘,并開啟時鐘門。
2)配置為CAN模式。
3)設置數據幀格式為標準幀,波特率為500kb/s。
4)配置采用中斷方式。
Flash模塊的配置是Bootloader實現的重要一環,需要對相關寄存器進行配置。對Flash模塊編程主要涉及Flash初始化、Flash擦除與編程寫入操作,本文選用的S32K148微控制器Flash存儲空間為0x00000000~0x00007FFF,主要配置如下。
1)配置Flash時鐘源為內部SPLLDIV2時鐘,頻率為20MHz,并開啟時鐘門。
2)P-Flash的擦除方式為扇區擦除,芯片采用的是交叉訪問方式實現,最小擦除扇區為4KB,需在Flash驅動中進行相應設置,執行擦除指令時,需配置FCCOB0為0x09,擦除完成之后,方可對Flash執行寫命令。
3)P-Flash在FTFC->FCCOB寄存器中配置相應命令,實現Flash的編程寫入。FCCOB0為命令寄存器,可用來配置編程、擦除等命令。通過配置FCCOB0=0x07實現編程功能。一次編程的字節數為8個字節。編程地址和數據存儲在FCCOB1~FCCOB11寄存器中。
在前文中提到Bootloader是固化在整車網關等ECU微控制器的內部Flash中某特定位置的一段程序代碼,應用程序同樣也是存儲在內部Flash中,兩者共同占據Flash存儲空間。所以二者的存儲地址要正確分配,避免重疊。
在本文中,Bootloader存放在0x00000000~0x00007FFF地址空間中。在LinkFiles文件中修改如下。

S19文件是NXP微控制器的程序刷寫文件,一般由開發環境自動輸出,具有特定的格式[6-7]。在不同的芯片和編譯環境中,其生成的文件不同。如MC9S12系列的編譯器Code-Warrior 5.2中,其生成文件的后綴為.s19,在MPC56系列編譯器CodeWarrior 2.10中,其生成的文件后綴為.mot,本文使用的S32 Design Studio生成的S-format 格式的文件后綴為.srec。雖然后綴名不同,其均具有相同的數據格式,簡述如下。
取生成的S19文件的中幾行記錄加以說明。

1)“S0”它是S文件的第一行數據,主要表示S文件的路徑以及文件名信息。
2)“S1”表示該行是一條S1類型的數據,數據13表示該行記錄有0x13個字節(包括2字節地址、16字節的數據、1字節校驗)。
3)“8000”表示該行記錄的地址信息。
4)“00F00120118400007984000079840000”表示該行S1類型數據的數據信息。
5)“CC”是該行數據的最后一個字節,表示該行記錄的校驗值。
本文采用S32 Design Studio進行開發,下文就在該環境下生成S19文件進行說明和討論。S32 Design Studio可以經過簡單的配置選擇,即可以生成S-format輸出文件。前文表述,S-format中的程序信息是由S1、S2或S3等行記錄組成。S1文件代表行記錄中2字節的地址域,S2文件代表行記錄中3字節的地址域,S3文件代表行記錄中4字節的地址域。通過實踐發現,在默認情況下,S32 Design Studio根據程序地址空間以及代碼規模自動選擇生成S1、S2或S3格式行記錄。這樣對我們在Bootloader開發中,進行上位機開發中帶來了不便。
為解決上述問題,在開發中,根據芯片的地址寬度為32位的特點,實現在將S19代碼生成或轉換為S3格式。實現方式有以下兩種。
1)在S32 Design Studio中設置,強制生成S3格式行記錄。
2)在S32 Design Studio中保持默認,通過上位機實現S1、S2向S3格式的轉換。
本文采用方式2,在上位機中軟件編程實現格式的轉換,便于工具的一致性和通用性。
示例如圖2與圖3所示。

圖2 生成S19文件

圖3 S3格式上位機轉換
系統啟動后,初始化系統時鐘、Flash模塊、CAN模塊和控制變量。初始化完成后,進入主程序運行,定時接收Bootloader連接數據幀。當接收到特定的數據幀并連接成功后,進入Bootloader下載模式,執行應用程序刷寫循環。刷寫完成后,跳轉到應用程序起始地址執行。本文中的應用程序初始地址位0x00008000。
整個Bootloader流程如圖4所示。

圖4 Bootloader流程圖
下面給出本文上位機與基于S32K148處理器的下位機具體的通信過程,通過CAN通信口將S19記錄文件寫入網關ECU中。
1)上位機端開啟,加載并轉換記錄文件,點擊啟動連接,持續發送報文ID=0x64,data0=0xFF至下位機。下位機上電初始化,初始化完成后。進入計時循環,并中斷接收上位機報文,與上位機建立通信連接。若連接成功,回復ID=0xC8,data0=0x01至上位機,否則跳轉到應用程序起始地址執行。
2)連接成功,下位機執行擦除指令,擦除Bootloader所在地址之外的地址空間。
3)擦除完成,下位機發送當前狀態ID=0xC8,data0=0xC1至上位機,上位機開始逐行讀取S19文件行記錄,并發送至下位機,一行發送完成,上位機發送ID=0x64,data=0xFE。
4)下位機接收到一行完成標識,對接收到的數據進行校驗。
5)數據校驗成功后,執行Flash寫入操作,將S19文件行記錄中的數據寫入地址。行寫入完成,ID=0xC8,data=0xC3至上位機,表示一行數據接收并寫入完成。
6)循環執行行記錄接收、校驗和行編程。
7)上位機發送ID=0x64,data=0xFD,表示整個S19文件發送完成。
刷寫過程如圖5所示。

圖5 刷寫過程示例圖
本文介紹了基于S32K系列微控制器S32K148,采用CAN總線技術,通過NXP S32DS IDE工具進行Bootloader相關的開發與實現。系統通過識別特定的CAN數據格式、標識符和數據字符選擇進入下載模式或者執行應用程序[8]。Bootloader與上位機通過固定ID的CAN幀進行交互反饋,可以成功地完成S19文件的下載并將其刷至目標Flash模塊中,便于系統升級。此外,本文了基于S32K148芯片的開發過程對于其它基于S32K系列Bootloader的開發也有一定的借鑒作用。當然本文也存在著需要進一步改進的地方,如采用UDS 14229協議傳輸S19文件和采用基于CAN-FD的Bootloader開發,這是后續開發的方向。