階：?jiǎn)?dòng)流程、故障定位與OTA升級(jí)實(shí)戰(zhàn)指南)
1. 為什么嵌入式固件越來(lái)越需要“進(jìn)階”思維先說(shuō)個(gè)我在技術(shù)社區(qū)里觀察到的現(xiàn)象。這幾年嵌入式崗位的要求變化非常明顯五年前會(huì)配置個(gè)寄存器、能點(diǎn)個(gè)燈、調(diào)通個(gè)UART基本就能應(yīng)付大部分工作?，F(xiàn)在再去招聘網(wǎng)站上看但凡薪資過(guò)得去的嵌入式崗位幾乎都寫著一行字熟悉固件啟動(dòng)流程有OTA升級(jí)實(shí)踐經(jīng)驗(yàn)具備獨(dú)立定位復(fù)雜嵌入式問(wèn)題的能力。門檻為什么抬高了因?yàn)楫a(chǎn)品形態(tài)變了。早期單片機(jī)項(xiàng)目大多是單機(jī)運(yùn)行的裸機(jī)程序代碼量撐死幾十KB跑飛了大不了復(fù)位重啟?，F(xiàn)在的嵌入式設(shè)備呢云連接是標(biāo)配遠(yuǎn)程升級(jí)是剛需MCU RTOS甚至MCU Linux SoC的異構(gòu)架構(gòu)越來(lái)越普遍。固件動(dòng)不動(dòng)幾MB要是啟動(dòng)流程沒(méi)搞清楚、故障定位靠瞎猜、OTA升級(jí)沒(méi)有回滾策略產(chǎn)品出廠就是災(zāi)難現(xiàn)場(chǎng)。另一個(gè)讓我印象深刻的點(diǎn)是很多工程師不是不努力而是學(xué)習(xí)路徑太散。今天看一篇裸機(jī)配置教程明天刷一段Linux驅(qū)動(dòng)分析后天翻到一個(gè)UBoot啟動(dòng)流程的帖子知識(shí)碎片化嚴(yán)重遇到實(shí)際問(wèn)題很難快速串起來(lái)。尤其是啟動(dòng)流程、故障定位、OTA升級(jí)這三個(gè)方向教科書(shū)上不會(huì)系統(tǒng)講日常工作里又沒(méi)法系統(tǒng)性總結(jié)屬于典型的“實(shí)踐中才能長(zhǎng)出來(lái)的經(jīng)驗(yàn)”。我寫這個(gè)連載專欄的初衷很簡(jiǎn)單把嵌入式固件進(jìn)階路上最硬核、最繞不開(kāi)的三個(gè)主題——啟動(dòng)流程深度拆解、故障定位方法論、OTA升級(jí)工程化實(shí)戰(zhàn)——串成一條完整的知識(shí)鏈配合課后思考題的完整解析讓讀者真正理解底層機(jī)制而不是停留在“能跑就行”的層面。這篇文章不整虛的我把專欄上篇的精華邏輯和核心思路整理出來(lái)相當(dāng)于給沒(méi)來(lái)得及訂閱的朋友做一次深度導(dǎo)覽。內(nèi)容包括MCU和SoC兩條啟動(dòng)路徑的完整拆解、RT-Thread啟動(dòng)初始化流程的逐步走讀、故障定位的系統(tǒng)化方法論、OTA升級(jí)工程化的分區(qū)策略和回滾機(jī)制以及上篇課后思考題的逐題解析。適合想進(jìn)階的嵌入式工程師、剛轉(zhuǎn)行做固件開(kāi)發(fā)的朋友以及正在準(zhǔn)備嵌入式面試的求職者。2. 啟動(dòng)流程深度拆解MCU與SoC的兩條路徑2.1 從復(fù)位向量到C main之間發(fā)生了什么很多人寫嵌入式代碼寫了三四年問(wèn)一個(gè)問(wèn)題芯片上電復(fù)位后第一條指令到底是從哪里取出來(lái)的回答得清楚的人不足三成。這不怪大家因?yàn)楝F(xiàn)代開(kāi)發(fā)環(huán)境把這段過(guò)程幾乎完全隱藏了編譯器、鏈接腳本、啟動(dòng)文件一條龍服務(wù)IDE里點(diǎn)一下編譯下載程序就跑起來(lái)了。但對(duì)固件進(jìn)階來(lái)說(shuō)這塊必須吃透因?yàn)樗鼪Q定了你對(duì)整個(gè)系統(tǒng)的掌控力。先說(shuō)MCU這條路徑最典型的比如STM32系列。芯片上電之后硬件邏輯會(huì)自動(dòng)從存儲(chǔ)器的起始地址讀取兩個(gè)關(guān)鍵值初始棧指針MSP和復(fù)位向量。注意這里的核心機(jī)制是地址0x00000000處存放棧頂?shù)刂返刂?x00000004處存放復(fù)位中斷服務(wù)程序的入口地址。這個(gè)布局不是任意約定的而是在Cortex-M架構(gòu)設(shè)計(jì)時(shí)就確定好的。CPU拿到復(fù)位向量后跳轉(zhuǎn)到SystemInit或者Reset_Handler執(zhí)行。先從啟動(dòng)文件startup_stm32xxx.s說(shuō)起這一段匯編做的事情包括三個(gè)部分設(shè)置初始棧指針、調(diào)用SystemInit進(jìn)行時(shí)鐘配置、然后調(diào)用C庫(kù)的初始化函數(shù)如__main完成數(shù)據(jù)段和BSS段的搬運(yùn)清零最終才跳到用戶的main函數(shù)。這里面最容易忽略但極為關(guān)鍵的細(xì)節(jié)是數(shù)據(jù)段的搬運(yùn)。編譯產(chǎn)物里初始化的全局變量初始值默認(rèn)存放在flash的只讀區(qū)域LOAD區(qū)程序運(yùn)行時(shí)需要這些變量存在于RAM中RUN區(qū)。啟動(dòng)代碼的核心任務(wù)之一就是把這部分?jǐn)?shù)據(jù)從flash拷貝到RAM這個(gè)操作在啟動(dòng)文件里通常寫作一個(gè)循環(huán)按字32位為單位搬運(yùn)還要處理邊界不對(duì)齊的情況。2.2 RT-Thread啟動(dòng)初始化流程走讀前面說(shuō)的還是裸機(jī)環(huán)境。如果用RT-Thread這類RTOS啟動(dòng)流程會(huì)再多出幾層關(guān)鍵邏輯。很多初學(xué)者第一次接觸RT-Thread時(shí)會(huì)有個(gè)困惑明明代碼里寫的是main函數(shù)入口為什么運(yùn)行起來(lái)后系統(tǒng)線程就已經(jīng)在跑了這就涉及到RT-Thread的啟動(dòng)初始化順序。RT-Thread的啟動(dòng)可以分為兩個(gè)階段。第一階段是從匯編Reset_Handler到C環(huán)境的main函數(shù)這跟裸機(jī)路徑類似。第二階段是從main函數(shù)里調(diào)用rtthread_startup()完成系統(tǒng)的全面初始化。具體來(lái)說(shuō)rtthread_startup的執(zhí)行流程大致是int rtthread_startup(void) { rt_hw_interrupt_disable(); /* 板級(jí)初始化必需。初始化系統(tǒng)滴答時(shí)鐘、引腳、串口等底層硬件 */ rt_hw_board_init(); /* 打印RT-Thread版本信息 */ rt_show_version(); /* 定時(shí)器線程初始化 */ rt_system_timer_init(); /* 調(diào)度器初始化必需 */ rt_system_scheduler_init(); /* 信號(hào)量、互斥量等內(nèi)核對(duì)象初始化 */ rt_system_sem_init(); /* 創(chuàng)建主線程 */ rt_application_init(); /* 定時(shí)器線程啟動(dòng) */ rt_system_timer_thread_init(); /* 空閑線程初始化 */ rt_thread_idle_init(); /* 啟動(dòng)調(diào)度器不再返回 */ rt_system_scheduler_start(); }注意觀察這個(gè)順序背后的邏輯。中斷最先被關(guān)閉是為了保證初始化過(guò)程的原子性板級(jí)初始化必須在系統(tǒng)初始化之前因?yàn)閮?nèi)核對(duì)象的創(chuàng)建很多依賴時(shí)鐘和內(nèi)存基礎(chǔ)調(diào)度器的初始化要先于線程的創(chuàng)建但調(diào)度器的啟動(dòng)必須在所有初始化完成后。有個(gè)細(xì)節(jié)值得單獨(dú)提出來(lái)rt_hw_board_init里會(huì)調(diào)用rt_hw_clock_init配置系統(tǒng)時(shí)鐘調(diào)用rt_hw_console_init初始化控制臺(tái)輸出。如果你在調(diào)試時(shí)發(fā)現(xiàn)串口沒(méi)有輸出第一步就該查這兩個(gè)函數(shù)的執(zhí)行情況。我在實(shí)際項(xiàng)目里遇到過(guò)一例板級(jí)初始化卡死在等待外部晶振穩(wěn)定的循環(huán)里導(dǎo)致系統(tǒng)完全無(wú)法啟動(dòng)這類問(wèn)題靠串口調(diào)試根本看不到線索只能從啟動(dòng)流程的時(shí)序推理入手。RT-Thread還提供了一種組件初始化機(jī)制使用INIT_BOARD_EXPORT、INIT_APP_EXPORT等宏將初始化函數(shù)按優(yōu)先級(jí)自動(dòng)注冊(cè)。這種方式讓驅(qū)動(dòng)和應(yīng)用的初始化代碼可以分散在各文件中可維護(hù)性更好但對(duì)啟動(dòng)順序的理解要求也更高。默認(rèn)的優(yōu)先級(jí)順序是板級(jí)初始化→組件初始化→內(nèi)核初始化→應(yīng)用初始化理解這個(gè)鏈路是排查“驅(qū)動(dòng)程序沒(méi)生效”類問(wèn)題的基本功。2.3 SoC與UBoot從Boot ROM到內(nèi)核啟動(dòng)講完MCU再看SoC這條路徑典型代表是各種應(yīng)用處理器平臺(tái)。這類芯片的啟動(dòng)流程比MCU復(fù)雜得多一般分為Boot ROM、Bootloader、內(nèi)核三個(gè)階段。Boot ROM是芯片出廠時(shí)固化在片內(nèi)ROM里的一段程序不可修改它的職責(zé)是初始化最基本的外設(shè)比如存儲(chǔ)控制器、時(shí)鐘然后根據(jù)啟動(dòng)引腳的電平配置從指定介質(zhì)加載第一段可執(zhí)行代碼。這里說(shuō)的第一段可執(zhí)行代碼通常就是SPLSecondary Program Loader或ARM Trusted Firmware中的BL2它們會(huì)進(jìn)一步初始化DRAM、串口、MMU等關(guān)鍵外設(shè)然后把真正的UBoot加載到內(nèi)存中運(yùn)行。UBoot完整起來(lái)之后才是大家比較熟悉的操作讀取環(huán)境變量、加載內(nèi)核鏡像到內(nèi)存、設(shè)置啟動(dòng)參數(shù)、跳轉(zhuǎn)執(zhí)行。UBoot的啟動(dòng)流程如果細(xì)拆大概是這個(gè)脈絡(luò)入口函數(shù)board_init_f完成CPU、板級(jí)、DRAM等基礎(chǔ)初始化將代碼重定位到RAM中執(zhí)行board_init_r在RAM中繼續(xù)完成剩下的外設(shè)初始化如網(wǎng)卡、USB、存儲(chǔ)設(shè)備驅(qū)動(dòng)解析bootcmd環(huán)境變量根據(jù)命令行的配置找到內(nèi)核鏡像調(diào)用bootm命令或booti命令搬運(yùn)內(nèi)核鏡像到指定地址將設(shè)備樹(shù)地址、initrd地址、啟動(dòng)參數(shù)地址設(shè)置好后跳轉(zhuǎn)到內(nèi)核入口SoC啟動(dòng)和MCU啟動(dòng)最大的思維差異在于MCU通常直接從內(nèi)部flash取指執(zhí)行而SoC經(jīng)歷了“從外部介質(zhì)加載—搬到內(nèi)存—從內(nèi)存啟動(dòng)”的多次搬運(yùn)過(guò)程每一次搬運(yùn)失敗都會(huì)導(dǎo)致啟動(dòng)停留在某個(gè)不可預(yù)期的狀態(tài)。排查這類問(wèn)題一個(gè)燒錄了完整啟動(dòng)日志的系統(tǒng)串口遠(yuǎn)比仿真器好用串口輸出能讓你快速定位系統(tǒng)到底卡在哪個(gè)階段。關(guān)于RT-Thread和MCU/SoC的啟動(dòng)過(guò)程網(wǎng)上有很多零散的教程但大多只講“怎么配”不講“為什么這么配”。我在專欄里花了大篇幅把這層機(jī)制補(bǔ)上因?yàn)闄C(jī)制不通看再多配置教程也是照貓畫(huà)虎換個(gè)芯片型號(hào)就抓瞎。3. 故障定位方法論從“瞎猜”到“系統(tǒng)排查”3.1 為什么你定位Bug總是靠運(yùn)氣嵌入式開(kāi)發(fā)里有個(gè)很常見(jiàn)的畫(huà)面程序偶發(fā)崩潰工程師開(kāi)始懷疑這懷疑那——掉電檢測(cè)不對(duì)、看門狗配置錯(cuò)誤、某個(gè)中斷優(yōu)先級(jí)太低、編譯器優(yōu)化等級(jí)太高……然后給代碼里到處加打印跑了一整天復(fù)現(xiàn)不到實(shí)在沒(méi)辦法就重啟一下碰碰運(yùn)氣。這種靠運(yùn)氣的排查方式有個(gè)共性問(wèn)題沒(méi)有建立系統(tǒng)化的排查鏈路。高效率的故障定位本質(zhì)上是“通過(guò)可觀測(cè)信息縮小問(wèn)題范圍并利用運(yùn)行機(jī)制指導(dǎo)排查方向”的迭代過(guò)程。它分成固定的步驟收集上下文集→提出多個(gè)假設(shè)→設(shè)計(jì)關(guān)鍵實(shí)驗(yàn)驗(yàn)證假設(shè)→收斂到根因→驗(yàn)證修復(fù)方案。我先說(shuō)一個(gè)真實(shí)案例。有次幫朋友排查一個(gè)產(chǎn)品問(wèn)題設(shè)備運(yùn)行幾小時(shí)后偶發(fā)死機(jī)復(fù)位后短時(shí)間正常過(guò)段時(shí)間又復(fù)發(fā)。第一次接手時(shí)的排查進(jìn)展很慢因?yàn)閺?fù)現(xiàn)周期太長(zhǎng)。后來(lái)決定先收集數(shù)據(jù)而非直接修代碼在系統(tǒng)死機(jī)前讓調(diào)試串口持續(xù)輸出內(nèi)存使用率和任務(wù)調(diào)度計(jì)數(shù)的快照發(fā)現(xiàn)每次死機(jī)前幾分鐘堆內(nèi)存的使用率都在穩(wěn)定攀升直到接近峰值后系統(tǒng)異常。問(wèn)題很快被鎖定為內(nèi)存泄漏——不是硬件問(wèn)題不是時(shí)鐘問(wèn)題是某個(gè)消息隊(duì)列的節(jié)點(diǎn)反復(fù)申請(qǐng)但不釋放。這個(gè)案例告訴我們定位問(wèn)題的第一步永遠(yuǎn)是收集數(shù)據(jù)而不是修改代碼。數(shù)據(jù)收集的渠道包括串口日志、運(yùn)行時(shí)統(tǒng)計(jì)信息、崩潰時(shí)的寄存器快照甚至是外置邏輯分析儀的時(shí)序數(shù)據(jù)。數(shù)據(jù)越完整假設(shè)空間的縮小速度越快。3.2 HardFault_HandlerCortex-M工程師最熟悉又最陌生的朋友嵌入式固件開(kāi)發(fā)里Cortex-M內(nèi)核的HardFault異?？赡苁怯龅竭^(guò)最多、也最讓新人恐懼的報(bào)錯(cuò)。程序跑著跑著突然進(jìn)了HardFault_Handler反匯編窗口一片亂碼call stack識(shí)別不出來(lái)除了復(fù)位不知道還能干嘛。HardFault的定位其實(shí)有標(biāo)準(zhǔn)流程核心是記住發(fā)生異常時(shí)核心會(huì)自動(dòng)把一組寄存器壓棧包括R0、R1、R2、R3、R12、LR、PC、xPSR。這組寄存器存儲(chǔ)在當(dāng)前的棧指針MSP或PSP指向的內(nèi)存區(qū)域。拿到崩潰現(xiàn)場(chǎng)后關(guān)鍵在于還原兩個(gè)信息程序是從哪條指令崩的PC以及是從哪個(gè)調(diào)用點(diǎn)進(jìn)去的LR。實(shí)際排查時(shí)我習(xí)慣先看LR寄存器的值。Cortex-M的LR在進(jìn)入異常時(shí)會(huì)被設(shè)置成一個(gè)特殊值EXC_RETURN通過(guò)判別這個(gè)值的bit位可以知道異常前使用的是MSP還是PSP進(jìn)而找到正確的棧指針。然后根據(jù)棧指針地址從內(nèi)存里逆序讀出壓棧的寄存器組。這里有個(gè)實(shí)操技巧在HardFault_Handler里加一小段匯編直接讀取棧指針并保存到全局變量__asm void hard_fault_get_sp(void) { MOV R0, SP LDR R1, hard_fault_sp STR R0, [R1] BX LR } void HardFault_Handler(void) { hard_fault_get_sp(); /* 在這里把hard_fault_sp指向的寄存器組打印出來(lái) */ }拿到PC和LR之后打開(kāi)map文件或者反匯編文件找到這兩個(gè)地址對(duì)應(yīng)的函數(shù)崩潰的位置基本就水落石出了。注意不要指望編譯器的call stack窗口能自動(dòng)識(shí)別因?yàn)閮?yōu)化后的代碼經(jīng)常沒(méi)有幀指針常規(guī)的?；厮菟惴〞?huì)失效。還有個(gè)容易被忽略的點(diǎn)就是總線錯(cuò)誤BusFault和用法錯(cuò)誤UsageFault。很多時(shí)候HardFault只是最終結(jié)果真正的異常來(lái)源是其它Fault。建議在啟動(dòng)階段就把三個(gè)Fault的優(yōu)先級(jí)配置好同時(shí)把UsageFault里的除零錯(cuò)誤、未對(duì)齊訪問(wèn)等檢測(cè)位打開(kāi)這樣崩潰時(shí)可以直接進(jìn)入對(duì)應(yīng)的Handler打印出的信息比單純一個(gè)HardFault精確得多。3.3 可觀測(cè)性建設(shè)日志分級(jí)與運(yùn)行時(shí)追蹤要真正擺脫“故障靠猜”必須在產(chǎn)品設(shè)計(jì)階段就把可觀測(cè)性考慮進(jìn)去。嵌入式環(huán)境相比服務(wù)器后端一個(gè)天然劣勢(shì)是日志資源極其有限內(nèi)存可能只有幾十KBflash空間也緊張沒(méi)法像云服務(wù)那樣搞一套完整日志中臺(tái)。但再有限也有分級(jí)分層的做法。我常用的日志方案是優(yōu)先級(jí)分級(jí)。ERROR級(jí)別必須實(shí)時(shí)打印因?yàn)槟鞘切枰⒓醋⒁獾漠惓ARNING級(jí)別可以緩沖輸出不影響主線運(yùn)行INFO級(jí)別默認(rèn)關(guān)閉通過(guò)編譯開(kāi)關(guān)或運(yùn)行時(shí)控制塊動(dòng)態(tài)開(kāi)啟DEBUG級(jí)別只在調(diào)試版本啟用。這套分級(jí)聽(tīng)著簡(jiǎn)單實(shí)際落地時(shí)很多人會(huì)搞混“詳情”和“關(guān)鍵信息”恨不得把所有變量都打印出來(lái)結(jié)果串口被日志淹沒(méi)真正有價(jià)值的現(xiàn)場(chǎng)信息反而被沖掉了。運(yùn)行時(shí)追蹤做得好也能大幅提升故障定位效率。一個(gè)相對(duì)輕量的方式是使用周期計(jì)數(shù)器DWT-CYCCNT記錄關(guān)鍵函數(shù)的執(zhí)行時(shí)間超時(shí)自動(dòng)打點(diǎn)不用額外引入邏輯分析儀就能評(píng)估某些時(shí)序問(wèn)題。另一個(gè)被很多團(tuán)隊(duì)使用的方案是環(huán)形緩沖區(qū)的崩潰日志存儲(chǔ)把最近的日志寫到專用的flash分區(qū)系統(tǒng)復(fù)位后上電讀取最后一段日志能直接看到崩潰前最后執(zhí)行的操作。比起串口長(zhǎng)時(shí)間掛機(jī)抓日志這個(gè)方法對(duì)偶發(fā)問(wèn)題的捕獲率明顯更高。3.4 RTOS環(huán)境下死機(jī)問(wèn)題的排查重點(diǎn)這里單獨(dú)提一下RTOS環(huán)境。上了RTOS之后故障排查的維度又多了幾個(gè)常見(jiàn)的坑包括任務(wù)棧溢出、中斷里調(diào)用非中斷安全API、優(yōu)先級(jí)反轉(zhuǎn)導(dǎo)致的死鎖、設(shè)備驅(qū)動(dòng)和任務(wù)的競(jìng)態(tài)條件。任務(wù)棧溢出是最常見(jiàn)的。RT-Thread提供了鉤子函數(shù)檢查棧溢出在任務(wù)切換時(shí)比較任務(wù)棧的當(dāng)前水位和棧頂標(biāo)記一旦檢測(cè)到溢出就觸發(fā)鉤子回調(diào)。配置方式是rt_thread_init(thread, task1, task1_entry, RT_NULL, stack_start, stack_size, PRIORITY, TICK); #ifdef RT_USING_HOOK rt_thread_setscheduler_hook(stack_overflow_hook); #endif實(shí)際項(xiàng)目里我還會(huì)在任務(wù)棧的尾部填一個(gè)固定的魔術(shù)字0xA5A5A5A5在系統(tǒng)空閑時(shí)掃描所有任務(wù)棧的魔術(shù)字是否被破壞。這個(gè)方法比依賴RTOS自帶的棧檢查更主動(dòng)能夠更早地發(fā)現(xiàn)“即將溢出但還沒(méi)到檢測(cè)點(diǎn)”的危險(xiǎn)狀態(tài)。中斷上下文里調(diào)用危險(xiǎn)API的問(wèn)題排查起來(lái)更隱蔽。某次客戶反饋設(shè)備在極端工況下偶發(fā)死鎖代碼審查沒(méi)發(fā)現(xiàn)問(wèn)題后來(lái)通過(guò)在IRQHandler入口和出口分別置位某個(gè)GPIO用示波器測(cè)量GPIO的時(shí)序發(fā)現(xiàn)一個(gè)定時(shí)器中斷的執(zhí)行時(shí)間異常拉長(zhǎng)——糟糕的是這個(gè)中斷服務(wù)函數(shù)內(nèi)部調(diào)用了rt_thread_mdelay導(dǎo)致調(diào)度器狀態(tài)錯(cuò)亂。這種問(wèn)題日志幾乎看不出來(lái)必須靠時(shí)序測(cè)量和代碼走讀結(jié)合。4. OTA升級(jí)工程化實(shí)戰(zhàn)分區(qū)、差分包與回滾4.1 在線升級(jí)的本質(zhì)不是“寫flash”而是“管理風(fēng)險(xiǎn)”O(jiān)TA升級(jí)是嵌入式產(chǎn)品由“工程樣品”走向“量產(chǎn)設(shè)備”的一道分水嶺。帶OTA功能的產(chǎn)品意味著你可以在設(shè)備售出之后繼續(xù)修復(fù)bug、迭代功能但也意味著你有了新的“翻車”方式——升級(jí)程序本身出問(wèn)題把設(shè)備變磚。我見(jiàn)過(guò)很多團(tuán)隊(duì)的第一版OTA方案做得相當(dāng)簡(jiǎn)單粗暴在應(yīng)用里接收升級(jí)包直接擦除當(dāng)前應(yīng)用分區(qū)寫入新固件然后跳轉(zhuǎn)重啟。這種方案有個(gè)致命問(wèn)題一旦寫flash過(guò)程中掉電、寫入了損壞的數(shù)據(jù)、或者新固件本身有bug導(dǎo)致系統(tǒng)無(wú)法啟動(dòng)設(shè)備就徹底變成了一塊磚頭只能返廠燒錄。OTA工程化的核心本質(zhì)其實(shí)是風(fēng)險(xiǎn)控制不是單純的程序搬運(yùn)。設(shè)計(jì)一個(gè)合格的OTA系統(tǒng)至少要覆蓋三個(gè)場(chǎng)景下載中斷能不能續(xù)傳、升級(jí)失敗能不能回滾、升級(jí)過(guò)程中設(shè)備意外斷電會(huì)不會(huì)損壞。這三個(gè)問(wèn)題每一個(gè)都對(duì)應(yīng)一套具體的設(shè)計(jì)策略。4.2 分區(qū)表設(shè)計(jì)A/B分區(qū)與recovery分區(qū)之爭(zhēng)分區(qū)設(shè)計(jì)是整個(gè)OTA升級(jí)的基石。目前主流的方案有兩種一種是A/B系統(tǒng)分區(qū)方案另一種是recovery模式方案。A/B方案也叫雙分區(qū)方案思路很簡(jiǎn)單把應(yīng)用分區(qū)分成A和B兩個(gè)槽位系統(tǒng)從一個(gè)槽位啟動(dòng)升級(jí)時(shí)寫入另一個(gè)槽位寫入成功后更新啟動(dòng)標(biāo)志重啟后bootloader從新槽位啟動(dòng)。這樣天然解決了回滾問(wèn)題如果新槽位啟動(dòng)失敗bootloader可以自動(dòng)切換到舊槽位啟動(dòng)。A/B方案對(duì)硬件的要求是flash空間多出一倍在存儲(chǔ)容量緊張的低成本MCU上實(shí)施有一定難度。recovery方案則是在flash里劃分一個(gè)獨(dú)立的recovery分區(qū)專門用來(lái)存放升級(jí)邏輯。主應(yīng)用升級(jí)時(shí)先寫入recovery分區(qū)然后重啟進(jìn)入recovery模式由recovery程序負(fù)責(zé)把新應(yīng)用寫入主分區(qū)。這種方案節(jié)省空間但回滾邏輯復(fù)雜一些需要recovery程序本身足夠健壯。我自己的經(jīng)驗(yàn)是flash容量在2MB以下的MCU產(chǎn)品優(yōu)先考慮recovery方案把recovery程序做得足夠精簡(jiǎn)穩(wěn)定flash容量充足的產(chǎn)品直接上A/B分區(qū)回滾邏輯簡(jiǎn)單可靠長(zhǎng)期維護(hù)成本最低。還有一個(gè)很多教程不會(huì)提的細(xì)節(jié)無(wú)論哪種方案都要在分區(qū)表里預(yù)留一個(gè)專門存放“啟動(dòng)狀態(tài)標(biāo)志”的區(qū)域。每次啟動(dòng)時(shí)bootloader先讀取這個(gè)區(qū)域的標(biāo)志值決定從哪個(gè)分區(qū)啟動(dòng)應(yīng)用正常運(yùn)行后將狀態(tài)標(biāo)志更新為“上次啟動(dòng)成功”。如果因?yàn)槌绦虮罎⒒蛘咝掳姹井惓?dǎo)致系統(tǒng)反復(fù)復(fù)位bootloader就能檢測(cè)到“連續(xù)啟動(dòng)失敗”的情況自動(dòng)觸發(fā)回滾。4.3 差分包生成與斷點(diǎn)續(xù)傳思路OTA升級(jí)要面對(duì)的現(xiàn)實(shí)約束是網(wǎng)絡(luò)帶寬和流量成本。設(shè)備可能通過(guò)2G/4G模塊甚至NB-IoT聯(lián)網(wǎng)單次傳輸幾十MB的全量升級(jí)包顯然不現(xiàn)實(shí)。差分包是更務(wù)實(shí)的選擇。差分包的基本原理是在升級(jí)服務(wù)器端用舊的固件版本作為基礎(chǔ)版本生成與新版固件之間的差異補(bǔ)丁比如使用bsdiff算法設(shè)備端只需要下載這個(gè)差異補(bǔ)丁通過(guò)逆向差分算法將本地固件與補(bǔ)丁合成新固件。差分包通常比全量包小80%以上在低帶寬高延遲的嵌入式網(wǎng)絡(luò)環(huán)境下優(yōu)勢(shì)明顯。設(shè)備端實(shí)現(xiàn)差分合成時(shí)有個(gè)關(guān)鍵注意點(diǎn)需要注意存儲(chǔ)空間。合成過(guò)程通常需要同時(shí)保留舊固件、補(bǔ)丁文件和新固件存儲(chǔ)開(kāi)銷可能很大。常見(jiàn)的做法是從舊固件分段讀取在RAM里合成新固件的對(duì)應(yīng)段然后一邊合成一邊寫入新分區(qū)從而把峰值存儲(chǔ)需求控制下來(lái)。另一個(gè)工程化重點(diǎn)是斷點(diǎn)續(xù)傳。嵌入式設(shè)備的網(wǎng)絡(luò)連接并不穩(wěn)定一個(gè)3MB的升級(jí)包如果下載到一半斷網(wǎng)只能從頭再來(lái)用戶體驗(yàn)極差。我通常在升級(jí)模塊里維護(hù)一個(gè)下載狀態(tài)結(jié)構(gòu)體記錄已接收的包序號(hào)和校驗(yàn)值在flash里單獨(dú)劃分一塊download分區(qū)保存這些信息。重新連接后直接從最后的包序號(hào)開(kāi)始繼續(xù)請(qǐng)求下載而不是重新發(fā)起整個(gè)下載流程。注意這塊download分區(qū)在升級(jí)完成前盡量不要復(fù)用防止意外斷電丟失續(xù)傳信息。4.4 升級(jí)流程的完整鏈路與回滾機(jī)制把整個(gè)OTA升級(jí)流程串起來(lái)看大概可以分成六個(gè)狀態(tài)升級(jí)檢測(cè)、固件下載、固件完整性校驗(yàn)、固件寫入、啟動(dòng)切換、回滾判斷。每個(gè)狀態(tài)都對(duì)應(yīng)著明確的代碼實(shí)現(xiàn)和異常處理邏輯。完整性校驗(yàn)這一步經(jīng)常被忽略。很多項(xiàng)目只校驗(yàn)傳輸層的CRC卻忘了對(duì)固件做完整性驗(yàn)證。正確做法是服務(wù)器在生成固件時(shí)計(jì)算整個(gè)固件的SHA256或MD5值設(shè)備下載完成后先校驗(yàn)哈希再校驗(yàn)數(shù)字簽名如果安全性要求高全部通過(guò)之后才允許寫入應(yīng)用分區(qū)。簽名機(jī)制的價(jià)值是阻止惡意固件注入即便是內(nèi)部使用的升級(jí)通道也建議至少做一層簡(jiǎn)單的簽名校驗(yàn)。啟動(dòng)切換和回滾判斷配套使用。設(shè)備從舊分區(qū)啟動(dòng)到新分區(qū)后應(yīng)用層會(huì)做自檢比如關(guān)鍵服務(wù)是否正常啟動(dòng)、外設(shè)是否能正常通信自檢通過(guò)后向狀態(tài)分區(qū)寫入“啟動(dòng)成功”標(biāo)記。如果自檢不通過(guò)應(yīng)用主動(dòng)請(qǐng)求重啟bootloader檢測(cè)到“連續(xù)N次啟動(dòng)均未確認(rèn)成功”的計(jì)數(shù)自動(dòng)回滾到舊分區(qū)。我在幾個(gè)量產(chǎn)項(xiàng)目里驗(yàn)證過(guò)這套流程穩(wěn)定得很。核心經(jīng)驗(yàn)有兩條第一狀態(tài)分區(qū)的寫入要加磨損均衡不要每次都擦寫同一個(gè)flash扇區(qū)第二回滾觸發(fā)條件要允許遠(yuǎn)程調(diào)參不同產(chǎn)品對(duì)“連續(xù)失敗幾次才算回滾”的容忍度不同參數(shù)寫死在代碼里后期會(huì)很被動(dòng)。5. 上篇課后思考題完整解析5.1 題目范圍與設(shè)計(jì)意圖每篇連載末尾我都會(huì)安排幾道思考題目的是幫助讀者檢驗(yàn)自己對(duì)內(nèi)容的理解程度。這里把上篇的課后思考題完整過(guò)一遍逐題給出解題思路和參考答案同時(shí)解釋我出這些題背后的考量——盡量讓讀者根據(jù)答案反推出題人的邏輯這樣才能做到舉一反三。上篇思考題覆蓋了三個(gè)模塊啟動(dòng)流程、故障定位、OTA設(shè)計(jì)。題目類型包含概念解釋題、代碼分析題和方案設(shè)計(jì)題。概念題側(cè)重檢驗(yàn)是否理解了“為什么這樣做”代碼題側(cè)重檢驗(yàn)?zāi)芊裾嬲x懂啟動(dòng)代碼和異常處理代碼方案題則檢驗(yàn)是否能把前面講的方法應(yīng)用到新場(chǎng)景。5.2 啟動(dòng)流程相關(guān)題目解析題目一為什么Cortex-M系列MCU的向量表第一個(gè)元素是棧頂?shù)刂范皇菑?fù)位函數(shù)的入口地址這道題看似考概念實(shí)際上在考你對(duì)CPU初始化流程本質(zhì)的理解。CPU上電后執(zhí)行的第一條指令之前必須先有一個(gè)可用棧因?yàn)镃語(yǔ)言環(huán)境依賴于棧寄存器。將棧頂?shù)刂纷鳛橄蛄勘淼谝粋€(gè)元素意味著一上電硬件就自動(dòng)把棧指針初始化好了無(wú)需任何匯編代碼干預(yù)。把復(fù)位向量放在第二個(gè)位置是因?yàn)閺?fù)位后的第一條指令通常是C環(huán)境建立的第一步但如果棧還沒(méi)準(zhǔn)備好后續(xù)任何函數(shù)調(diào)用都可能出問(wèn)題。更深一層說(shuō)這也是為了支持架構(gòu)的靈活性不同的NMI、HardFault等異常處理器只需要從向量表統(tǒng)一取地址不需要特殊指令支持。題目二RT-Thread啟動(dòng)時(shí)為什么要先關(guān)閉中斷凡是對(duì)并發(fā)編程有些經(jīng)驗(yàn)的讀者都能秒答這個(gè)問(wèn)題。啟動(dòng)過(guò)程中涉及大量全局狀態(tài)初始化——內(nèi)存池、對(duì)象容器、鏈表節(jié)點(diǎn)、定時(shí)器列表如果中斷在初始化過(guò)程中觸發(fā)并訪問(wèn)了半初始化的內(nèi)核對(duì)象系統(tǒng)狀態(tài)就會(huì)直接錯(cuò)亂。關(guān)中斷是保證初始化原子性的最樸素手段。但這里的進(jìn)階考點(diǎn)是關(guān)閉中斷的時(shí)機(jī)和恢復(fù)的時(shí)機(jī)分別在哪里RT-Thread在rtthread_startup入口處關(guān)閉中斷直到調(diào)度器啟動(dòng)時(shí)才恢復(fù)因?yàn)檎{(diào)度器啟動(dòng)本身涉及上下文切換必須在中斷開(kāi)啟的狀態(tài)下才能完成。題目三如果MCU上電后既沒(méi)有任何輸出也沒(méi)有進(jìn)入main函數(shù)你會(huì)從哪些方面排查這是一個(gè)非常實(shí)戰(zhàn)的開(kāi)放題。我給出的排查清單是分層的。第一層是供電用示波器測(cè)VDD波形是否穩(wěn)定上電過(guò)程是否有明顯的電壓跌落。第二層是時(shí)鐘晶振是否起振時(shí)鐘引腳波形是否正常如果使用的是內(nèi)部RC檢查配置是否存在不可滿足的倍頻系數(shù)。第三層是復(fù)位確認(rèn)復(fù)位引腳電平不會(huì)一直被拉低看門狗是否在上電瞬間就觸發(fā)了復(fù)位。第四層是啟動(dòng)引腳QSPI或外部NOR flash的方案需要確認(rèn)啟動(dòng)模式選擇引腳的電平是否符合預(yù)期。第五層才是代碼本身用仿真器連接查看PC寄存器的值停在哪個(gè)范圍判斷是執(zhí)行到復(fù)位向量附近還是反復(fù)復(fù)位抑或是停在硬件初始化循環(huán)里。5.3 故障定位相關(guān)題目解析題目四在Cortex-M上系統(tǒng)進(jìn)入HardFault后如何推測(cè)異常前的PC值完整的解題思路分四步。第一步讀取LR寄存器利用EXC_RETURN判斷異常前使用的是MSP還是PSP。第二步對(duì)應(yīng)地讀取MSP或PSP的值記為SP_exc。第三步從SP_exc指向的地址開(kāi)始以字為單位依次讀取R0、R1、R2、R3、R12、LR、PC、xPSR。第四步根據(jù)PC值查閱map文件或反匯編得到具體的崩潰函數(shù)根據(jù)LR值推斷調(diào)用鏈路。注意在沒(méi)有開(kāi)啟FPU的Cortex-M上異常壓棧的寄存器就這8個(gè)字順序固定如果開(kāi)啟了FPU并且使用了FPU寄存器壓棧結(jié)構(gòu)會(huì)多出S0-S15及FPSCR共18個(gè)字讀取時(shí)不能搞混。題目五在RTOS環(huán)境下如何區(qū)分“任務(wù)棧溢出”和“堆內(nèi)存泄漏”導(dǎo)致的崩潰這道題很多人答得泛泛而談。我的判斷標(biāo)準(zhǔn)是看崩潰的時(shí)間和地址特征。任務(wù)棧溢出的崩潰通常在函數(shù)調(diào)用深度突然增大時(shí)出現(xiàn)時(shí)間上有明顯的突變性而且崩潰現(xiàn)場(chǎng)保存的棧指針離任務(wù)棧邊界非常近。堆內(nèi)存泄漏的崩潰則通常是漸進(jìn)式的系統(tǒng)運(yùn)行到某個(gè)臨界點(diǎn)后內(nèi)存分配失敗或者因?yàn)閮?nèi)存碎片導(dǎo)致某次大塊分配失敗崩潰時(shí)間點(diǎn)往往是“運(yùn)行時(shí)間越久越容易崩”。實(shí)操中有一個(gè)很有效的工具組合任務(wù)棧溢出用棧魔術(shù)字掃描在空閑任務(wù)里周期性檢查每個(gè)任務(wù)棧的高水位標(biāo)記內(nèi)存泄漏則用內(nèi)存分配計(jì)數(shù)在malloc/free接口上包一層統(tǒng)計(jì)函數(shù)定期把分配總數(shù)和釋放總數(shù)打到日志里觀察差值是否在持續(xù)上漲。5.4 OTA設(shè)計(jì)相關(guān)題目解析題目六如果產(chǎn)品flash空間只夠存放一個(gè)應(yīng)用副本但你又必須支持OTA升級(jí)且保證升級(jí)失敗不磚機(jī)你會(huì)怎么設(shè)計(jì)這是一個(gè)工程權(quán)衡題沒(méi)有標(biāo)準(zhǔn)答案但有一個(gè)關(guān)鍵原則要守必須保證任意時(shí)刻都有一個(gè)可啟動(dòng)的固件副本在flash里。在只夠一個(gè)應(yīng)用副本的約束下常見(jiàn)解法是拆分方案把flash分成bootloader分區(qū)、app分區(qū)和download暫存分區(qū)。升級(jí)時(shí)先把新固件下載到download分區(qū)校驗(yàn)無(wú)誤后在升級(jí)過(guò)程中利用bootloader配合分塊或乒乓覆蓋的方式寫入app分區(qū)。更極致一點(diǎn)如果連download分區(qū)都沒(méi)有可以退化為“啟動(dòng)時(shí)代理下載”模式系統(tǒng)重啟到bootloader由bootloader直接從網(wǎng)絡(luò)接收固件寫入app分區(qū)應(yīng)用不參與固件寫入。這種模式節(jié)省空間但bootloader的邏輯復(fù)雜度和網(wǎng)絡(luò)棧開(kāi)銷會(huì)顯著上升。題目七為什么差分升級(jí)比全量升級(jí)更難做工程化差分升級(jí)的難點(diǎn)在于它不只涉及傳輸還涉及固件合成和存儲(chǔ)管理。接收差分補(bǔ)丁后設(shè)備需要同時(shí)保留舊固件、差分補(bǔ)丁和新固件至少一部分通常會(huì)把三段數(shù)據(jù)分別放在三個(gè)不同的flash區(qū)域合成過(guò)程中還要頻繁做讀取、解壓、校驗(yàn)和寫入操作。一旦某個(gè)環(huán)節(jié)的偏移量算錯(cuò)合成出來(lái)的固件就是壞的無(wú)法啟動(dòng)。所以工程上必須為差分升級(jí)加一道額外的防線合成后的新固件先完整計(jì)算一遍哈希和服務(wù)器下發(fā)的預(yù)期哈希比對(duì)通過(guò)后才允許置位啟動(dòng)標(biāo)志。這道校驗(yàn)的時(shí)間會(huì)稍微延長(zhǎng)升級(jí)時(shí)長(zhǎng)但相比變磚風(fēng)險(xiǎn)這點(diǎn)代價(jià)非常值得。6. 一些個(gè)人經(jīng)驗(yàn)與下篇預(yù)告整理完上篇這幾塊內(nèi)容我自己也把整個(gè)知識(shí)體系重新過(guò)了一遍。啟動(dòng)流程、故障定位、OTA升級(jí)這三個(gè)話題單獨(dú)拿出來(lái)每一個(gè)都是一門課的分量但真正把它們串起來(lái)之后你會(huì)發(fā)現(xiàn)它們彼此是咬合的。啟動(dòng)流程是底層地基故障定位是用來(lái)填坑的工具箱OTA則是把這兩個(gè)能力產(chǎn)品化的載體。從實(shí)際帶項(xiàng)目和新手輔導(dǎo)的角度我給讀者三個(gè)建議。第一不要滿足于“能在IDE里編譯運(yùn)行”?；ㄒ粋€(gè)下午把鏈接腳本從頭到尾看一遍把你用到的芯片的啟動(dòng)文件逐行注釋一遍收獲遠(yuǎn)比看十篇使用教程大。第二趁早建立一套自己的“崩潰現(xiàn)場(chǎng)捕獲”工具鏈無(wú)論是串口打印還是環(huán)形日志一定要讓系統(tǒng)在出問(wèn)題時(shí)留下足夠多可以回溯的信息。項(xiàng)目到后期能不能快速定位問(wèn)題拼的就是這套基礎(chǔ)設(shè)施。第三OTA升級(jí)別等項(xiàng)目快量產(chǎn)了才做方案在固件設(shè)計(jì)的第一天就要想好分區(qū)方案和升級(jí)接口。下篇我會(huì)重點(diǎn)拆解兩個(gè)實(shí)戰(zhàn)場(chǎng)景一是基于RT-Thread平臺(tái)上完整實(shí)現(xiàn)一套帶A/B分區(qū)和回滾機(jī)制的OTA組件二是用一個(gè)線上故障的真實(shí)案例展示從串口日志到最終定位的全過(guò)程排查思路。同時(shí)會(huì)把下篇的思考題設(shè)計(jì)得更靠近工程實(shí)踐讓讀者真的有“動(dòng)手做一遍”的沖動(dòng)。最后再分享一個(gè)小技巧。在啟動(dòng)代碼里加上這個(gè)信息打印后續(xù)很多問(wèn)題的排查會(huì)省掉一半力氣void show_boot_info(void) { rt_kprintf(\n); rt_kprintf(Firmware Version: %s\n, FW_VERSION); rt_kprintf(Built Time: %s %s\n, __DATE__, __TIME__); rt_kprintf(Boot Reason: %d\n, get_boot_reason()); rt_kprintf(Last Reset Cause: %d\n, get_reset_cause()); rt_kprintf(\n); }打印編譯時(shí)間和版本號(hào)的目的是防止現(xiàn)場(chǎng)設(shè)備與代碼版本對(duì)不上號(hào)打印復(fù)位原因則能快速分辨是上電復(fù)位、看門狗復(fù)位還是軟件復(fù)位——這個(gè)信息在遠(yuǎn)程診斷時(shí)幾乎必查。把這些基礎(chǔ)觀測(cè)手段做扎實(shí)比任何“萬(wàn)能調(diào)試大法”都管用。很多時(shí)候嵌入式開(kāi)發(fā)拼的不是破解疑難雜癥的靈光一現(xiàn)而是把基礎(chǔ)工作做到位之后疑難雜癥自然變少了。 嵌入式固件進(jìn)階：?jiǎn)?dòng)流程、故障定位與OTA升級(jí)實(shí)戰(zhàn)指南
1. 為什么嵌入式固件越來(lái)越需要“進(jìn)階”思維先說(shuō)個(gè)我在技術(shù)社區(qū)里觀察到的現(xiàn)象。這幾年嵌入式崗位的要求變化非常明顯五年前會(huì)配置個(gè)寄存器、能點(diǎn)個(gè)燈、調(diào)通個(gè)UART基本就能應(yīng)付大部分工作?，F(xiàn)在再去招聘網(wǎng)站上看但凡薪資過(guò)得去的嵌入式崗位幾乎都寫著一行字熟悉固件啟動(dòng)流程有OTA升級(jí)實(shí)踐經(jīng)驗(yàn)具備獨(dú)立定位復(fù)雜嵌入式問(wèn)題的能力。門檻為什么抬高了因?yàn)楫a(chǎn)品形態(tài)變了。早期單片機(jī)項(xiàng)目大多是單機(jī)運(yùn)行的裸機(jī)程序代碼量撐死幾十KB跑飛了大不了復(fù)位重啟?，F(xiàn)在的嵌入式設(shè)備呢云連接是標(biāo)配遠(yuǎn)程升級(jí)是剛需MCU RTOS甚至MCU Linux SoC的異構(gòu)架構(gòu)越來(lái)越普遍。固件動(dòng)不動(dòng)幾MB要是啟動(dòng)流程沒(méi)搞清楚、故障定位靠瞎猜、OTA升級(jí)沒(méi)有回滾策略產(chǎn)品出廠就是災(zāi)難現(xiàn)場(chǎng)。另一個(gè)讓我印象深刻的點(diǎn)是很多工程師不是不努力而是學(xué)習(xí)路徑太散。今天看一篇裸機(jī)配置教程明天刷一段Linux驅(qū)動(dòng)分析后天翻到一個(gè)UBoot啟動(dòng)流程的帖子知識(shí)碎片化嚴(yán)重遇到實(shí)際問(wèn)題很難快速串起來(lái)。尤其是啟動(dòng)流程、故障定位、OTA升級(jí)這三個(gè)方向教科書(shū)上不會(huì)系統(tǒng)講日常工作里又沒(méi)法系統(tǒng)性總結(jié)屬于典型的“實(shí)踐中才能長(zhǎng)出來(lái)的經(jīng)驗(yàn)”。我寫這個(gè)連載專欄的初衷很簡(jiǎn)單把嵌入式固件進(jìn)階路上最硬核、最繞不開(kāi)的三個(gè)主題——啟動(dòng)流程深度拆解、故障定位方法論、OTA升級(jí)工程化實(shí)戰(zhàn)——串成一條完整的知識(shí)鏈配合課后思考題的完整解析讓讀者真正理解底層機(jī)制而不是停留在“能跑就行”的層面。這篇文章不整虛的我把專欄上篇的精華邏輯和核心思路整理出來(lái)相當(dāng)于給沒(méi)來(lái)得及訂閱的朋友做一次深度導(dǎo)覽。內(nèi)容包括MCU和SoC兩條啟動(dòng)路徑的完整拆解、RT-Thread啟動(dòng)初始化流程的逐步走讀、故障定位的系統(tǒng)化方法論、OTA升級(jí)工程化的分區(qū)策略和回滾機(jī)制以及上篇課后思考題的逐題解析。適合想進(jìn)階的嵌入式工程師、剛轉(zhuǎn)行做固件開(kāi)發(fā)的朋友以及正在準(zhǔn)備嵌入式面試的求職者。2. 啟動(dòng)流程深度拆解MCU與SoC的兩條路徑2.1 從復(fù)位向量到C main之間發(fā)生了什么很多人寫嵌入式代碼寫了三四年問(wèn)一個(gè)問(wèn)題芯片上電復(fù)位后第一條指令到底是從哪里取出來(lái)的回答得清楚的人不足三成。這不怪大家因?yàn)楝F(xiàn)代開(kāi)發(fā)環(huán)境把這段過(guò)程幾乎完全隱藏了編譯器、鏈接腳本、啟動(dòng)文件一條龍服務(wù)IDE里點(diǎn)一下編譯下載程序就跑起來(lái)了。但對(duì)固件進(jìn)階來(lái)說(shuō)這塊必須吃透因?yàn)樗鼪Q定了你對(duì)整個(gè)系統(tǒng)的掌控力。先說(shuō)MCU這條路徑最典型的比如STM32系列。芯片上電之后硬件邏輯會(huì)自動(dòng)從存儲(chǔ)器的起始地址讀取兩個(gè)關(guān)鍵值初始棧指針MSP和復(fù)位向量。注意這里的核心機(jī)制是地址0x00000000處存放棧頂?shù)刂返刂?x00000004處存放復(fù)位中斷服務(wù)程序的入口地址。這個(gè)布局不是任意約定的而是在Cortex-M架構(gòu)設(shè)計(jì)時(shí)就確定好的。CPU拿到復(fù)位向量后跳轉(zhuǎn)到SystemInit或者Reset_Handler執(zhí)行。先從啟動(dòng)文件startup_stm32xxx.s說(shuō)起這一段匯編做的事情包括三個(gè)部分設(shè)置初始棧指針、調(diào)用SystemInit進(jìn)行時(shí)鐘配置、然后調(diào)用C庫(kù)的初始化函數(shù)如__main完成數(shù)據(jù)段和BSS段的搬運(yùn)清零最終才跳到用戶的main函數(shù)。這里面最容易忽略但極為關(guān)鍵的細(xì)節(jié)是數(shù)據(jù)段的搬運(yùn)。編譯產(chǎn)物里初始化的全局變量初始值默認(rèn)存放在flash的只讀區(qū)域LOAD區(qū)程序運(yùn)行時(shí)需要這些變量存在于RAM中RUN區(qū)。啟動(dòng)代碼的核心任務(wù)之一就是把這部分?jǐn)?shù)據(jù)從flash拷貝到RAM這個(gè)操作在啟動(dòng)文件里通常寫作一個(gè)循環(huán)按字32位為單位搬運(yùn)還要處理邊界不對(duì)齊的情況。2.2 RT-Thread啟動(dòng)初始化流程走讀前面說(shuō)的還是裸機(jī)環(huán)境。如果用RT-Thread這類RTOS啟動(dòng)流程會(huì)再多出幾層關(guān)鍵邏輯。很多初學(xué)者第一次接觸RT-Thread時(shí)會(huì)有個(gè)困惑明明代碼里寫的是main函數(shù)入口為什么運(yùn)行起來(lái)后系統(tǒng)線程就已經(jīng)在跑了這就涉及到RT-Thread的啟動(dòng)初始化順序。RT-Thread的啟動(dòng)可以分為兩個(gè)階段。第一階段是從匯編Reset_Handler到C環(huán)境的main函數(shù)這跟裸機(jī)路徑類似。第二階段是從main函數(shù)里調(diào)用rtthread_startup()完成系統(tǒng)的全面初始化。具體來(lái)說(shuō)rtthread_startup的執(zhí)行流程大致是int rtthread_startup(void) { rt_hw_interrupt_disable(); /* 板級(jí)初始化必需。初始化系統(tǒng)滴答時(shí)鐘、引腳、串口等底層硬件 */ rt_hw_board_init(); /* 打印RT-Thread版本信息 */ rt_show_version(); /* 定時(shí)器線程初始化 */ rt_system_timer_init(); /* 調(diào)度器初始化必需 */ rt_system_scheduler_init(); /* 信號(hào)量、互斥量等內(nèi)核對(duì)象初始化 */ rt_system_sem_init(); /* 創(chuàng)建主線程 */ rt_application_init(); /* 定時(shí)器線程啟動(dòng) */ rt_system_timer_thread_init(); /* 空閑線程初始化 */ rt_thread_idle_init(); /* 啟動(dòng)調(diào)度器不再返回 */ rt_system_scheduler_start(); }注意觀察這個(gè)順序背后的邏輯。中斷最先被關(guān)閉是為了保證初始化過(guò)程的原子性板級(jí)初始化必須在系統(tǒng)初始化之前因?yàn)閮?nèi)核對(duì)象的創(chuàng)建很多依賴時(shí)鐘和內(nèi)存基礎(chǔ)調(diào)度器的初始化要先于線程的創(chuàng)建但調(diào)度器的啟動(dòng)必須在所有初始化完成后。有個(gè)細(xì)節(jié)值得單獨(dú)提出來(lái)rt_hw_board_init里會(huì)調(diào)用rt_hw_clock_init配置系統(tǒng)時(shí)鐘調(diào)用rt_hw_console_init初始化控制臺(tái)輸出。如果你在調(diào)試時(shí)發(fā)現(xiàn)串口沒(méi)有輸出第一步就該查這兩個(gè)函數(shù)的執(zhí)行情況。我在實(shí)際項(xiàng)目里遇到過(guò)一例板級(jí)初始化卡死在等待外部晶振穩(wěn)定的循環(huán)里導(dǎo)致系統(tǒng)完全無(wú)法啟動(dòng)這類問(wèn)題靠串口調(diào)試根本看不到線索只能從啟動(dòng)流程的時(shí)序推理入手。RT-Thread還提供了一種組件初始化機(jī)制使用INIT_BOARD_EXPORT、INIT_APP_EXPORT等宏將初始化函數(shù)按優(yōu)先級(jí)自動(dòng)注冊(cè)。這種方式讓驅(qū)動(dòng)和應(yīng)用的初始化代碼可以分散在各文件中可維護(hù)性更好但對(duì)啟動(dòng)順序的理解要求也更高。默認(rèn)的優(yōu)先級(jí)順序是板級(jí)初始化→組件初始化→內(nèi)核初始化→應(yīng)用初始化理解這個(gè)鏈路是排查“驅(qū)動(dòng)程序沒(méi)生效”類問(wèn)題的基本功。2.3 SoC與UBoot從Boot ROM到內(nèi)核啟動(dòng)講完MCU再看SoC這條路徑典型代表是各種應(yīng)用處理器平臺(tái)。這類芯片的啟動(dòng)流程比MCU復(fù)雜得多一般分為Boot ROM、Bootloader、內(nèi)核三個(gè)階段。Boot ROM是芯片出廠時(shí)固化在片內(nèi)ROM里的一段程序不可修改它的職責(zé)是初始化最基本的外設(shè)比如存儲(chǔ)控制器、時(shí)鐘然后根據(jù)啟動(dòng)引腳的電平配置從指定介質(zhì)加載第一段可執(zhí)行代碼。這里說(shuō)的第一段可執(zhí)行代碼通常就是SPLSecondary Program Loader或ARM Trusted Firmware中的BL2它們會(huì)進(jìn)一步初始化DRAM、串口、MMU等關(guān)鍵外設(shè)然后把真正的UBoot加載到內(nèi)存中運(yùn)行。UBoot完整起來(lái)之后才是大家比較熟悉的操作讀取環(huán)境變量、加載內(nèi)核鏡像到內(nèi)存、設(shè)置啟動(dòng)參數(shù)、跳轉(zhuǎn)執(zhí)行。UBoot的啟動(dòng)流程如果細(xì)拆大概是這個(gè)脈絡(luò)入口函數(shù)board_init_f完成CPU、板級(jí)、DRAM等基礎(chǔ)初始化將代碼重定位到RAM中執(zhí)行board_init_r在RAM中繼續(xù)完成剩下的外設(shè)初始化如網(wǎng)卡、USB、存儲(chǔ)設(shè)備驅(qū)動(dòng)解析bootcmd環(huán)境變量根據(jù)命令行的配置找到內(nèi)核鏡像調(diào)用bootm命令或booti命令搬運(yùn)內(nèi)核鏡像到指定地址將設(shè)備樹(shù)地址、initrd地址、啟動(dòng)參數(shù)地址設(shè)置好后跳轉(zhuǎn)到內(nèi)核入口SoC啟動(dòng)和MCU啟動(dòng)最大的思維差異在于MCU通常直接從內(nèi)部flash取指執(zhí)行而SoC經(jīng)歷了“從外部介質(zhì)加載—搬到內(nèi)存—從內(nèi)存啟動(dòng)”的多次搬運(yùn)過(guò)程每一次搬運(yùn)失敗都會(huì)導(dǎo)致啟動(dòng)停留在某個(gè)不可預(yù)期的狀態(tài)。排查這類問(wèn)題一個(gè)燒錄了完整啟動(dòng)日志的系統(tǒng)串口遠(yuǎn)比仿真器好用串口輸出能讓你快速定位系統(tǒng)到底卡在哪個(gè)階段。關(guān)于RT-Thread和MCU/SoC的啟動(dòng)過(guò)程網(wǎng)上有很多零散的教程但大多只講“怎么配”不講“為什么這么配”。我在專欄里花了大篇幅把這層機(jī)制補(bǔ)上因?yàn)闄C(jī)制不通看再多配置教程也是照貓畫(huà)虎換個(gè)芯片型號(hào)就抓瞎。3. 故障定位方法論從“瞎猜”到“系統(tǒng)排查”3.1 為什么你定位Bug總是靠運(yùn)氣嵌入式開(kāi)發(fā)里有個(gè)很常見(jiàn)的畫(huà)面程序偶發(fā)崩潰工程師開(kāi)始懷疑這懷疑那——掉電檢測(cè)不對(duì)、看門狗配置錯(cuò)誤、某個(gè)中斷優(yōu)先級(jí)太低、編譯器優(yōu)化等級(jí)太高……然后給代碼里到處加打印跑了一整天復(fù)現(xiàn)不到實(shí)在沒(méi)辦法就重啟一下碰碰運(yùn)氣。這種靠運(yùn)氣的排查方式有個(gè)共性問(wèn)題沒(méi)有建立系統(tǒng)化的排查鏈路。高效率的故障定位本質(zhì)上是“通過(guò)可觀測(cè)信息縮小問(wèn)題范圍并利用運(yùn)行機(jī)制指導(dǎo)排查方向”的迭代過(guò)程。它分成固定的步驟收集上下文集→提出多個(gè)假設(shè)→設(shè)計(jì)關(guān)鍵實(shí)驗(yàn)驗(yàn)證假設(shè)→收斂到根因→驗(yàn)證修復(fù)方案。我先說(shuō)一個(gè)真實(shí)案例。有次幫朋友排查一個(gè)產(chǎn)品問(wèn)題設(shè)備運(yùn)行幾小時(shí)后偶發(fā)死機(jī)復(fù)位后短時(shí)間正常過(guò)段時(shí)間又復(fù)發(fā)。第一次接手時(shí)的排查進(jìn)展很慢因?yàn)閺?fù)現(xiàn)周期太長(zhǎng)。后來(lái)決定先收集數(shù)據(jù)而非直接修代碼在系統(tǒng)死機(jī)前讓調(diào)試串口持續(xù)輸出內(nèi)存使用率和任務(wù)調(diào)度計(jì)數(shù)的快照發(fā)現(xiàn)每次死機(jī)前幾分鐘堆內(nèi)存的使用率都在穩(wěn)定攀升直到接近峰值后系統(tǒng)異常。問(wèn)題很快被鎖定為內(nèi)存泄漏——不是硬件問(wèn)題不是時(shí)鐘問(wèn)題是某個(gè)消息隊(duì)列的節(jié)點(diǎn)反復(fù)申請(qǐng)但不釋放。這個(gè)案例告訴我們定位問(wèn)題的第一步永遠(yuǎn)是收集數(shù)據(jù)而不是修改代碼。數(shù)據(jù)收集的渠道包括串口日志、運(yùn)行時(shí)統(tǒng)計(jì)信息、崩潰時(shí)的寄存器快照甚至是外置邏輯分析儀的時(shí)序數(shù)據(jù)。數(shù)據(jù)越完整假設(shè)空間的縮小速度越快。3.2 HardFault_HandlerCortex-M工程師最熟悉又最陌生的朋友嵌入式固件開(kāi)發(fā)里Cortex-M內(nèi)核的HardFault異?？赡苁怯龅竭^(guò)最多、也最讓新人恐懼的報(bào)錯(cuò)。程序跑著跑著突然進(jìn)了HardFault_Handler反匯編窗口一片亂碼call stack識(shí)別不出來(lái)除了復(fù)位不知道還能干嘛。HardFault的定位其實(shí)有標(biāo)準(zhǔn)流程核心是記住發(fā)生異常時(shí)核心會(huì)自動(dòng)把一組寄存器壓棧包括R0、R1、R2、R3、R12、LR、PC、xPSR。這組寄存器存儲(chǔ)在當(dāng)前的棧指針MSP或PSP指向的內(nèi)存區(qū)域。拿到崩潰現(xiàn)場(chǎng)后關(guān)鍵在于還原兩個(gè)信息程序是從哪條指令崩的PC以及是從哪個(gè)調(diào)用點(diǎn)進(jìn)去的LR。實(shí)際排查時(shí)我習(xí)慣先看LR寄存器的值。Cortex-M的LR在進(jìn)入異常時(shí)會(huì)被設(shè)置成一個(gè)特殊值EXC_RETURN通過(guò)判別這個(gè)值的bit位可以知道異常前使用的是MSP還是PSP進(jìn)而找到正確的棧指針。然后根據(jù)棧指針地址從內(nèi)存里逆序讀出壓棧的寄存器組。這里有個(gè)實(shí)操技巧在HardFault_Handler里加一小段匯編直接讀取棧指針并保存到全局變量__asm void hard_fault_get_sp(void) { MOV R0, SP LDR R1, hard_fault_sp STR R0, [R1] BX LR } void HardFault_Handler(void) { hard_fault_get_sp(); /* 在這里把hard_fault_sp指向的寄存器組打印出來(lái) */ }拿到PC和LR之后打開(kāi)map文件或者反匯編文件找到這兩個(gè)地址對(duì)應(yīng)的函數(shù)崩潰的位置基本就水落石出了。注意不要指望編譯器的call stack窗口能自動(dòng)識(shí)別因?yàn)閮?yōu)化后的代碼經(jīng)常沒(méi)有幀指針常規(guī)的?；厮菟惴〞?huì)失效。還有個(gè)容易被忽略的點(diǎn)就是總線錯(cuò)誤BusFault和用法錯(cuò)誤UsageFault。很多時(shí)候HardFault只是最終結(jié)果真正的異常來(lái)源是其它Fault。建議在啟動(dòng)階段就把三個(gè)Fault的優(yōu)先級(jí)配置好同時(shí)把UsageFault里的除零錯(cuò)誤、未對(duì)齊訪問(wèn)等檢測(cè)位打開(kāi)這樣崩潰時(shí)可以直接進(jìn)入對(duì)應(yīng)的Handler打印出的信息比單純一個(gè)HardFault精確得多。3.3 可觀測(cè)性建設(shè)日志分級(jí)與運(yùn)行時(shí)追蹤要真正擺脫“故障靠猜”必須在產(chǎn)品設(shè)計(jì)階段就把可觀測(cè)性考慮進(jìn)去。嵌入式環(huán)境相比服務(wù)器后端一個(gè)天然劣勢(shì)是日志資源極其有限內(nèi)存可能只有幾十KBflash空間也緊張沒(méi)法像云服務(wù)那樣搞一套完整日志中臺(tái)。但再有限也有分級(jí)分層的做法。我常用的日志方案是優(yōu)先級(jí)分級(jí)。ERROR級(jí)別必須實(shí)時(shí)打印因?yàn)槟鞘切枰⒓醋⒁獾漠惓ARNING級(jí)別可以緩沖輸出不影響主線運(yùn)行INFO級(jí)別默認(rèn)關(guān)閉通過(guò)編譯開(kāi)關(guān)或運(yùn)行時(shí)控制塊動(dòng)態(tài)開(kāi)啟DEBUG級(jí)別只在調(diào)試版本啟用。這套分級(jí)聽(tīng)著簡(jiǎn)單實(shí)際落地時(shí)很多人會(huì)搞混“詳情”和“關(guān)鍵信息”恨不得把所有變量都打印出來(lái)結(jié)果串口被日志淹沒(méi)真正有價(jià)值的現(xiàn)場(chǎng)信息反而被沖掉了。運(yùn)行時(shí)追蹤做得好也能大幅提升故障定位效率。一個(gè)相對(duì)輕量的方式是使用周期計(jì)數(shù)器DWT-CYCCNT記錄關(guān)鍵函數(shù)的執(zhí)行時(shí)間超時(shí)自動(dòng)打點(diǎn)不用額外引入邏輯分析儀就能評(píng)估某些時(shí)序問(wèn)題。另一個(gè)被很多團(tuán)隊(duì)使用的方案是環(huán)形緩沖區(qū)的崩潰日志存儲(chǔ)把最近的日志寫到專用的flash分區(qū)系統(tǒng)復(fù)位后上電讀取最后一段日志能直接看到崩潰前最后執(zhí)行的操作。比起串口長(zhǎng)時(shí)間掛機(jī)抓日志這個(gè)方法對(duì)偶發(fā)問(wèn)題的捕獲率明顯更高。3.4 RTOS環(huán)境下死機(jī)問(wèn)題的排查重點(diǎn)這里單獨(dú)提一下RTOS環(huán)境。上了RTOS之后故障排查的維度又多了幾個(gè)常見(jiàn)的坑包括任務(wù)棧溢出、中斷里調(diào)用非中斷安全API、優(yōu)先級(jí)反轉(zhuǎn)導(dǎo)致的死鎖、設(shè)備驅(qū)動(dòng)和任務(wù)的競(jìng)態(tài)條件。任務(wù)棧溢出是最常見(jiàn)的。RT-Thread提供了鉤子函數(shù)檢查棧溢出在任務(wù)切換時(shí)比較任務(wù)棧的當(dāng)前水位和棧頂標(biāo)記一旦檢測(cè)到溢出就觸發(fā)鉤子回調(diào)。配置方式是rt_thread_init(thread, task1, task1_entry, RT_NULL, stack_start, stack_size, PRIORITY, TICK); #ifdef RT_USING_HOOK rt_thread_setscheduler_hook(stack_overflow_hook); #endif實(shí)際項(xiàng)目里我還會(huì)在任務(wù)棧的尾部填一個(gè)固定的魔術(shù)字0xA5A5A5A5在系統(tǒng)空閑時(shí)掃描所有任務(wù)棧的魔術(shù)字是否被破壞。這個(gè)方法比依賴RTOS自帶的棧檢查更主動(dòng)能夠更早地發(fā)現(xiàn)“即將溢出但還沒(méi)到檢測(cè)點(diǎn)”的危險(xiǎn)狀態(tài)。中斷上下文里調(diào)用危險(xiǎn)API的問(wèn)題排查起來(lái)更隱蔽。某次客戶反饋設(shè)備在極端工況下偶發(fā)死鎖代碼審查沒(méi)發(fā)現(xiàn)問(wèn)題后來(lái)通過(guò)在IRQHandler入口和出口分別置位某個(gè)GPIO用示波器測(cè)量GPIO的時(shí)序發(fā)現(xiàn)一個(gè)定時(shí)器中斷的執(zhí)行時(shí)間異常拉長(zhǎng)——糟糕的是這個(gè)中斷服務(wù)函數(shù)內(nèi)部調(diào)用了rt_thread_mdelay導(dǎo)致調(diào)度器狀態(tài)錯(cuò)亂。這種問(wèn)題日志幾乎看不出來(lái)必須靠時(shí)序測(cè)量和代碼走讀結(jié)合。4. OTA升級(jí)工程化實(shí)戰(zhàn)分區(qū)、差分包與回滾4.1 在線升級(jí)的本質(zhì)不是“寫flash”而是“管理風(fēng)險(xiǎn)”O(jiān)TA升級(jí)是嵌入式產(chǎn)品由“工程樣品”走向“量產(chǎn)設(shè)備”的一道分水嶺。帶OTA功能的產(chǎn)品意味著你可以在設(shè)備售出之后繼續(xù)修復(fù)bug、迭代功能但也意味著你有了新的“翻車”方式——升級(jí)程序本身出問(wèn)題把設(shè)備變磚。我見(jiàn)過(guò)很多團(tuán)隊(duì)的第一版OTA方案做得相當(dāng)簡(jiǎn)單粗暴在應(yīng)用里接收升級(jí)包直接擦除當(dāng)前應(yīng)用分區(qū)寫入新固件然后跳轉(zhuǎn)重啟。這種方案有個(gè)致命問(wèn)題一旦寫flash過(guò)程中掉電、寫入了損壞的數(shù)據(jù)、或者新固件本身有bug導(dǎo)致系統(tǒng)無(wú)法啟動(dòng)設(shè)備就徹底變成了一塊磚頭只能返廠燒錄。OTA工程化的核心本質(zhì)其實(shí)是風(fēng)險(xiǎn)控制不是單純的程序搬運(yùn)。設(shè)計(jì)一個(gè)合格的OTA系統(tǒng)至少要覆蓋三個(gè)場(chǎng)景下載中斷能不能續(xù)傳、升級(jí)失敗能不能回滾、升級(jí)過(guò)程中設(shè)備意外斷電會(huì)不會(huì)損壞。這三個(gè)問(wèn)題每一個(gè)都對(duì)應(yīng)一套具體的設(shè)計(jì)策略。4.2 分區(qū)表設(shè)計(jì)A/B分區(qū)與recovery分區(qū)之爭(zhēng)分區(qū)設(shè)計(jì)是整個(gè)OTA升級(jí)的基石。目前主流的方案有兩種一種是A/B系統(tǒng)分區(qū)方案另一種是recovery模式方案。A/B方案也叫雙分區(qū)方案思路很簡(jiǎn)單把應(yīng)用分區(qū)分成A和B兩個(gè)槽位系統(tǒng)從一個(gè)槽位啟動(dòng)升級(jí)時(shí)寫入另一個(gè)槽位寫入成功后更新啟動(dòng)標(biāo)志重啟后bootloader從新槽位啟動(dòng)。這樣天然解決了回滾問(wèn)題如果新槽位啟動(dòng)失敗bootloader可以自動(dòng)切換到舊槽位啟動(dòng)。A/B方案對(duì)硬件的要求是flash空間多出一倍在存儲(chǔ)容量緊張的低成本MCU上實(shí)施有一定難度。recovery方案則是在flash里劃分一個(gè)獨(dú)立的recovery分區(qū)專門用來(lái)存放升級(jí)邏輯。主應(yīng)用升級(jí)時(shí)先寫入recovery分區(qū)然后重啟進(jìn)入recovery模式由recovery程序負(fù)責(zé)把新應(yīng)用寫入主分區(qū)。這種方案節(jié)省空間但回滾邏輯復(fù)雜一些需要recovery程序本身足夠健壯。我自己的經(jīng)驗(yàn)是flash容量在2MB以下的MCU產(chǎn)品優(yōu)先考慮recovery方案把recovery程序做得足夠精簡(jiǎn)穩(wěn)定flash容量充足的產(chǎn)品直接上A/B分區(qū)回滾邏輯簡(jiǎn)單可靠長(zhǎng)期維護(hù)成本最低。還有一個(gè)很多教程不會(huì)提的細(xì)節(jié)無(wú)論哪種方案都要在分區(qū)表里預(yù)留一個(gè)專門存放“啟動(dòng)狀態(tài)標(biāo)志”的區(qū)域。每次啟動(dòng)時(shí)bootloader先讀取這個(gè)區(qū)域的標(biāo)志值決定從哪個(gè)分區(qū)啟動(dòng)應(yīng)用正常運(yùn)行后將狀態(tài)標(biāo)志更新為“上次啟動(dòng)成功”。如果因?yàn)槌绦虮罎⒒蛘咝掳姹井惓?dǎo)致系統(tǒng)反復(fù)復(fù)位bootloader就能檢測(cè)到“連續(xù)啟動(dòng)失敗”的情況自動(dòng)觸發(fā)回滾。4.3 差分包生成與斷點(diǎn)續(xù)傳思路OTA升級(jí)要面對(duì)的現(xiàn)實(shí)約束是網(wǎng)絡(luò)帶寬和流量成本。設(shè)備可能通過(guò)2G/4G模塊甚至NB-IoT聯(lián)網(wǎng)單次傳輸幾十MB的全量升級(jí)包顯然不現(xiàn)實(shí)。差分包是更務(wù)實(shí)的選擇。差分包的基本原理是在升級(jí)服務(wù)器端用舊的固件版本作為基礎(chǔ)版本生成與新版固件之間的差異補(bǔ)丁比如使用bsdiff算法設(shè)備端只需要下載這個(gè)差異補(bǔ)丁通過(guò)逆向差分算法將本地固件與補(bǔ)丁合成新固件。差分包通常比全量包小80%以上在低帶寬高延遲的嵌入式網(wǎng)絡(luò)環(huán)境下優(yōu)勢(shì)明顯。設(shè)備端實(shí)現(xiàn)差分合成時(shí)有個(gè)關(guān)鍵注意點(diǎn)需要注意存儲(chǔ)空間。合成過(guò)程通常需要同時(shí)保留舊固件、補(bǔ)丁文件和新固件存儲(chǔ)開(kāi)銷可能很大。常見(jiàn)的做法是從舊固件分段讀取在RAM里合成新固件的對(duì)應(yīng)段然后一邊合成一邊寫入新分區(qū)從而把峰值存儲(chǔ)需求控制下來(lái)。另一個(gè)工程化重點(diǎn)是斷點(diǎn)續(xù)傳。嵌入式設(shè)備的網(wǎng)絡(luò)連接并不穩(wěn)定一個(gè)3MB的升級(jí)包如果下載到一半斷網(wǎng)只能從頭再來(lái)用戶體驗(yàn)極差。我通常在升級(jí)模塊里維護(hù)一個(gè)下載狀態(tài)結(jié)構(gòu)體記錄已接收的包序號(hào)和校驗(yàn)值在flash里單獨(dú)劃分一塊download分區(qū)保存這些信息。重新連接后直接從最后的包序號(hào)開(kāi)始繼續(xù)請(qǐng)求下載而不是重新發(fā)起整個(gè)下載流程。注意這塊download分區(qū)在升級(jí)完成前盡量不要復(fù)用防止意外斷電丟失續(xù)傳信息。4.4 升級(jí)流程的完整鏈路與回滾機(jī)制把整個(gè)OTA升級(jí)流程串起來(lái)看大概可以分成六個(gè)狀態(tài)升級(jí)檢測(cè)、固件下載、固件完整性校驗(yàn)、固件寫入、啟動(dòng)切換、回滾判斷。每個(gè)狀態(tài)都對(duì)應(yīng)著明確的代碼實(shí)現(xiàn)和異常處理邏輯。完整性校驗(yàn)這一步經(jīng)常被忽略。很多項(xiàng)目只校驗(yàn)傳輸層的CRC卻忘了對(duì)固件做完整性驗(yàn)證。正確做法是服務(wù)器在生成固件時(shí)計(jì)算整個(gè)固件的SHA256或MD5值設(shè)備下載完成后先校驗(yàn)哈希再校驗(yàn)數(shù)字簽名如果安全性要求高全部通過(guò)之后才允許寫入應(yīng)用分區(qū)。簽名機(jī)制的價(jià)值是阻止惡意固件注入即便是內(nèi)部使用的升級(jí)通道也建議至少做一層簡(jiǎn)單的簽名校驗(yàn)。啟動(dòng)切換和回滾判斷配套使用。設(shè)備從舊分區(qū)啟動(dòng)到新分區(qū)后應(yīng)用層會(huì)做自檢比如關(guān)鍵服務(wù)是否正常啟動(dòng)、外設(shè)是否能正常通信自檢通過(guò)后向狀態(tài)分區(qū)寫入“啟動(dòng)成功”標(biāo)記。如果自檢不通過(guò)應(yīng)用主動(dòng)請(qǐng)求重啟bootloader檢測(cè)到“連續(xù)N次啟動(dòng)均未確認(rèn)成功”的計(jì)數(shù)自動(dòng)回滾到舊分區(qū)。我在幾個(gè)量產(chǎn)項(xiàng)目里驗(yàn)證過(guò)這套流程穩(wěn)定得很。核心經(jīng)驗(yàn)有兩條第一狀態(tài)分區(qū)的寫入要加磨損均衡不要每次都擦寫同一個(gè)flash扇區(qū)第二回滾觸發(fā)條件要允許遠(yuǎn)程調(diào)參不同產(chǎn)品對(duì)“連續(xù)失敗幾次才算回滾”的容忍度不同參數(shù)寫死在代碼里后期會(huì)很被動(dòng)。5. 上篇課后思考題完整解析5.1 題目范圍與設(shè)計(jì)意圖每篇連載末尾我都會(huì)安排幾道思考題目的是幫助讀者檢驗(yàn)自己對(duì)內(nèi)容的理解程度。這里把上篇的課后思考題完整過(guò)一遍逐題給出解題思路和參考答案同時(shí)解釋我出這些題背后的考量——盡量讓讀者根據(jù)答案反推出題人的邏輯這樣才能做到舉一反三。上篇思考題覆蓋了三個(gè)模塊啟動(dòng)流程、故障定位、OTA設(shè)計(jì)。題目類型包含概念解釋題、代碼分析題和方案設(shè)計(jì)題。概念題側(cè)重檢驗(yàn)是否理解了“為什么這樣做”代碼題側(cè)重檢驗(yàn)?zāi)芊裾嬲x懂啟動(dòng)代碼和異常處理代碼方案題則檢驗(yàn)是否能把前面講的方法應(yīng)用到新場(chǎng)景。5.2 啟動(dòng)流程相關(guān)題目解析題目一為什么Cortex-M系列MCU的向量表第一個(gè)元素是棧頂?shù)刂范皇菑?fù)位函數(shù)的入口地址這道題看似考概念實(shí)際上在考你對(duì)CPU初始化流程本質(zhì)的理解。CPU上電后執(zhí)行的第一條指令之前必須先有一個(gè)可用棧因?yàn)镃語(yǔ)言環(huán)境依賴于棧寄存器。將棧頂?shù)刂纷鳛橄蛄勘淼谝粋€(gè)元素意味著一上電硬件就自動(dòng)把棧指針初始化好了無(wú)需任何匯編代碼干預(yù)。把復(fù)位向量放在第二個(gè)位置是因?yàn)閺?fù)位后的第一條指令通常是C環(huán)境建立的第一步但如果棧還沒(méi)準(zhǔn)備好后續(xù)任何函數(shù)調(diào)用都可能出問(wèn)題。更深一層說(shuō)這也是為了支持架構(gòu)的靈活性不同的NMI、HardFault等異常處理器只需要從向量表統(tǒng)一取地址不需要特殊指令支持。題目二RT-Thread啟動(dòng)時(shí)為什么要先關(guān)閉中斷凡是對(duì)并發(fā)編程有些經(jīng)驗(yàn)的讀者都能秒答這個(gè)問(wèn)題。啟動(dòng)過(guò)程中涉及大量全局狀態(tài)初始化——內(nèi)存池、對(duì)象容器、鏈表節(jié)點(diǎn)、定時(shí)器列表如果中斷在初始化過(guò)程中觸發(fā)并訪問(wèn)了半初始化的內(nèi)核對(duì)象系統(tǒng)狀態(tài)就會(huì)直接錯(cuò)亂。關(guān)中斷是保證初始化原子性的最樸素手段。但這里的進(jìn)階考點(diǎn)是關(guān)閉中斷的時(shí)機(jī)和恢復(fù)的時(shí)機(jī)分別在哪里RT-Thread在rtthread_startup入口處關(guān)閉中斷直到調(diào)度器啟動(dòng)時(shí)才恢復(fù)因?yàn)檎{(diào)度器啟動(dòng)本身涉及上下文切換必須在中斷開(kāi)啟的狀態(tài)下才能完成。題目三如果MCU上電后既沒(méi)有任何輸出也沒(méi)有進(jìn)入main函數(shù)你會(huì)從哪些方面排查這是一個(gè)非常實(shí)戰(zhàn)的開(kāi)放題。我給出的排查清單是分層的。第一層是供電用示波器測(cè)VDD波形是否穩(wěn)定上電過(guò)程是否有明顯的電壓跌落。第二層是時(shí)鐘晶振是否起振時(shí)鐘引腳波形是否正常如果使用的是內(nèi)部RC檢查配置是否存在不可滿足的倍頻系數(shù)。第三層是復(fù)位確認(rèn)復(fù)位引腳電平不會(huì)一直被拉低看門狗是否在上電瞬間就觸發(fā)了復(fù)位。第四層是啟動(dòng)引腳QSPI或外部NOR flash的方案需要確認(rèn)啟動(dòng)模式選擇引腳的電平是否符合預(yù)期。第五層才是代碼本身用仿真器連接查看PC寄存器的值停在哪個(gè)范圍判斷是執(zhí)行到復(fù)位向量附近還是反復(fù)復(fù)位抑或是停在硬件初始化循環(huán)里。5.3 故障定位相關(guān)題目解析題目四在Cortex-M上系統(tǒng)進(jìn)入HardFault后如何推測(cè)異常前的PC值完整的解題思路分四步。第一步讀取LR寄存器利用EXC_RETURN判斷異常前使用的是MSP還是PSP。第二步對(duì)應(yīng)地讀取MSP或PSP的值記為SP_exc。第三步從SP_exc指向的地址開(kāi)始以字為單位依次讀取R0、R1、R2、R3、R12、LR、PC、xPSR。第四步根據(jù)PC值查閱map文件或反匯編得到具體的崩潰函數(shù)根據(jù)LR值推斷調(diào)用鏈路。注意在沒(méi)有開(kāi)啟FPU的Cortex-M上異常壓棧的寄存器就這8個(gè)字順序固定如果開(kāi)啟了FPU并且使用了FPU寄存器壓棧結(jié)構(gòu)會(huì)多出S0-S15及FPSCR共18個(gè)字讀取時(shí)不能搞混。題目五在RTOS環(huán)境下如何區(qū)分“任務(wù)棧溢出”和“堆內(nèi)存泄漏”導(dǎo)致的崩潰這道題很多人答得泛泛而談。我的判斷標(biāo)準(zhǔn)是看崩潰的時(shí)間和地址特征。任務(wù)棧溢出的崩潰通常在函數(shù)調(diào)用深度突然增大時(shí)出現(xiàn)時(shí)間上有明顯的突變性而且崩潰現(xiàn)場(chǎng)保存的棧指針離任務(wù)棧邊界非常近。堆內(nèi)存泄漏的崩潰則通常是漸進(jìn)式的系統(tǒng)運(yùn)行到某個(gè)臨界點(diǎn)后內(nèi)存分配失敗或者因?yàn)閮?nèi)存碎片導(dǎo)致某次大塊分配失敗崩潰時(shí)間點(diǎn)往往是“運(yùn)行時(shí)間越久越容易崩”。實(shí)操中有一個(gè)很有效的工具組合任務(wù)棧溢出用棧魔術(shù)字掃描在空閑任務(wù)里周期性檢查每個(gè)任務(wù)棧的高水位標(biāo)記內(nèi)存泄漏則用內(nèi)存分配計(jì)數(shù)在malloc/free接口上包一層統(tǒng)計(jì)函數(shù)定期把分配總數(shù)和釋放總數(shù)打到日志里觀察差值是否在持續(xù)上漲。5.4 OTA設(shè)計(jì)相關(guān)題目解析題目六如果產(chǎn)品flash空間只夠存放一個(gè)應(yīng)用副本但你又必須支持OTA升級(jí)且保證升級(jí)失敗不磚機(jī)你會(huì)怎么設(shè)計(jì)這是一個(gè)工程權(quán)衡題沒(méi)有標(biāo)準(zhǔn)答案但有一個(gè)關(guān)鍵原則要守必須保證任意時(shí)刻都有一個(gè)可啟動(dòng)的固件副本在flash里。在只夠一個(gè)應(yīng)用副本的約束下常見(jiàn)解法是拆分方案把flash分成bootloader分區(qū)、app分區(qū)和download暫存分區(qū)。升級(jí)時(shí)先把新固件下載到download分區(qū)校驗(yàn)無(wú)誤后在升級(jí)過(guò)程中利用bootloader配合分塊或乒乓覆蓋的方式寫入app分區(qū)。更極致一點(diǎn)如果連download分區(qū)都沒(méi)有可以退化為“啟動(dòng)時(shí)代理下載”模式系統(tǒng)重啟到bootloader由bootloader直接從網(wǎng)絡(luò)接收固件寫入app分區(qū)應(yīng)用不參與固件寫入。這種模式節(jié)省空間但bootloader的邏輯復(fù)雜度和網(wǎng)絡(luò)棧開(kāi)銷會(huì)顯著上升。題目七為什么差分升級(jí)比全量升級(jí)更難做工程化差分升級(jí)的難點(diǎn)在于它不只涉及傳輸還涉及固件合成和存儲(chǔ)管理。接收差分補(bǔ)丁后設(shè)備需要同時(shí)保留舊固件、差分補(bǔ)丁和新固件至少一部分通常會(huì)把三段數(shù)據(jù)分別放在三個(gè)不同的flash區(qū)域合成過(guò)程中還要頻繁做讀取、解壓、校驗(yàn)和寫入操作。一旦某個(gè)環(huán)節(jié)的偏移量算錯(cuò)合成出來(lái)的固件就是壞的無(wú)法啟動(dòng)。所以工程上必須為差分升級(jí)加一道額外的防線合成后的新固件先完整計(jì)算一遍哈希和服務(wù)器下發(fā)的預(yù)期哈希比對(duì)通過(guò)后才允許置位啟動(dòng)標(biāo)志。這道校驗(yàn)的時(shí)間會(huì)稍微延長(zhǎng)升級(jí)時(shí)長(zhǎng)但相比變磚風(fēng)險(xiǎn)這點(diǎn)代價(jià)非常值得。6. 一些個(gè)人經(jīng)驗(yàn)與下篇預(yù)告整理完上篇這幾塊內(nèi)容我自己也把整個(gè)知識(shí)體系重新過(guò)了一遍。啟動(dòng)流程、故障定位、OTA升級(jí)這三個(gè)話題單獨(dú)拿出來(lái)每一個(gè)都是一門課的分量但真正把它們串起來(lái)之后你會(huì)發(fā)現(xiàn)它們彼此是咬合的。啟動(dòng)流程是底層地基故障定位是用來(lái)填坑的工具箱OTA則是把這兩個(gè)能力產(chǎn)品化的載體。從實(shí)際帶項(xiàng)目和新手輔導(dǎo)的角度我給讀者三個(gè)建議。第一不要滿足于“能在IDE里編譯運(yùn)行”?；ㄒ粋€(gè)下午把鏈接腳本從頭到尾看一遍把你用到的芯片的啟動(dòng)文件逐行注釋一遍收獲遠(yuǎn)比看十篇使用教程大。第二趁早建立一套自己的“崩潰現(xiàn)場(chǎng)捕獲”工具鏈無(wú)論是串口打印還是環(huán)形日志一定要讓系統(tǒng)在出問(wèn)題時(shí)留下足夠多可以回溯的信息。項(xiàng)目到后期能不能快速定位問(wèn)題拼的就是這套基礎(chǔ)設(shè)施。第三OTA升級(jí)別等項(xiàng)目快量產(chǎn)了才做方案在固件設(shè)計(jì)的第一天就要想好分區(qū)方案和升級(jí)接口。下篇我會(huì)重點(diǎn)拆解兩個(gè)實(shí)戰(zhàn)場(chǎng)景一是基于RT-Thread平臺(tái)上完整實(shí)現(xiàn)一套帶A/B分區(qū)和回滾機(jī)制的OTA組件二是用一個(gè)線上故障的真實(shí)案例展示從串口日志到最終定位的全過(guò)程排查思路。同時(shí)會(huì)把下篇的思考題設(shè)計(jì)得更靠近工程實(shí)踐讓讀者真的有“動(dòng)手做一遍”的沖動(dòng)。最后再分享一個(gè)小技巧。在啟動(dòng)代碼里加上這個(gè)信息打印后續(xù)很多問(wèn)題的排查會(huì)省掉一半力氣void show_boot_info(void) { rt_kprintf(\n); rt_kprintf(Firmware Version: %s\n, FW_VERSION); rt_kprintf(Built Time: %s %s\n, __DATE__, __TIME__); rt_kprintf(Boot Reason: %d\n, get_boot_reason()); rt_kprintf(Last Reset Cause: %d\n, get_reset_cause()); rt_kprintf(\n); }打印編譯時(shí)間和版本號(hào)的目的是防止現(xiàn)場(chǎng)設(shè)備與代碼版本對(duì)不上號(hào)打印復(fù)位原因則能快速分辨是上電復(fù)位、看門狗復(fù)位還是軟件復(fù)位——這個(gè)信息在遠(yuǎn)程診斷時(shí)幾乎必查。把這些基礎(chǔ)觀測(cè)手段做扎實(shí)比任何“萬(wàn)能調(diào)試大法”都管用。很多時(shí)候嵌入式開(kāi)發(fā)拼的不是破解疑難雜癥的靈光一現(xiàn)而是把基礎(chǔ)工作做到位之后疑難雜癥自然變少了。