計(jì)與實(shí)現(xiàn)：Flash分區(qū)與跳轉(zhuǎn)實(shí)戰(zhàn))
剛接手一個(gè)基于TMS320F28377D的電機(jī)控制項(xiàng)目時(shí)客戶(hù)提的第一句話(huà)是“你們這個(gè)設(shè)備以后軟件升級(jí)方便嗎”。當(dāng)時(shí)整機(jī)已經(jīng)用JTAG調(diào)試了大半年所有代碼都在CCS里一次次燒寫(xiě)驗(yàn)證沒(méi)人覺(jué)得這會(huì)是個(gè)問(wèn)題。直到有一臺(tái)樣機(jī)發(fā)到現(xiàn)場(chǎng)、客戶(hù)想要改一組算法參數(shù)我才意識(shí)到一個(gè)沒(méi)有Bootloader的DSP產(chǎn)品在交付之后基本等于“要升級(jí)就必須拆機(jī)開(kāi)蓋接仿真器”。這篇文章把我給F28377D設(shè)計(jì)Bootloader的完整思路、CMD文件分配、跳轉(zhuǎn)代碼和踩過(guò)的坑整理出來(lái)希望能幫正在做C2000系列產(chǎn)品化開(kāi)發(fā)的同行少走彎路。這篇文章適合兩類(lèi)人看一類(lèi)是剛接觸C2000 Bootloader想知道“從哪下手”的工程師另一類(lèi)是已經(jīng)在做升級(jí)功能但被跳轉(zhuǎn)失敗、Flash編程報(bào)錯(cuò)、CMD分區(qū)沖突折磨過(guò)的開(kāi)發(fā)者。我會(huì)盡量把原理和操作放在一起講不會(huì)只貼代碼不給理由。1. 為什么非做Bootloader不可F28377D產(chǎn)品的三個(gè)現(xiàn)實(shí)痛點(diǎn)1.1 不要等產(chǎn)品交付了才想起升級(jí)問(wèn)題很多DSP項(xiàng)目在樣機(jī)階段都靠仿真器燒錄這沒(méi)有錯(cuò)畢竟調(diào)試階段JTAG是最直接的手段。但產(chǎn)品一旦到了現(xiàn)場(chǎng)情況完全不同。工業(yè)設(shè)備往往安裝在電柜里有些甚至在高空或狹窄空間想用XDS100V2連接目標(biāo)板必須先斷電、開(kāi)柜、拆擋板運(yùn)氣不好還要?jiǎng)咏泳€(xiàn)。Bootloader解決的不是“能不能燒”的問(wèn)題而是“怎么不拆機(jī)也能燒”的問(wèn)題。通過(guò)SCI串口或者CAN總線(xiàn)讓DSP自己把應(yīng)用程序固件接收下來(lái)寫(xiě)進(jìn)Flash這才是產(chǎn)品化該有的形態(tài)。我見(jiàn)過(guò)不少團(tuán)隊(duì)把Bootloader放到項(xiàng)目末期才做結(jié)果發(fā)現(xiàn)Flash分區(qū)已經(jīng)被應(yīng)用代碼占滿(mǎn)、中斷向量表動(dòng)不了、RAM段不夠用只能大改鏈接腳本。更合理的順序是在工程建立的第一天就把Bootloader占位規(guī)劃好哪怕先寫(xiě)一個(gè)空殼。1.2 Bootloader不是萬(wàn)能的先定義它的邊界設(shè)計(jì)Bootloader前先要搞清楚它到底負(fù)責(zé)什么。以我的經(jīng)驗(yàn)F28377D的Bootloader至少應(yīng)該覆蓋以下職責(zé)檢測(cè)是否有升級(jí)請(qǐng)求比如串口收到特定握手幀、升級(jí)引腳拉低、或者Flash中有升級(jí)標(biāo)志和上位機(jī)完成通信協(xié)商包括固件版本、長(zhǎng)度、校驗(yàn)碼擦除App區(qū)域的Flash扇區(qū)逐塊接收數(shù)據(jù)并寫(xiě)入校驗(yàn)整個(gè)固件全部通過(guò)后跳轉(zhuǎn)到App在App異常跑飛時(shí)能恢復(fù)升級(jí)模式而不是變磚。不歸Bootloader管的也很多它不負(fù)責(zé)具體應(yīng)用邏輯不負(fù)責(zé)電機(jī)控制參數(shù)更不是文件系統(tǒng)。做得越重越容易出問(wèn)題。本著“能少做就少做”的原則才是可靠的Bootloader。1.3 F28377D雙核架構(gòu)帶來(lái)的額外考量F28377D不是普通單核DSP它有兩個(gè)C28x CPU還有一個(gè)CLA實(shí)時(shí)協(xié)處理器。這意味著B(niǎo)ootloader不光要管自己的CPU1還要考慮CPU2的啟動(dòng)時(shí)序。我的做法是Bootloader主體放在CPU1上CPU1先啟動(dòng)判斷是否需要進(jìn)入升級(jí)模式如果需要升級(jí)就通過(guò)IPC中斷通知CPU2停下等待如果不需要升級(jí)先啟動(dòng)CPU2再跳轉(zhuǎn)App。這樣CPU2不需要單獨(dú)做一整套Bootloader簡(jiǎn)化了大半工作量。順帶提醒一句F28377D的上電時(shí)序里CPU2的復(fù)位和啟動(dòng)都受CPU1控制CPU2RESCTL、IPCBOOTMODE這些寄存器在寫(xiě)雙核程序時(shí)會(huì)頻繁用到。設(shè)計(jì)Bootloader時(shí)一定把CPU2這種“從屬啟動(dòng)”關(guān)系考慮進(jìn)去否則App能跑起來(lái)純屬運(yùn)氣。2. 啟動(dòng)鏈路梳理從CPU復(fù)位到Bootloader再到App2.1 Boot ROM與引導(dǎo)模式選擇的工作原理F28377D內(nèi)部固化了一段Boot ROMCPU復(fù)位后首先執(zhí)行的是這段ROM代碼。Boot ROM會(huì)根據(jù)采樣到的GPIO引腳狀態(tài)決定從哪個(gè)介質(zhì)加載程序可以是Flash、SCI、CAN、并行接口等。對(duì)量產(chǎn)產(chǎn)品來(lái)說(shuō)最常用的是“Flash啟動(dòng)”模式即Boot ROM直接把控制權(quán)交給Flash起始地址處的Bootloader代碼。至于哪些GPIO組合對(duì)應(yīng)哪種模式不同封裝的F28377D引腳分配可能不同我強(qiáng)烈建議打開(kāi)TI的《TMS320F2837xD Technical Reference Manual》里的Boot Mode Selection章節(jié)對(duì)照自己板子的原理圖逐一確認(rèn)。比較關(guān)鍵的一點(diǎn)是F28377D支持自定義引導(dǎo)模式OTP里可以燒寫(xiě)B(tài)OOTDEF讓Boot ROM按照你預(yù)設(shè)的方式選擇啟動(dòng)源。這意味著你可以設(shè)計(jì)成“上電先進(jìn)入Bootloader再?zèng)Q定跳不跳App”也可以設(shè)計(jì)成“上電直接跳App只有收到升級(jí)命令才復(fù)位進(jìn)Bootloader”。前者的優(yōu)點(diǎn)是升級(jí)入口永遠(yuǎn)可靠缺點(diǎn)是每次上電都會(huì)慢一點(diǎn)后者速度快但需要更多狀態(tài)判斷。2.2 跳轉(zhuǎn)App時(shí)到底發(fā)生了什么跳轉(zhuǎn)本質(zhì)上是一句函數(shù)指針調(diào)用把CPU的PC指針指到App的入口地址。但這背后有幾個(gè)容易被忽略的細(xì)節(jié)。C28x的入口通常是鏈接器符號(hào)_c_int00而不是用戶(hù)寫(xiě)的main函數(shù)。_c_int00是C運(yùn)行時(shí)初始化入口它負(fù)責(zé)初始化棧指針、全局變量、BSS段然后才調(diào)用main。所以跳轉(zhuǎn)App時(shí)必須跳到App的_c_int00不能直接跳到main地址。一個(gè)典型的跳轉(zhuǎn)函數(shù)長(zhǎng)這樣extern void _c_int00(void); #define APP_ENTRY_ADDR 0x090000 void jump_to_app(void) { // 先關(guān)閉全局中斷避免跳轉(zhuǎn)過(guò)程中被打斷 DINT(); // 關(guān)掉看門(mén)狗防止App初始化時(shí)間稍長(zhǎng)導(dǎo)致復(fù)位 ServiceDog(); // 如果有DMA/CLA在跑先禁掉 // 清掉PIE中斷標(biāo)志恢復(fù)默認(rèn)狀態(tài) // 把SP棧指針?lè)诺紸pp棧頂由鏈接器符號(hào)提供 // 這里演示直接用_c_int00入口跳轉(zhuǎn) ((void (*)(void))APP_ENTRY_ADDR)(); }不過(guò)實(shí)際工程里我不會(huì)往App入口地址塞死值而是把入口地址固化在Flash某個(gè)參數(shù)區(qū)升級(jí)時(shí)和固件一起更新。這樣Bootloader的代碼可以完全不變以后調(diào)整App起始地址也不需要?jiǎng)覤ootloader。2.3 PIE向量表跳轉(zhuǎn)失敗的高發(fā)區(qū)C2000系列的中斷向量在PIE向量表里PIE向量表默認(rèn)存放在RAM中由InitPieVectTable()初始化。問(wèn)題在于Bootloader運(yùn)行時(shí)PIE向量表里裝的是Bootloader的ISR地址跳轉(zhuǎn)到App后App的啟動(dòng)代碼會(huì)重新把PIE向量表覆蓋成App的ISR地址這本來(lái)沒(méi)問(wèn)題。但如果你在Bootloader里開(kāi)了某個(gè)外設(shè)中斷跳轉(zhuǎn)前又沒(méi)有徹底關(guān)掉它App初始化到一半時(shí)中斷來(lái)了CPU從PIE表里取到的是一個(gè)“已經(jīng)不存在”的Bootloader ISR地址結(jié)果可想而知。所以跳轉(zhuǎn)前清中斷標(biāo)志、禁止中斷、關(guān)閉無(wú)關(guān)外設(shè)時(shí)鐘這三步一個(gè)都不能省。3. CMD文件配置Bootloader和App的“內(nèi)存地圖”規(guī)劃3.1 CMD文件到底在管什么很多DSP初學(xué)者把CMD文件當(dāng)成一種“必抄模板”哪里報(bào)錯(cuò)改哪里根本不知道它在干什么。CMD文件本質(zhì)上是告訴鏈接器兩件事第一目標(biāo)芯片上有哪些可用的內(nèi)存區(qū)域MEMORY指令第二代碼和數(shù)據(jù)段分別放到哪些區(qū)域里SECTIONS指令。F28377D的地址空間比C2000老型號(hào)大得多Flash有1MB以上RAM也分了M0、M1、D0、D1、LS0-LS5等多個(gè)區(qū)域。正因?yàn)橘Y源多分區(qū)規(guī)劃就更容易混亂。Bootloader和App是兩個(gè)獨(dú)立工程各自有各自的CMD文件兩邊必須對(duì)同一個(gè)Flash布局協(xié)議保持一致否則Bootloader擦錯(cuò)扇區(qū)、App跳飛就是家常便飯。3.2 Bootloader工程的CMD文件示例下面這份CMD文件是我在一個(gè)F28377D項(xiàng)目中實(shí)際用過(guò)的簡(jiǎn)化版本。注意F28377D不同批次、不同子型號(hào)的Flash扇區(qū)邊界可能不同里面的地址必須先對(duì)照你手上芯片的Memory Map確認(rèn)不能直接照抄。MEMORY { PAGE 0: /* Bootloader占用Flash起始部分建議獨(dú)立扇區(qū) */ BOOT_FLASH : origin 0x080000, length 0x010000 /* App區(qū)域從另一個(gè)扇區(qū)邊界開(kāi)始 */ APP_FLASH : origin 0x090000, length 0x040000 /* 參數(shù)存儲(chǔ)區(qū)存放升級(jí)標(biāo)志、版本號(hào)、入口地址等 */ PARAM_FLASH : origin 0x0D0000, length 0x002000 /* Bootloader運(yùn)行時(shí)的局部代碼可放RAM提升Flash擦寫(xiě)可靠性 */ BOOT_RAM : origin 0x00D000, length 0x001000 PAGE 1: BOOT_STACK : origin 0x00C000, length 0x000800 } SECTIONS { /* 復(fù)位向量和啟動(dòng)入口必須放在Flash起始處 */ codestart : BOOT_FLASH, PAGE 0 .text : BOOT_FLASH, PAGE 0 .cinit : BOOT_FLASH, PAGE 0 .const : BOOT_FLASH, PAGE 0 .switch : BOOT_FLASH, PAGE 0 .stack : BOOT_STACK, PAGE 1 .bss : BOOT_RAM, PAGE 1 .data : BOOT_RAM, PAGE 1 .cio : BOOT_RAM, PAGE 1 .sysmem : BOOT_RAM, PAGE 1 }這里的BOOT_FLASH區(qū)域只給Bootloader用大小我留了64K。對(duì)于大多數(shù)Bootloader來(lái)說(shuō)哪怕加上Flash API庫(kù)和通信協(xié)議棧64K也完全夠用甚至很寬裕。APP_FLASH給應(yīng)用程序按項(xiàng)目實(shí)際大小調(diào)整。PARAM_FLASH是一個(gè)容易被忽視的獨(dú)立區(qū)域它保存的是“升級(jí)標(biāo)志”“固件版本”“App入口地址”這類(lèi)元數(shù)據(jù)。3.3 為什么必須單獨(dú)畫(huà)一個(gè)PARAM_FLASH區(qū)域你可能會(huì)問(wèn)升級(jí)標(biāo)志用普通全局變量不就行了嗎不行。全局變量在RAM里掉電就丟放在App的某個(gè)固定地址雖然能保存但每次升級(jí)App覆蓋Flash時(shí)可能把它一起沖掉需要額外保護(hù)。更合理的做法是單獨(dú)預(yù)留一小塊參數(shù)區(qū)不在Bootloader和App的代碼段范圍內(nèi)專(zhuān)門(mén)用來(lái)寫(xiě)這些控制信息。我項(xiàng)目的參數(shù)區(qū)包含這樣的結(jié)構(gòu)體typedef struct { uint32_t magic; // 固定魔數(shù)比如0x535A5346 uint32_t app_version; // App版本號(hào) uint32_t app_entry; // App入口地址 uint32_t boot_count; // Bootloader啟動(dòng)計(jì)數(shù) uint32_t upgrade_flag; // 是否需要升級(jí)的標(biāo)記 uint32_t crc32; // 結(jié)構(gòu)體自身CRC } BOOT_PARAM_T;每次上電Bootloader先讀這個(gè)結(jié)構(gòu)體校驗(yàn)magic和crc32再?zèng)Q定走升級(jí)流程還是跳App。如果項(xiàng)目不需要這么多字段精簡(jiǎn)成magic加upgrade_flag也夠用但結(jié)構(gòu)體一定要加CRC因?yàn)镕lash在極端環(huán)境下可能發(fā)生位翻轉(zhuǎn)靠一個(gè)魔數(shù)判斷可靠性不夠。3.4 App工程的CMD文件要改什么App工程的CMD文件和普通裸機(jī)工程的區(qū)別是不能覆蓋Bootloader區(qū)域向量表也要放到App自己的起點(diǎn)。下面是我App工程CMD里最關(guān)鍵的一段MEMORY { PAGE 0: APP_FLASH : origin 0x090000, length 0x040000 PARAM_FLASH : origin 0x0D0000, length 0x002000 } SECTIONS { codestart : APP_FLASH, PAGE 0 .text : APP_FLASH, PAGE 0 .cinit : APP_FLASH, PAGE 0 .const : APP_FLASH, PAGE 0 }注意App里的codestart段也放在APP_FLASH起始處目的是保證_c_int00入口地址正好落在0x090000。Bootloader跳轉(zhuǎn)時(shí)約定的入口地址是0x090000App編譯后入口也必須在這兩邊必須對(duì)齊。3.5 Flash扇區(qū)邊界與CMD分區(qū)的關(guān)系F28377D的Flash擦除以扇區(qū)為單位CMD分區(qū)不能隨便寫(xiě)任意地址必須落在扇區(qū)邊界上。如果一個(gè)扇區(qū)同時(shí)跨Bootloader和App就會(huì)出現(xiàn)“擦App時(shí)把Bootloader擦了一半”的悲劇。具體到F28377D不同扇區(qū)大小并不完全一樣。設(shè)計(jì)分區(qū)前我會(huì)把芯片Memory Map里的Flash Sector Table打印出來(lái)貼在工位上逐個(gè)扇區(qū)核對(duì)。比如Bootloader要占64K那就看哪幾個(gè)扇區(qū)拼起來(lái)正好是64K并且和其他區(qū)域互不交叉。分完區(qū)以后在Bootloader里寫(xiě)一段保護(hù)代碼明確禁止擦除低于某地址的Flash從代碼層面防止誤操作。這個(gè)保護(hù)邏輯后面在可靠性章節(jié)再展開(kāi)。4. 通信協(xié)議與Flash編程代碼實(shí)現(xiàn)4.1 協(xié)議幀設(shè)計(jì)定長(zhǎng)幀還是不定長(zhǎng)幀Bootloader的通訊協(xié)議是整個(gè)升級(jí)鏈路的地基。我最初圖省事用了一個(gè)最簡(jiǎn)單的定長(zhǎng)幀比如一次固定傳128字節(jié)代碼好寫(xiě)但App大了以后效率很低。后來(lái)改成不定長(zhǎng)幀一幀最多傳4KB升級(jí)1MB固件大概需要256幀配合一次ACK回包速度完全能接受。我用的幀格式長(zhǎng)這樣/* 幀結(jié)構(gòu) */ /* 幀頭 2字節(jié) 命令 1字節(jié) 數(shù)據(jù)長(zhǎng)度 2字節(jié) 數(shù)據(jù) N字節(jié) CRC32 4字節(jié) */ typedef struct { uint16_t sync; // 固定為0xA5A5 uint8_t cmd; // 命令字 uint16_t len; // 數(shù)據(jù)長(zhǎng)度小端 uint8_t data[4096]; // 數(shù)據(jù)區(qū) uint32_t crc32; // 對(duì)整個(gè)幀的CRC校驗(yàn) } BOOT_FRAME_T;命令字我定義了幾種CMD_HANDSHAKE握手上位機(jī)發(fā)版本Bootloader回當(dāng)前版本和Bootloader版本CMD_ERASE擦除App區(qū)域CMD_PROGRAM寫(xiě)入一幀數(shù)據(jù)CMD_VERIFY對(duì)寫(xiě)入的Flash做CRC校驗(yàn)CMD_JUMP_APP跳轉(zhuǎn)AppCMD_REBOOT軟復(fù)位。加上幀號(hào)機(jī)制會(huì)更穩(wěn)。我在幀頭里加了16位幀序號(hào)Bootloader收到后回ACK上位機(jī)超時(shí)重發(fā)。這里有個(gè)經(jīng)驗(yàn)不要讓Bootloader對(duì)每一幀都實(shí)時(shí)擦寫(xiě)效率太低。我會(huì)先把一幀數(shù)據(jù)暫存到RAM緩沖收滿(mǎn)一個(gè)扇區(qū)大小的數(shù)據(jù)后統(tǒng)一擦寫(xiě)一次把Flash擦除次數(shù)降下來(lái)。4.2 F28377D Flash API的正確打開(kāi)方式F28377D的Flash編程不能用寄存器直接操作TI官方提供F021 Flash API庫(kù)通常放在C2000Ware里。使用Flash API之前要先把庫(kù)加進(jìn)工程然后調(diào)用初始化函數(shù)#include FlashTech_F021.h #include F021_API.h void flash_api_init(void) { Fapi_initializeAPI(F021_FLASH0_BASE, 120); Fapi_setupFlashController(F021_FLASH0_BASE); Fapi_enressetting(); }注意Fapi_initializeAPI第二個(gè)參數(shù)是Flash頻率單位是MHz。你必須讓這個(gè)頻率和DSP實(shí)際運(yùn)行的SYSCLK一致否則Flash訪問(wèn)時(shí)序不對(duì)后面一切操作基本都會(huì)失敗。擦除扇區(qū)時(shí)常用的調(diào)用方式是這樣的Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector, (uint32_t *)APP_SECTOR_START); while (Fapi_getFsmStatus() ! Fapi_Status_FsmReady) { // 輪詢(xún)Flash狀態(tài)機(jī)直到空閑 }寫(xiě)入數(shù)據(jù)時(shí)需要把源、目的地址和字節(jié)數(shù)填進(jìn)命令結(jié)構(gòu)體uint8_t write_buffer[2048]; Fapi_issueProgrammingCommand((uint32_t *)APP_FLASH_OFFSET, write_buffer, 2048, 0, 0, 0); while (Fapi_getFsmStatus() ! Fapi_Status_FsmReady) { // 等待編程完成 }這里有一個(gè)很關(guān)鍵的細(xì)節(jié)Flash API庫(kù)的代碼本身也在Flash里。當(dāng)你在擦寫(xiě)Flash時(shí)CPU如果同時(shí)從同一塊Flash取指就會(huì)出現(xiàn)總線(xiàn)沖突甚至死機(jī)。正確做法是把Flash API相關(guān)函數(shù)放到RAM里去執(zhí)行比如在CMD文件里增加一個(gè)TI_NOINIT或自建的RAM段把需要執(zhí)行的函數(shù)用鏈接指令指定進(jìn)去。在CCS里可以用編譯指令控制函數(shù)存放位置#pragma CODE_SECTION(flash_erase_sector, .flashAPI)然后把.flashAPI段放到RAM里SECTIONS { .flashAPI : BOOT_RAM, PAGE 0 }這一步絕對(duì)不能省否則你會(huì)發(fā)現(xiàn)程序在Flash API運(yùn)行時(shí)卡死而且不是每次必現(xiàn)具備極強(qiáng)的玄學(xué)屬性。4.3 升級(jí)流程的完整狀態(tài)機(jī)我把Bootloader里的主循環(huán)寫(xiě)成狀態(tài)機(jī)而不是一長(zhǎng)串if else這樣便于擴(kuò)展和排錯(cuò)上電/復(fù)位初始化系統(tǒng)時(shí)鐘、看門(mén)狗、SCI/CAN外設(shè)讀取PARAM_FLASH里的升級(jí)標(biāo)志如果升級(jí)標(biāo)志有效進(jìn)入升級(jí)模式等待上位機(jī)通信如果升級(jí)標(biāo)志無(wú)效直接跳轉(zhuǎn)App升級(jí)模式里按收到命令切換狀態(tài)握手、擦除、編程、校驗(yàn)、跳轉(zhuǎn)App任何時(shí)候收到錯(cuò)誤幀回NACK并恢復(fù)等待狀態(tài)。每進(jìn)入一個(gè)狀態(tài)我習(xí)慣打一個(gè)調(diào)試日志通過(guò)串口發(fā)出來(lái)。別看這個(gè)細(xì)節(jié)簡(jiǎn)單量產(chǎn)設(shè)備里Bootloader出問(wèn)題很難用仿真器抓有時(shí)只能靠串口打印定位。我的Bootloader里專(zhuān)門(mén)編譯了一個(gè)DEBUG版本串口輸出完整狀態(tài)發(fā)布時(shí)再把打印關(guān)掉但保留狀態(tài)返回值。5. 不想到場(chǎng)變磚升級(jí)流程的可靠性設(shè)計(jì)5.1 升級(jí)標(biāo)志的“兩段式”確認(rèn)很多Bootloader的問(wèn)題出在“升級(jí)標(biāo)志寫(xiě)早了”。如果上位機(jī)剛發(fā)來(lái)一個(gè)升級(jí)請(qǐng)求Bootloader就把upgrade_flag寫(xiě)成1結(jié)果升級(jí)過(guò)程中途斷電下次上電Bootloader發(fā)現(xiàn)flag1進(jìn)入升級(jí)模式而上位機(jī)又沒(méi)準(zhǔn)備好設(shè)備就一直停在下載等待狀態(tài)看起來(lái)像磚了。我的做法是引入兩段式確認(rèn)第一段上位機(jī)發(fā)CMD_HANDSHAKEBootloader應(yīng)答此時(shí)不寫(xiě)標(biāo)志第二段收到完整固件并校驗(yàn)通過(guò)后Bootloader寫(xiě)一個(gè)PENDING_UPGRADE標(biāo)志第三段真正跳轉(zhuǎn)前上位機(jī)發(fā)CMD_JUMP_APPBootloader再把標(biāo)志清除然后跳轉(zhuǎn)。這樣即使斷電最多回到“上次App還完好”的狀態(tài)不會(huì)因?yàn)橹虚g狀態(tài)導(dǎo)致永久卡死。5.2 App WDT回退機(jī)制讓不正常的App自動(dòng)回到Bootloader一個(gè)再完善的Bootloader如果App本身跑飛產(chǎn)品照樣可能變成“廢品”。所以我在設(shè)計(jì)時(shí)強(qiáng)制加入WDT回退機(jī)制Bootloader跳轉(zhuǎn)App前不會(huì)關(guān)閉看門(mén)狗而是把看門(mén)狗周期設(shè)置成一個(gè)較長(zhǎng)值A(chǔ)pp正常啟動(dòng)后必須在規(guī)定時(shí)間內(nèi)“喂狗”并寫(xiě)一個(gè)APP_RUNNING_OK標(biāo)志如果App沒(méi)有及時(shí)喂狗例如固件不匹配、初始化死循環(huán)WDT會(huì)復(fù)位芯片Bootloader再次獲得控制權(quán)Bootloader檢測(cè)到APP_RUNNING_OK存在但版本更新標(biāo)記不對(duì)則進(jìn)入升級(jí)模式等待上位機(jī)。這樣一來(lái)即使燒寫(xiě)了一個(gè)有問(wèn)題的App設(shè)備也能通過(guò)WDT自動(dòng)復(fù)位回Bootloader重新升級(jí)正確固件。這個(gè)機(jī)制我在多臺(tái)樣機(jī)上驗(yàn)證過(guò)確實(shí)能攔住90%以上的“變磚”情況。5.3 Flash寫(xiě)保護(hù)與代碼級(jí)防線(xiàn)F28377D的Flash寄存器默認(rèn)就是寫(xiě)保護(hù)的操作前必須通過(guò)EALLOW指令解除保護(hù)操作完成后用EDIS恢復(fù)。這個(gè)機(jī)制本來(lái)是保護(hù)Flash內(nèi)容不被惡意破壞的但我在Bootloader里會(huì)再主動(dòng)做一層更嚴(yán)格的區(qū)域判斷。比如我在擦除函數(shù)開(kāi)頭加這樣一段邏輯bool is_sector_protected(uint32_t sector_addr) { /* 禁止擦除Bootloader區(qū)域和參數(shù)區(qū) */ if (sector_addr APP_SECTOR_START) return true; if (sector_addr APP_SECTOR_END) return true; return false; }所有擦寫(xiě)請(qǐng)求不管來(lái)自協(xié)議還是本地先過(guò)這個(gè)“門(mén)衛(wèi)”。這不是多余的謹(jǐn)慎我在調(diào)試早期因?yàn)樯衔粰C(jī)數(shù)據(jù)長(zhǎng)度算錯(cuò)確實(shí)差點(diǎn)把Bootloader自己的扇區(qū)擦掉有了這層保護(hù)即使協(xié)議解析出錯(cuò)也不會(huì)造成不可逆后果。5.4 CRC校驗(yàn)不能只做一次固件寫(xiě)完以后Bootloader會(huì)對(duì)整個(gè)App區(qū)域做一次CRC校驗(yàn)校驗(yàn)通過(guò)才允許跳轉(zhuǎn)。但這句話(huà)要拆成兩層來(lái)看一是傳輸層的CRC不能在傳輸過(guò)程中出錯(cuò)二是在跳轉(zhuǎn)之前再對(duì)Flash里的固件實(shí)際讀出來(lái)算一遍CRC防止寫(xiě)入環(huán)節(jié)出問(wèn)題。兩層校驗(yàn)分開(kāi)寫(xiě)每一層都有獨(dú)立的錯(cuò)誤處理。做到了這個(gè)程度即使現(xiàn)場(chǎng)有強(qiáng)電磁干擾、電源波動(dòng)升級(jí)也能大概率成功萬(wàn)一失敗也能安全回到Bootloader而不是卡死。6. 實(shí)測(cè)踩坑記錄與排查鏈路6.1 坑一跳轉(zhuǎn)App后直接死機(jī)連串口打印都沒(méi)有這是我最先遇到的坑。排查手段只剩一條用JTAG連仿真器單步跟蹤發(fā)現(xiàn)_c_int00入口地址確實(shí)進(jìn)去了但程序一直卡在棧指針初始化附近。最終原因是我在跳轉(zhuǎn)App前把棧指針SP重新設(shè)置了但App的CMD文件里.stack段分配到的RAM區(qū)域需要初始化而B(niǎo)ootloader跳轉(zhuǎn)時(shí)并沒(méi)有執(zhí)行App的啟動(dòng)代碼。后來(lái)我改成跳轉(zhuǎn)前不做額外的SP操作把SP的事情完全交給App的_c_int00處理問(wèn)題立刻消失。教訓(xùn)跳轉(zhuǎn)App時(shí)硬件狀態(tài)要盡可能“干凈”。不要自作聰明去提前設(shè)置寄存器除非你明確知道App啟動(dòng)代碼依賴(lài)什么。6.2 坑二Flash擦寫(xiě)偶爾報(bào)VREGFLT錯(cuò)誤F28377D的Flash模塊有一個(gè)電壓調(diào)整器狀態(tài)寄存器VREGFLT表示電壓調(diào)整器工作異常。這個(gè)錯(cuò)不是每次都出現(xiàn)但一旦出現(xiàn)擦寫(xiě)命令會(huì)失敗。排查后發(fā)現(xiàn)是Flash頻率參數(shù)設(shè)置不對(duì)。我在Fapi_initializeAPI里填的Flash頻率和SYSCLK實(shí)際值差了幾MHz導(dǎo)致Flash內(nèi)部電荷泵工作不穩(wěn)定。解決方法是統(tǒng)一用一個(gè)宏定義系統(tǒng)主頻初始化Flash API時(shí)直接引用絕不手填兩個(gè)數(shù)字。后面我還發(fā)現(xiàn)擦寫(xiě)Flash期間如果發(fā)生中斷容易觸發(fā)RAM沖突導(dǎo)致VREGFLT誤報(bào)。后來(lái)我在擦寫(xiě)關(guān)鍵區(qū)間加上了臨界區(qū)保護(hù)把中斷先掛起Flash操作完成后再放行。6.3 坑三CMD文件分配重疊編譯時(shí)不報(bào)運(yùn)行時(shí)才炸CMD文件里地址沖突鏈接器很多時(shí)候并不會(huì)給出明顯錯(cuò)誤它可能會(huì)把兩個(gè)段放到同一個(gè)地址而不告警尤其是當(dāng)你用了origin和length手工指定時(shí)。我遇到過(guò)一次Bootloader和App的.stack段都指定到了0x00C000編譯都通過(guò)結(jié)果App跑到中途棧指針越界寫(xiě)壞了Bootloader的數(shù)據(jù)。排查時(shí)把map文件打開(kāi)一行行比對(duì)才定位到是棧段重疊。經(jīng)驗(yàn)每次編譯完一定要看生成的.map文件。重點(diǎn)查.stack、.bss、.text的最終鏈接地址確認(rèn)沒(méi)有和Bootloader的鏈接布局重疊。如果兩個(gè)工程共用一個(gè)RAM地址哪怕錯(cuò)開(kāi)了運(yùn)行時(shí)間段也遲早出問(wèn)題。6.4 坑四SCI接收不定長(zhǎng)幀時(shí)串包Bootloader通信用UART時(shí)幀邊界如果沒(méi)處理干凈很容易串包。特別是有一次邊上有個(gè)變頻器干擾很大幀頭偶爾會(huì)被打成別的字節(jié)。我寫(xiě)了狀態(tài)機(jī)來(lái)接收狀態(tài)每次收到幀頭重新計(jì)數(shù)長(zhǎng)度字段加范圍判斷CRC不對(duì)直接丟棄等待下一個(gè)幀頭。這套UART狀態(tài)機(jī)排查了一段時(shí)間最終穩(wěn)定下來(lái)。一點(diǎn)心得不要迷信“加個(gè)延時(shí)就能避開(kāi)干擾”。串口協(xié)議必須要做幀同步、長(zhǎng)度校驗(yàn)、CRC三重保障缺一不可。CAN通信也一樣CAN本身有硬件校驗(yàn)但還是要在應(yīng)用層加幀序號(hào)和超時(shí)重傳機(jī)制防止丟幀造成混亂。6.5 坑五升級(jí)到一半上位機(jī)掉線(xiàn)Bootloader干等升級(jí)過(guò)程中如果上位機(jī)軟件崩潰、線(xiàn)纜斷開(kāi)Bootloader就會(huì)一直等在“接收數(shù)據(jù)”狀態(tài)看起來(lái)很無(wú)助。我加了一個(gè)30秒超時(shí)定時(shí)器每收到一幀就重置超時(shí)后自動(dòng)復(fù)位回到Bootloader起始狀態(tài)。同時(shí)上位機(jī)和Bootloader之間加了心跳機(jī)制心跳超時(shí)后Bootloader主動(dòng)上報(bào)“當(dāng)前狀態(tài)”上位機(jī)可以根據(jù)狀態(tài)決定繼續(xù)升級(jí)還是重新開(kāi)始。這套機(jī)制做下來(lái)現(xiàn)場(chǎng)升級(jí)再也沒(méi)出現(xiàn)“卡在中間、必須斷電”的情況。7. 一點(diǎn)個(gè)人體會(huì)給F28377D做Bootloader這件事代碼量并不大真正費(fèi)心思的是內(nèi)存規(guī)劃和各種邊界情況。我在樣機(jī)階段用了兩周把整個(gè)鏈路跑通后來(lái)在客戶(hù)現(xiàn)場(chǎng)用串口升級(jí)一次成功的時(shí)候覺(jué)得之前翻的那些問(wèn)題都值了。如果你也在做類(lèi)似產(chǎn)品我只有一個(gè)建議在項(xiàng)目啟動(dòng)第一天就把Flash分區(qū)畫(huà)好哪怕Bootloader先寫(xiě)個(gè)空實(shí)現(xiàn)也要把CMD文件、入口地址、升級(jí)標(biāo)志位的約定固定下來(lái)。后面再改布局成本比想象中大得多。希望這篇文章能幫你少踩幾個(gè)坑。 TMS320F28377D Bootloader設(shè)計(jì)與實(shí)現(xiàn)：Flash分區(qū)與跳轉(zhuǎn)實(shí)戰(zhàn)
剛接手一個(gè)基于TMS320F28377D的電機(jī)控制項(xiàng)目時(shí)客戶(hù)提的第一句話(huà)是“你們這個(gè)設(shè)備以后軟件升級(jí)方便嗎”。當(dāng)時(shí)整機(jī)已經(jīng)用JTAG調(diào)試了大半年所有代碼都在CCS里一次次燒寫(xiě)驗(yàn)證沒(méi)人覺(jué)得這會(huì)是個(gè)問(wèn)題。直到有一臺(tái)樣機(jī)發(fā)到現(xiàn)場(chǎng)、客戶(hù)想要改一組算法參數(shù)我才意識(shí)到一個(gè)沒(méi)有Bootloader的DSP產(chǎn)品在交付之后基本等于“要升級(jí)就必須拆機(jī)開(kāi)蓋接仿真器”。這篇文章把我給F28377D設(shè)計(jì)Bootloader的完整思路、CMD文件分配、跳轉(zhuǎn)代碼和踩過(guò)的坑整理出來(lái)希望能幫正在做C2000系列產(chǎn)品化開(kāi)發(fā)的同行少走彎路。這篇文章適合兩類(lèi)人看一類(lèi)是剛接觸C2000 Bootloader想知道“從哪下手”的工程師另一類(lèi)是已經(jīng)在做升級(jí)功能但被跳轉(zhuǎn)失敗、Flash編程報(bào)錯(cuò)、CMD分區(qū)沖突折磨過(guò)的開(kāi)發(fā)者。我會(huì)盡量把原理和操作放在一起講不會(huì)只貼代碼不給理由。1. 為什么非做Bootloader不可F28377D產(chǎn)品的三個(gè)現(xiàn)實(shí)痛點(diǎn)1.1 不要等產(chǎn)品交付了才想起升級(jí)問(wèn)題很多DSP項(xiàng)目在樣機(jī)階段都靠仿真器燒錄這沒(méi)有錯(cuò)畢竟調(diào)試階段JTAG是最直接的手段。但產(chǎn)品一旦到了現(xiàn)場(chǎng)情況完全不同。工業(yè)設(shè)備往往安裝在電柜里有些甚至在高空或狹窄空間想用XDS100V2連接目標(biāo)板必須先斷電、開(kāi)柜、拆擋板運(yùn)氣不好還要?jiǎng)咏泳€(xiàn)。Bootloader解決的不是“能不能燒”的問(wèn)題而是“怎么不拆機(jī)也能燒”的問(wèn)題。通過(guò)SCI串口或者CAN總線(xiàn)讓DSP自己把應(yīng)用程序固件接收下來(lái)寫(xiě)進(jìn)Flash這才是產(chǎn)品化該有的形態(tài)。我見(jiàn)過(guò)不少團(tuán)隊(duì)把Bootloader放到項(xiàng)目末期才做結(jié)果發(fā)現(xiàn)Flash分區(qū)已經(jīng)被應(yīng)用代碼占滿(mǎn)、中斷向量表動(dòng)不了、RAM段不夠用只能大改鏈接腳本。更合理的順序是在工程建立的第一天就把Bootloader占位規(guī)劃好哪怕先寫(xiě)一個(gè)空殼。1.2 Bootloader不是萬(wàn)能的先定義它的邊界設(shè)計(jì)Bootloader前先要搞清楚它到底負(fù)責(zé)什么。以我的經(jīng)驗(yàn)F28377D的Bootloader至少應(yīng)該覆蓋以下職責(zé)檢測(cè)是否有升級(jí)請(qǐng)求比如串口收到特定握手幀、升級(jí)引腳拉低、或者Flash中有升級(jí)標(biāo)志和上位機(jī)完成通信協(xié)商包括固件版本、長(zhǎng)度、校驗(yàn)碼擦除App區(qū)域的Flash扇區(qū)逐塊接收數(shù)據(jù)并寫(xiě)入校驗(yàn)整個(gè)固件全部通過(guò)后跳轉(zhuǎn)到App在App異常跑飛時(shí)能恢復(fù)升級(jí)模式而不是變磚。不歸Bootloader管的也很多它不負(fù)責(zé)具體應(yīng)用邏輯不負(fù)責(zé)電機(jī)控制參數(shù)更不是文件系統(tǒng)。做得越重越容易出問(wèn)題。本著“能少做就少做”的原則才是可靠的Bootloader。1.3 F28377D雙核架構(gòu)帶來(lái)的額外考量F28377D不是普通單核DSP它有兩個(gè)C28x CPU還有一個(gè)CLA實(shí)時(shí)協(xié)處理器。這意味著B(niǎo)ootloader不光要管自己的CPU1還要考慮CPU2的啟動(dòng)時(shí)序。我的做法是Bootloader主體放在CPU1上CPU1先啟動(dòng)判斷是否需要進(jìn)入升級(jí)模式如果需要升級(jí)就通過(guò)IPC中斷通知CPU2停下等待如果不需要升級(jí)先啟動(dòng)CPU2再跳轉(zhuǎn)App。這樣CPU2不需要單獨(dú)做一整套Bootloader簡(jiǎn)化了大半工作量。順帶提醒一句F28377D的上電時(shí)序里CPU2的復(fù)位和啟動(dòng)都受CPU1控制CPU2RESCTL、IPCBOOTMODE這些寄存器在寫(xiě)雙核程序時(shí)會(huì)頻繁用到。設(shè)計(jì)Bootloader時(shí)一定把CPU2這種“從屬啟動(dòng)”關(guān)系考慮進(jìn)去否則App能跑起來(lái)純屬運(yùn)氣。2. 啟動(dòng)鏈路梳理從CPU復(fù)位到Bootloader再到App2.1 Boot ROM與引導(dǎo)模式選擇的工作原理F28377D內(nèi)部固化了一段Boot ROMCPU復(fù)位后首先執(zhí)行的是這段ROM代碼。Boot ROM會(huì)根據(jù)采樣到的GPIO引腳狀態(tài)決定從哪個(gè)介質(zhì)加載程序可以是Flash、SCI、CAN、并行接口等。對(duì)量產(chǎn)產(chǎn)品來(lái)說(shuō)最常用的是“Flash啟動(dòng)”模式即Boot ROM直接把控制權(quán)交給Flash起始地址處的Bootloader代碼。至于哪些GPIO組合對(duì)應(yīng)哪種模式不同封裝的F28377D引腳分配可能不同我強(qiáng)烈建議打開(kāi)TI的《TMS320F2837xD Technical Reference Manual》里的Boot Mode Selection章節(jié)對(duì)照自己板子的原理圖逐一確認(rèn)。比較關(guān)鍵的一點(diǎn)是F28377D支持自定義引導(dǎo)模式OTP里可以燒寫(xiě)B(tài)OOTDEF讓Boot ROM按照你預(yù)設(shè)的方式選擇啟動(dòng)源。這意味著你可以設(shè)計(jì)成“上電先進(jìn)入Bootloader再?zèng)Q定跳不跳App”也可以設(shè)計(jì)成“上電直接跳App只有收到升級(jí)命令才復(fù)位進(jìn)Bootloader”。前者的優(yōu)點(diǎn)是升級(jí)入口永遠(yuǎn)可靠缺點(diǎn)是每次上電都會(huì)慢一點(diǎn)后者速度快但需要更多狀態(tài)判斷。2.2 跳轉(zhuǎn)App時(shí)到底發(fā)生了什么跳轉(zhuǎn)本質(zhì)上是一句函數(shù)指針調(diào)用把CPU的PC指針指到App的入口地址。但這背后有幾個(gè)容易被忽略的細(xì)節(jié)。C28x的入口通常是鏈接器符號(hào)_c_int00而不是用戶(hù)寫(xiě)的main函數(shù)。_c_int00是C運(yùn)行時(shí)初始化入口它負(fù)責(zé)初始化棧指針、全局變量、BSS段然后才調(diào)用main。所以跳轉(zhuǎn)App時(shí)必須跳到App的_c_int00不能直接跳到main地址。一個(gè)典型的跳轉(zhuǎn)函數(shù)長(zhǎng)這樣extern void _c_int00(void); #define APP_ENTRY_ADDR 0x090000 void jump_to_app(void) { // 先關(guān)閉全局中斷避免跳轉(zhuǎn)過(guò)程中被打斷 DINT(); // 關(guān)掉看門(mén)狗防止App初始化時(shí)間稍長(zhǎng)導(dǎo)致復(fù)位 ServiceDog(); // 如果有DMA/CLA在跑先禁掉 // 清掉PIE中斷標(biāo)志恢復(fù)默認(rèn)狀態(tài) // 把SP棧指針?lè)诺紸pp棧頂由鏈接器符號(hào)提供 // 這里演示直接用_c_int00入口跳轉(zhuǎn) ((void (*)(void))APP_ENTRY_ADDR)(); }不過(guò)實(shí)際工程里我不會(huì)往App入口地址塞死值而是把入口地址固化在Flash某個(gè)參數(shù)區(qū)升級(jí)時(shí)和固件一起更新。這樣Bootloader的代碼可以完全不變以后調(diào)整App起始地址也不需要?jiǎng)覤ootloader。2.3 PIE向量表跳轉(zhuǎn)失敗的高發(fā)區(qū)C2000系列的中斷向量在PIE向量表里PIE向量表默認(rèn)存放在RAM中由InitPieVectTable()初始化。問(wèn)題在于Bootloader運(yùn)行時(shí)PIE向量表里裝的是Bootloader的ISR地址跳轉(zhuǎn)到App后App的啟動(dòng)代碼會(huì)重新把PIE向量表覆蓋成App的ISR地址這本來(lái)沒(méi)問(wèn)題。但如果你在Bootloader里開(kāi)了某個(gè)外設(shè)中斷跳轉(zhuǎn)前又沒(méi)有徹底關(guān)掉它App初始化到一半時(shí)中斷來(lái)了CPU從PIE表里取到的是一個(gè)“已經(jīng)不存在”的Bootloader ISR地址結(jié)果可想而知。所以跳轉(zhuǎn)前清中斷標(biāo)志、禁止中斷、關(guān)閉無(wú)關(guān)外設(shè)時(shí)鐘這三步一個(gè)都不能省。3. CMD文件配置Bootloader和App的“內(nèi)存地圖”規(guī)劃3.1 CMD文件到底在管什么很多DSP初學(xué)者把CMD文件當(dāng)成一種“必抄模板”哪里報(bào)錯(cuò)改哪里根本不知道它在干什么。CMD文件本質(zhì)上是告訴鏈接器兩件事第一目標(biāo)芯片上有哪些可用的內(nèi)存區(qū)域MEMORY指令第二代碼和數(shù)據(jù)段分別放到哪些區(qū)域里SECTIONS指令。F28377D的地址空間比C2000老型號(hào)大得多Flash有1MB以上RAM也分了M0、M1、D0、D1、LS0-LS5等多個(gè)區(qū)域。正因?yàn)橘Y源多分區(qū)規(guī)劃就更容易混亂。Bootloader和App是兩個(gè)獨(dú)立工程各自有各自的CMD文件兩邊必須對(duì)同一個(gè)Flash布局協(xié)議保持一致否則Bootloader擦錯(cuò)扇區(qū)、App跳飛就是家常便飯。3.2 Bootloader工程的CMD文件示例下面這份CMD文件是我在一個(gè)F28377D項(xiàng)目中實(shí)際用過(guò)的簡(jiǎn)化版本。注意F28377D不同批次、不同子型號(hào)的Flash扇區(qū)邊界可能不同里面的地址必須先對(duì)照你手上芯片的Memory Map確認(rèn)不能直接照抄。MEMORY { PAGE 0: /* Bootloader占用Flash起始部分建議獨(dú)立扇區(qū) */ BOOT_FLASH : origin 0x080000, length 0x010000 /* App區(qū)域從另一個(gè)扇區(qū)邊界開(kāi)始 */ APP_FLASH : origin 0x090000, length 0x040000 /* 參數(shù)存儲(chǔ)區(qū)存放升級(jí)標(biāo)志、版本號(hào)、入口地址等 */ PARAM_FLASH : origin 0x0D0000, length 0x002000 /* Bootloader運(yùn)行時(shí)的局部代碼可放RAM提升Flash擦寫(xiě)可靠性 */ BOOT_RAM : origin 0x00D000, length 0x001000 PAGE 1: BOOT_STACK : origin 0x00C000, length 0x000800 } SECTIONS { /* 復(fù)位向量和啟動(dòng)入口必須放在Flash起始處 */ codestart : BOOT_FLASH, PAGE 0 .text : BOOT_FLASH, PAGE 0 .cinit : BOOT_FLASH, PAGE 0 .const : BOOT_FLASH, PAGE 0 .switch : BOOT_FLASH, PAGE 0 .stack : BOOT_STACK, PAGE 1 .bss : BOOT_RAM, PAGE 1 .data : BOOT_RAM, PAGE 1 .cio : BOOT_RAM, PAGE 1 .sysmem : BOOT_RAM, PAGE 1 }這里的BOOT_FLASH區(qū)域只給Bootloader用大小我留了64K。對(duì)于大多數(shù)Bootloader來(lái)說(shuō)哪怕加上Flash API庫(kù)和通信協(xié)議棧64K也完全夠用甚至很寬裕。APP_FLASH給應(yīng)用程序按項(xiàng)目實(shí)際大小調(diào)整。PARAM_FLASH是一個(gè)容易被忽視的獨(dú)立區(qū)域它保存的是“升級(jí)標(biāo)志”“固件版本”“App入口地址”這類(lèi)元數(shù)據(jù)。3.3 為什么必須單獨(dú)畫(huà)一個(gè)PARAM_FLASH區(qū)域你可能會(huì)問(wèn)升級(jí)標(biāo)志用普通全局變量不就行了嗎不行。全局變量在RAM里掉電就丟放在App的某個(gè)固定地址雖然能保存但每次升級(jí)App覆蓋Flash時(shí)可能把它一起沖掉需要額外保護(hù)。更合理的做法是單獨(dú)預(yù)留一小塊參數(shù)區(qū)不在Bootloader和App的代碼段范圍內(nèi)專(zhuān)門(mén)用來(lái)寫(xiě)這些控制信息。我項(xiàng)目的參數(shù)區(qū)包含這樣的結(jié)構(gòu)體typedef struct { uint32_t magic; // 固定魔數(shù)比如0x535A5346 uint32_t app_version; // App版本號(hào) uint32_t app_entry; // App入口地址 uint32_t boot_count; // Bootloader啟動(dòng)計(jì)數(shù) uint32_t upgrade_flag; // 是否需要升級(jí)的標(biāo)記 uint32_t crc32; // 結(jié)構(gòu)體自身CRC } BOOT_PARAM_T;每次上電Bootloader先讀這個(gè)結(jié)構(gòu)體校驗(yàn)magic和crc32再?zèng)Q定走升級(jí)流程還是跳App。如果項(xiàng)目不需要這么多字段精簡(jiǎn)成magic加upgrade_flag也夠用但結(jié)構(gòu)體一定要加CRC因?yàn)镕lash在極端環(huán)境下可能發(fā)生位翻轉(zhuǎn)靠一個(gè)魔數(shù)判斷可靠性不夠。3.4 App工程的CMD文件要改什么App工程的CMD文件和普通裸機(jī)工程的區(qū)別是不能覆蓋Bootloader區(qū)域向量表也要放到App自己的起點(diǎn)。下面是我App工程CMD里最關(guān)鍵的一段MEMORY { PAGE 0: APP_FLASH : origin 0x090000, length 0x040000 PARAM_FLASH : origin 0x0D0000, length 0x002000 } SECTIONS { codestart : APP_FLASH, PAGE 0 .text : APP_FLASH, PAGE 0 .cinit : APP_FLASH, PAGE 0 .const : APP_FLASH, PAGE 0 }注意App里的codestart段也放在APP_FLASH起始處目的是保證_c_int00入口地址正好落在0x090000。Bootloader跳轉(zhuǎn)時(shí)約定的入口地址是0x090000App編譯后入口也必須在這兩邊必須對(duì)齊。3.5 Flash扇區(qū)邊界與CMD分區(qū)的關(guān)系F28377D的Flash擦除以扇區(qū)為單位CMD分區(qū)不能隨便寫(xiě)任意地址必須落在扇區(qū)邊界上。如果一個(gè)扇區(qū)同時(shí)跨Bootloader和App就會(huì)出現(xiàn)“擦App時(shí)把Bootloader擦了一半”的悲劇。具體到F28377D不同扇區(qū)大小并不完全一樣。設(shè)計(jì)分區(qū)前我會(huì)把芯片Memory Map里的Flash Sector Table打印出來(lái)貼在工位上逐個(gè)扇區(qū)核對(duì)。比如Bootloader要占64K那就看哪幾個(gè)扇區(qū)拼起來(lái)正好是64K并且和其他區(qū)域互不交叉。分完區(qū)以后在Bootloader里寫(xiě)一段保護(hù)代碼明確禁止擦除低于某地址的Flash從代碼層面防止誤操作。這個(gè)保護(hù)邏輯后面在可靠性章節(jié)再展開(kāi)。4. 通信協(xié)議與Flash編程代碼實(shí)現(xiàn)4.1 協(xié)議幀設(shè)計(jì)定長(zhǎng)幀還是不定長(zhǎng)幀Bootloader的通訊協(xié)議是整個(gè)升級(jí)鏈路的地基。我最初圖省事用了一個(gè)最簡(jiǎn)單的定長(zhǎng)幀比如一次固定傳128字節(jié)代碼好寫(xiě)但App大了以后效率很低。后來(lái)改成不定長(zhǎng)幀一幀最多傳4KB升級(jí)1MB固件大概需要256幀配合一次ACK回包速度完全能接受。我用的幀格式長(zhǎng)這樣/* 幀結(jié)構(gòu) */ /* 幀頭 2字節(jié) 命令 1字節(jié) 數(shù)據(jù)長(zhǎng)度 2字節(jié) 數(shù)據(jù) N字節(jié) CRC32 4字節(jié) */ typedef struct { uint16_t sync; // 固定為0xA5A5 uint8_t cmd; // 命令字 uint16_t len; // 數(shù)據(jù)長(zhǎng)度小端 uint8_t data[4096]; // 數(shù)據(jù)區(qū) uint32_t crc32; // 對(duì)整個(gè)幀的CRC校驗(yàn) } BOOT_FRAME_T;命令字我定義了幾種CMD_HANDSHAKE握手上位機(jī)發(fā)版本Bootloader回當(dāng)前版本和Bootloader版本CMD_ERASE擦除App區(qū)域CMD_PROGRAM寫(xiě)入一幀數(shù)據(jù)CMD_VERIFY對(duì)寫(xiě)入的Flash做CRC校驗(yàn)CMD_JUMP_APP跳轉(zhuǎn)AppCMD_REBOOT軟復(fù)位。加上幀號(hào)機(jī)制會(huì)更穩(wěn)。我在幀頭里加了16位幀序號(hào)Bootloader收到后回ACK上位機(jī)超時(shí)重發(fā)。這里有個(gè)經(jīng)驗(yàn)不要讓Bootloader對(duì)每一幀都實(shí)時(shí)擦寫(xiě)效率太低。我會(huì)先把一幀數(shù)據(jù)暫存到RAM緩沖收滿(mǎn)一個(gè)扇區(qū)大小的數(shù)據(jù)后統(tǒng)一擦寫(xiě)一次把Flash擦除次數(shù)降下來(lái)。4.2 F28377D Flash API的正確打開(kāi)方式F28377D的Flash編程不能用寄存器直接操作TI官方提供F021 Flash API庫(kù)通常放在C2000Ware里。使用Flash API之前要先把庫(kù)加進(jìn)工程然后調(diào)用初始化函數(shù)#include FlashTech_F021.h #include F021_API.h void flash_api_init(void) { Fapi_initializeAPI(F021_FLASH0_BASE, 120); Fapi_setupFlashController(F021_FLASH0_BASE); Fapi_enressetting(); }注意Fapi_initializeAPI第二個(gè)參數(shù)是Flash頻率單位是MHz。你必須讓這個(gè)頻率和DSP實(shí)際運(yùn)行的SYSCLK一致否則Flash訪問(wèn)時(shí)序不對(duì)后面一切操作基本都會(huì)失敗。擦除扇區(qū)時(shí)常用的調(diào)用方式是這樣的Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector, (uint32_t *)APP_SECTOR_START); while (Fapi_getFsmStatus() ! Fapi_Status_FsmReady) { // 輪詢(xún)Flash狀態(tài)機(jī)直到空閑 }寫(xiě)入數(shù)據(jù)時(shí)需要把源、目的地址和字節(jié)數(shù)填進(jìn)命令結(jié)構(gòu)體uint8_t write_buffer[2048]; Fapi_issueProgrammingCommand((uint32_t *)APP_FLASH_OFFSET, write_buffer, 2048, 0, 0, 0); while (Fapi_getFsmStatus() ! Fapi_Status_FsmReady) { // 等待編程完成 }這里有一個(gè)很關(guān)鍵的細(xì)節(jié)Flash API庫(kù)的代碼本身也在Flash里。當(dāng)你在擦寫(xiě)Flash時(shí)CPU如果同時(shí)從同一塊Flash取指就會(huì)出現(xiàn)總線(xiàn)沖突甚至死機(jī)。正確做法是把Flash API相關(guān)函數(shù)放到RAM里去執(zhí)行比如在CMD文件里增加一個(gè)TI_NOINIT或自建的RAM段把需要執(zhí)行的函數(shù)用鏈接指令指定進(jìn)去。在CCS里可以用編譯指令控制函數(shù)存放位置#pragma CODE_SECTION(flash_erase_sector, .flashAPI)然后把.flashAPI段放到RAM里SECTIONS { .flashAPI : BOOT_RAM, PAGE 0 }這一步絕對(duì)不能省否則你會(huì)發(fā)現(xiàn)程序在Flash API運(yùn)行時(shí)卡死而且不是每次必現(xiàn)具備極強(qiáng)的玄學(xué)屬性。4.3 升級(jí)流程的完整狀態(tài)機(jī)我把Bootloader里的主循環(huán)寫(xiě)成狀態(tài)機(jī)而不是一長(zhǎng)串if else這樣便于擴(kuò)展和排錯(cuò)上電/復(fù)位初始化系統(tǒng)時(shí)鐘、看門(mén)狗、SCI/CAN外設(shè)讀取PARAM_FLASH里的升級(jí)標(biāo)志如果升級(jí)標(biāo)志有效進(jìn)入升級(jí)模式等待上位機(jī)通信如果升級(jí)標(biāo)志無(wú)效直接跳轉(zhuǎn)App升級(jí)模式里按收到命令切換狀態(tài)握手、擦除、編程、校驗(yàn)、跳轉(zhuǎn)App任何時(shí)候收到錯(cuò)誤幀回NACK并恢復(fù)等待狀態(tài)。每進(jìn)入一個(gè)狀態(tài)我習(xí)慣打一個(gè)調(diào)試日志通過(guò)串口發(fā)出來(lái)。別看這個(gè)細(xì)節(jié)簡(jiǎn)單量產(chǎn)設(shè)備里Bootloader出問(wèn)題很難用仿真器抓有時(shí)只能靠串口打印定位。我的Bootloader里專(zhuān)門(mén)編譯了一個(gè)DEBUG版本串口輸出完整狀態(tài)發(fā)布時(shí)再把打印關(guān)掉但保留狀態(tài)返回值。5. 不想到場(chǎng)變磚升級(jí)流程的可靠性設(shè)計(jì)5.1 升級(jí)標(biāo)志的“兩段式”確認(rèn)很多Bootloader的問(wèn)題出在“升級(jí)標(biāo)志寫(xiě)早了”。如果上位機(jī)剛發(fā)來(lái)一個(gè)升級(jí)請(qǐng)求Bootloader就把upgrade_flag寫(xiě)成1結(jié)果升級(jí)過(guò)程中途斷電下次上電Bootloader發(fā)現(xiàn)flag1進(jìn)入升級(jí)模式而上位機(jī)又沒(méi)準(zhǔn)備好設(shè)備就一直停在下載等待狀態(tài)看起來(lái)像磚了。我的做法是引入兩段式確認(rèn)第一段上位機(jī)發(fā)CMD_HANDSHAKEBootloader應(yīng)答此時(shí)不寫(xiě)標(biāo)志第二段收到完整固件并校驗(yàn)通過(guò)后Bootloader寫(xiě)一個(gè)PENDING_UPGRADE標(biāo)志第三段真正跳轉(zhuǎn)前上位機(jī)發(fā)CMD_JUMP_APPBootloader再把標(biāo)志清除然后跳轉(zhuǎn)。這樣即使斷電最多回到“上次App還完好”的狀態(tài)不會(huì)因?yàn)橹虚g狀態(tài)導(dǎo)致永久卡死。5.2 App WDT回退機(jī)制讓不正常的App自動(dòng)回到Bootloader一個(gè)再完善的Bootloader如果App本身跑飛產(chǎn)品照樣可能變成“廢品”。所以我在設(shè)計(jì)時(shí)強(qiáng)制加入WDT回退機(jī)制Bootloader跳轉(zhuǎn)App前不會(huì)關(guān)閉看門(mén)狗而是把看門(mén)狗周期設(shè)置成一個(gè)較長(zhǎng)值A(chǔ)pp正常啟動(dòng)后必須在規(guī)定時(shí)間內(nèi)“喂狗”并寫(xiě)一個(gè)APP_RUNNING_OK標(biāo)志如果App沒(méi)有及時(shí)喂狗例如固件不匹配、初始化死循環(huán)WDT會(huì)復(fù)位芯片Bootloader再次獲得控制權(quán)Bootloader檢測(cè)到APP_RUNNING_OK存在但版本更新標(biāo)記不對(duì)則進(jìn)入升級(jí)模式等待上位機(jī)。這樣一來(lái)即使燒寫(xiě)了一個(gè)有問(wèn)題的App設(shè)備也能通過(guò)WDT自動(dòng)復(fù)位回Bootloader重新升級(jí)正確固件。這個(gè)機(jī)制我在多臺(tái)樣機(jī)上驗(yàn)證過(guò)確實(shí)能攔住90%以上的“變磚”情況。5.3 Flash寫(xiě)保護(hù)與代碼級(jí)防線(xiàn)F28377D的Flash寄存器默認(rèn)就是寫(xiě)保護(hù)的操作前必須通過(guò)EALLOW指令解除保護(hù)操作完成后用EDIS恢復(fù)。這個(gè)機(jī)制本來(lái)是保護(hù)Flash內(nèi)容不被惡意破壞的但我在Bootloader里會(huì)再主動(dòng)做一層更嚴(yán)格的區(qū)域判斷。比如我在擦除函數(shù)開(kāi)頭加這樣一段邏輯bool is_sector_protected(uint32_t sector_addr) { /* 禁止擦除Bootloader區(qū)域和參數(shù)區(qū) */ if (sector_addr APP_SECTOR_START) return true; if (sector_addr APP_SECTOR_END) return true; return false; }所有擦寫(xiě)請(qǐng)求不管來(lái)自協(xié)議還是本地先過(guò)這個(gè)“門(mén)衛(wèi)”。這不是多余的謹(jǐn)慎我在調(diào)試早期因?yàn)樯衔粰C(jī)數(shù)據(jù)長(zhǎng)度算錯(cuò)確實(shí)差點(diǎn)把Bootloader自己的扇區(qū)擦掉有了這層保護(hù)即使協(xié)議解析出錯(cuò)也不會(huì)造成不可逆后果。5.4 CRC校驗(yàn)不能只做一次固件寫(xiě)完以后Bootloader會(huì)對(duì)整個(gè)App區(qū)域做一次CRC校驗(yàn)校驗(yàn)通過(guò)才允許跳轉(zhuǎn)。但這句話(huà)要拆成兩層來(lái)看一是傳輸層的CRC不能在傳輸過(guò)程中出錯(cuò)二是在跳轉(zhuǎn)之前再對(duì)Flash里的固件實(shí)際讀出來(lái)算一遍CRC防止寫(xiě)入環(huán)節(jié)出問(wèn)題。兩層校驗(yàn)分開(kāi)寫(xiě)每一層都有獨(dú)立的錯(cuò)誤處理。做到了這個(gè)程度即使現(xiàn)場(chǎng)有強(qiáng)電磁干擾、電源波動(dòng)升級(jí)也能大概率成功萬(wàn)一失敗也能安全回到Bootloader而不是卡死。6. 實(shí)測(cè)踩坑記錄與排查鏈路6.1 坑一跳轉(zhuǎn)App后直接死機(jī)連串口打印都沒(méi)有這是我最先遇到的坑。排查手段只剩一條用JTAG連仿真器單步跟蹤發(fā)現(xiàn)_c_int00入口地址確實(shí)進(jìn)去了但程序一直卡在棧指針初始化附近。最終原因是我在跳轉(zhuǎn)App前把棧指針SP重新設(shè)置了但App的CMD文件里.stack段分配到的RAM區(qū)域需要初始化而B(niǎo)ootloader跳轉(zhuǎn)時(shí)并沒(méi)有執(zhí)行App的啟動(dòng)代碼。后來(lái)我改成跳轉(zhuǎn)前不做額外的SP操作把SP的事情完全交給App的_c_int00處理問(wèn)題立刻消失。教訓(xùn)跳轉(zhuǎn)App時(shí)硬件狀態(tài)要盡可能“干凈”。不要自作聰明去提前設(shè)置寄存器除非你明確知道App啟動(dòng)代碼依賴(lài)什么。6.2 坑二Flash擦寫(xiě)偶爾報(bào)VREGFLT錯(cuò)誤F28377D的Flash模塊有一個(gè)電壓調(diào)整器狀態(tài)寄存器VREGFLT表示電壓調(diào)整器工作異常。這個(gè)錯(cuò)不是每次都出現(xiàn)但一旦出現(xiàn)擦寫(xiě)命令會(huì)失敗。排查后發(fā)現(xiàn)是Flash頻率參數(shù)設(shè)置不對(duì)。我在Fapi_initializeAPI里填的Flash頻率和SYSCLK實(shí)際值差了幾MHz導(dǎo)致Flash內(nèi)部電荷泵工作不穩(wěn)定。解決方法是統(tǒng)一用一個(gè)宏定義系統(tǒng)主頻初始化Flash API時(shí)直接引用絕不手填兩個(gè)數(shù)字。后面我還發(fā)現(xiàn)擦寫(xiě)Flash期間如果發(fā)生中斷容易觸發(fā)RAM沖突導(dǎo)致VREGFLT誤報(bào)。后來(lái)我在擦寫(xiě)關(guān)鍵區(qū)間加上了臨界區(qū)保護(hù)把中斷先掛起Flash操作完成后再放行。6.3 坑三CMD文件分配重疊編譯時(shí)不報(bào)運(yùn)行時(shí)才炸CMD文件里地址沖突鏈接器很多時(shí)候并不會(huì)給出明顯錯(cuò)誤它可能會(huì)把兩個(gè)段放到同一個(gè)地址而不告警尤其是當(dāng)你用了origin和length手工指定時(shí)。我遇到過(guò)一次Bootloader和App的.stack段都指定到了0x00C000編譯都通過(guò)結(jié)果App跑到中途棧指針越界寫(xiě)壞了Bootloader的數(shù)據(jù)。排查時(shí)把map文件打開(kāi)一行行比對(duì)才定位到是棧段重疊。經(jīng)驗(yàn)每次編譯完一定要看生成的.map文件。重點(diǎn)查.stack、.bss、.text的最終鏈接地址確認(rèn)沒(méi)有和Bootloader的鏈接布局重疊。如果兩個(gè)工程共用一個(gè)RAM地址哪怕錯(cuò)開(kāi)了運(yùn)行時(shí)間段也遲早出問(wèn)題。6.4 坑四SCI接收不定長(zhǎng)幀時(shí)串包Bootloader通信用UART時(shí)幀邊界如果沒(méi)處理干凈很容易串包。特別是有一次邊上有個(gè)變頻器干擾很大幀頭偶爾會(huì)被打成別的字節(jié)。我寫(xiě)了狀態(tài)機(jī)來(lái)接收狀態(tài)每次收到幀頭重新計(jì)數(shù)長(zhǎng)度字段加范圍判斷CRC不對(duì)直接丟棄等待下一個(gè)幀頭。這套UART狀態(tài)機(jī)排查了一段時(shí)間最終穩(wěn)定下來(lái)。一點(diǎn)心得不要迷信“加個(gè)延時(shí)就能避開(kāi)干擾”。串口協(xié)議必須要做幀同步、長(zhǎng)度校驗(yàn)、CRC三重保障缺一不可。CAN通信也一樣CAN本身有硬件校驗(yàn)但還是要在應(yīng)用層加幀序號(hào)和超時(shí)重傳機(jī)制防止丟幀造成混亂。6.5 坑五升級(jí)到一半上位機(jī)掉線(xiàn)Bootloader干等升級(jí)過(guò)程中如果上位機(jī)軟件崩潰、線(xiàn)纜斷開(kāi)Bootloader就會(huì)一直等在“接收數(shù)據(jù)”狀態(tài)看起來(lái)很無(wú)助。我加了一個(gè)30秒超時(shí)定時(shí)器每收到一幀就重置超時(shí)后自動(dòng)復(fù)位回到Bootloader起始狀態(tài)。同時(shí)上位機(jī)和Bootloader之間加了心跳機(jī)制心跳超時(shí)后Bootloader主動(dòng)上報(bào)“當(dāng)前狀態(tài)”上位機(jī)可以根據(jù)狀態(tài)決定繼續(xù)升級(jí)還是重新開(kāi)始。這套機(jī)制做下來(lái)現(xiàn)場(chǎng)升級(jí)再也沒(méi)出現(xiàn)“卡在中間、必須斷電”的情況。7. 一點(diǎn)個(gè)人體會(huì)給F28377D做Bootloader這件事代碼量并不大真正費(fèi)心思的是內(nèi)存規(guī)劃和各種邊界情況。我在樣機(jī)階段用了兩周把整個(gè)鏈路跑通后來(lái)在客戶(hù)現(xiàn)場(chǎng)用串口升級(jí)一次成功的時(shí)候覺(jué)得之前翻的那些問(wèn)題都值了。如果你也在做類(lèi)似產(chǎn)品我只有一個(gè)建議在項(xiàng)目啟動(dòng)第一天就把Flash分區(qū)畫(huà)好哪怕Bootloader先寫(xiě)個(gè)空實(shí)現(xiàn)也要把CMD文件、入口地址、升級(jí)標(biāo)志位的約定固定下來(lái)。后面再改布局成本比想象中大得多。希望這篇文章能幫你少踩幾個(gè)坑。