1. 為什么要花大力氣拆解啟動(dòng)流程做嵌入式固件這幾年我最大的一個(gè)感受是很多線上問(wèn)題、現(xiàn)場(chǎng)事故最后都?xì)w結(jié)到了啟動(dòng)過(guò)程上。應(yīng)用邏輯跑飛了、外設(shè)初始化順序不對(duì)、內(nèi)存踩踏導(dǎo)致上電即死、OTA升級(jí)后設(shè)備變磚——這些問(wèn)題看似五花八門真正的根源往往就藏在從復(fù)位向量到main函數(shù)之間的那幾百行代碼里。但現(xiàn)實(shí)是大多數(shù)工程師對(duì)啟動(dòng)流程的理解停留在復(fù)位后從0x08000000開(kāi)始執(zhí)行這種層面。能用調(diào)試器跑到main就算成功至于中間發(fā)生了什么、為什么要這樣設(shè)計(jì)、哪些環(huán)節(jié)最容易出問(wèn)題很少人能把整條鏈路完整講清楚。這也是我在CSDN開(kāi)這個(gè)付費(fèi)專欄的初衷——把啟動(dòng)流程、故障定位、OTA升級(jí)這三塊硬骨頭掰開(kāi)揉碎從原理到工程實(shí)踐一條線講透。這篇連載的上篇我已經(jīng)重點(diǎn)做了啟動(dòng)流程的深度拆解課后留了幾道思考題。今天這篇一方面把上篇的思考題完整解析一遍另一方面把故障定位的方法論和OTA升級(jí)的工程化方案做個(gè)系統(tǒng)梳理。三塊內(nèi)容看似獨(dú)立實(shí)際是一條完整的技術(shù)鏈路不懂啟動(dòng)流程就不知道系統(tǒng)從哪里開(kāi)始不會(huì)故障定位系統(tǒng)崩了只能干瞪眼不做OTA工程化固件迭代就只能靠下載器一臺(tái)臺(tái)燒。適合誰(shuí)來(lái)讀我覺(jué)得只要是做嵌入式開(kāi)發(fā)、特別是做單片機(jī)或者帶系統(tǒng)的固件開(kāi)發(fā)、想往更高階方向走的工程師這篇文章都值得花半小時(shí)認(rèn)真看一遍。尤其是已經(jīng)在做量產(chǎn)項(xiàng)目、遇到過(guò)現(xiàn)場(chǎng)問(wèn)題卻不知道怎么下手的人你踩過(guò)的坑大概率都在下面這些內(nèi)容里。2. MCU與SoC啟動(dòng)流程從復(fù)位向量到main函數(shù)之間到底發(fā)生了什么2.1 裸機(jī)MCU啟動(dòng)的本質(zhì)一張向量表和一個(gè)棧指針先看最簡(jiǎn)單的場(chǎng)景——裸機(jī)MCU比如STM32F103這種Cortex-M3內(nèi)核的片子。上電之后硬件做的事情其實(shí)非常少讀0x00000000處的初始棧指針MSP讀0x00000004處的復(fù)位向量然后跳轉(zhuǎn)過(guò)去執(zhí)行。這個(gè)動(dòng)作在ARM架構(gòu)手冊(cè)里有明確規(guī)定屬于CPU的基本行為。但這里有個(gè)關(guān)鍵點(diǎn)硬件只負(fù)責(zé)這兩個(gè)動(dòng)作之后的一切都是軟件的事。跳轉(zhuǎn)到復(fù)位向量之后芯片廠商的啟動(dòng)文件比如startup_stm32f103xe.s就開(kāi)始干活了。這段匯編代碼做的事情按順序大概是初始化?？臻g把棧指針設(shè)置到RAM的合法區(qū)域拷貝.data段的數(shù)據(jù)從Flash到RAM清零.bss段可選配置系統(tǒng)時(shí)鐘調(diào)用SystemInit函數(shù)做時(shí)鐘和Flash等待狀態(tài)的初始化跳轉(zhuǎn)到C運(yùn)行時(shí)庫(kù)的__main最終進(jìn)入main函數(shù)很多人以為啟動(dòng)文件是編譯器自動(dòng)生成的其實(shí)不是。它由芯片廠商提供不同廠商、不同內(nèi)核的啟動(dòng)文件差異很大。比如Cortex-M0的啟動(dòng)文件和M3/M4的就不同M0的中斷向量表更簡(jiǎn)單可用的中斷也少得多。如果移植代碼時(shí)忽略了這個(gè)差異經(jīng)常會(huì)在莫名其妙的地方出問(wèn)題。另外還有一個(gè)非常容易被忽略的細(xì)節(jié)看門狗。如果工程里默認(rèn)開(kāi)了獨(dú)立看門狗IWDG而且你在進(jìn)main之前消耗的時(shí)間過(guò)長(zhǎng)——比如SystemInit里做了較耗時(shí)的時(shí)鐘切換——看門狗可能已經(jīng)溢出復(fù)位了。這個(gè)問(wèn)題在調(diào)試器里幾乎看不出來(lái)因?yàn)檎{(diào)試器默認(rèn)暫停看門狗計(jì)數(shù)但現(xiàn)場(chǎng)設(shè)備上就是反復(fù)重啟。我見(jiàn)過(guò)不止一個(gè)項(xiàng)目因?yàn)檫@個(gè)原因一上電就跑飛查了半天最后發(fā)現(xiàn)是啟動(dòng)文件里缺了喂狗。雖然裸機(jī)場(chǎng)景下看門狗通常由用戶程序自己初始化但如果你用的是帶Bootloader的方案這個(gè)問(wèn)題會(huì)更突出——后面講OTA的時(shí)候我會(huì)再提。2.2 SoC啟動(dòng)鏈路為什么要比MCU多那么多級(jí)說(shuō)完MCU再看SoC。拿常見(jiàn)的i.MX6ULL、全志V3s這類帶MMU、能跑Linux的應(yīng)用處理器來(lái)說(shuō)啟動(dòng)過(guò)程要比MCU復(fù)雜一個(gè)量級(jí)。SoC的典型啟動(dòng)鏈路是這樣的ROM Code → BootROM固化在芯片內(nèi)部 → SPL或叫MLO → U-Boot → Kernel → rootfsROM Code是芯片出廠時(shí)就固化在硅片內(nèi)部的一段代碼誰(shuí)也改不了。它的職責(zé)是根據(jù)eFUSE或GPIO的電平狀態(tài)決定從哪里加載下一級(jí)bootloader——比如SD卡、eMMC、NAND Flash、USB、網(wǎng)絡(luò)等等。這段代碼的主要作用是引導(dǎo)級(jí)的引導(dǎo)它的存在讓芯片可以支持多種啟動(dòng)介質(zhì)而且不需要修改芯片本身。然后是SPLSecondary Program Loader。這是U-Boot的一個(gè)精簡(jiǎn)版本主要目的是在DDR還沒(méi)初始化之前用最小的代碼量把DDR初始化好然后把完整的U-Boot從存儲(chǔ)介質(zhì)加載到內(nèi)存里運(yùn)行。為什么要分兩步因?yàn)橥暾腢-Boot比較大幾百KB到幾MB而芯片內(nèi)置的SRAM通常只有幾十到幾百KB裝不下完整的U-Boot。所以先把SPL加載進(jìn)SRAM運(yùn)行由SPL初始化SDRAM/DDR再把完整的U-Boot搬到內(nèi)存里跑。U-Boot起來(lái)之后會(huì)做更完整的板級(jí)初始化串口打印、網(wǎng)卡、eMMC/SD驅(qū)動(dòng)、顯示、命令行交互等。然后根據(jù)bootcmd環(huán)境變量把kernel鏡像和設(shè)備樹(shù)加載到內(nèi)存指定地址跳轉(zhuǎn)執(zhí)行。kernel接管后完成虛擬內(nèi)存、調(diào)度器、驅(qū)動(dòng)模型等的初始化最后掛載根文件系統(tǒng)執(zhí)行init進(jìn)程。這條鏈路看上去很簡(jiǎn)單但實(shí)際調(diào)試時(shí)每一步都可能出問(wèn)題。一個(gè)常見(jiàn)的情況SPL階段串口沒(méi)輸出任何東西你連U-Boot都沒(méi)進(jìn)。這時(shí)要用調(diào)試器確認(rèn)SPL有沒(méi)有被執(zhí)行——是加載地址不對(duì)還是DDR初始化就崩了。另一個(gè)典型問(wèn)題U-Boot已經(jīng)起來(lái)了但kernel啟動(dòng)到一半死掉這通常是設(shè)備樹(shù)DTB與kernel版本不匹配或者kernel里對(duì)應(yīng)外設(shè)驅(qū)動(dòng)不全導(dǎo)致。2.3 RT-Thread系統(tǒng)啟動(dòng)初始化流程的獨(dú)特性如果你用的是RT-Thread這種RTOS啟動(dòng)流程又是另一套邏輯。RT-Thread在keil/IAR/GCC下的啟動(dòng)過(guò)程大體是硬件啟動(dòng)文件把環(huán)境準(zhǔn)備好之后進(jìn)入RT-Thread的入口函數(shù)rtthread_startup然后在這個(gè)函數(shù)里完成一系列初始化最終啟動(dòng)調(diào)度器進(jìn)入第一個(gè)線程。按順序大概是這樣關(guān)閉中斷保證初始化過(guò)程不被搶占初始化硬件相關(guān)部分板級(jí)初始化、系統(tǒng)堆初始化初始化內(nèi)核對(duì)象調(diào)度器、信號(hào)量、互斥鎖、郵箱、消息隊(duì)列等創(chuàng)建main線程或叫init線程讓?xiě)?yīng)用代碼在main線程里跑啟動(dòng)調(diào)度器開(kāi)始多任務(wù)調(diào)度有一個(gè)RT-Thread新手容易踩的坑在main函數(shù)里寫(xiě)一個(gè)死循環(huán)什么都不做以為RT-Thread會(huì)自動(dòng)跑別的線程。實(shí)際上如果main線程里沒(méi)有主動(dòng)讓出CPU或者阻塞等待它會(huì)把CPU占滿其他優(yōu)先級(jí)低于它的線程永遠(yuǎn)得不到調(diào)度。這就是為什么RT-Thread官方例程的main函數(shù)里通常要么有延時(shí)、要么有信號(hào)量等待——不是為了搞個(gè)示例而是為了讓調(diào)度器有機(jī)會(huì)切換任務(wù)。還有一點(diǎn)RT-Thread的啟動(dòng)過(guò)程對(duì)中斷比較敏感。如果在調(diào)度器啟動(dòng)之前就打開(kāi)了中斷而且此時(shí)剛好有中斷觸發(fā)中斷處理函數(shù)里如果調(diào)用了依賴于調(diào)度器的API比如釋放信號(hào)量、發(fā)送消息可能會(huì)導(dǎo)致系統(tǒng)崩潰。因?yàn)檎{(diào)度器還沒(méi)初始化完內(nèi)核對(duì)象還沒(méi)準(zhǔn)備好。這個(gè)屬于時(shí)序問(wèn)題排查起來(lái)很隱蔽建議你寫(xiě)板級(jí)初始化代碼時(shí)明確中斷開(kāi)關(guān)的時(shí)機(jī)不要依賴廠商的默認(rèn)實(shí)現(xiàn)。2.4 U-Boot啟動(dòng)流程中必須吃透的幾個(gè)環(huán)節(jié)U-Boot作為SoC啟動(dòng)鏈路中的關(guān)鍵一環(huán)它的啟動(dòng)流程值得單獨(dú)說(shuō)。U-Boot從入口_start開(kāi)始經(jīng)歷大致以下幾個(gè)階段設(shè)置CPU為SVC模式關(guān)閉中斷和MMU保證硬件處于最原始的干凈狀態(tài)初始化串口早期串口用于打印最開(kāi)始的啟動(dòng)日志初始化DDR控制器如果是從SPL跳轉(zhuǎn)過(guò)來(lái)這一步可能已經(jīng)做過(guò)了重定位U-Boot自身到DDR的高地址區(qū)域因?yàn)榈偷刂穮^(qū)域后續(xù)要放kernel初始化板級(jí)硬件時(shí)鐘、網(wǎng)卡、存儲(chǔ)控制器、GPIO等進(jìn)入main_loop等待用戶按鍵進(jìn)入命令行或者自動(dòng)執(zhí)行bootcmd理解U-Boot的關(guān)鍵在于理解它的兩個(gè)階段設(shè)計(jì)SPL階段和U-Boot正式階段。很多剛開(kāi)始接觸U-Boot的工程師會(huì)困惑為什么U-Boot源碼里有兩個(gè)board_init_f和board_init_r為什么有的函數(shù)執(zhí)行兩次原因就是分階段初始化——第一階段init_f在SRAM里運(yùn)行做最小初始化第二階段init_r在DDR里運(yùn)行做完整初始化。實(shí)際調(diào)試中最常見(jiàn)的U-Boot故障有三種U-Boot起來(lái)后網(wǎng)卡不通無(wú)法通過(guò)tftp下載kernel。這個(gè)一般先查PHY地址對(duì)不對(duì)再看設(shè)備樹(shù)里網(wǎng)卡節(jié)點(diǎn)的reg屬性是否匹配。U-Boot能起來(lái)但無(wú)法加載kernel提示Bad Linux ARM zImage magic。這個(gè)通常是加載地址不對(duì)——kernel鏡像要加載到內(nèi)存的合適地址不同SoC有各自約定亂放肯定不行。加了新外設(shè)后U-Boot啟動(dòng)變慢甚至卡死。這個(gè)重點(diǎn)檢查新設(shè)備的初始化是否放在了會(huì)阻塞的位置比如等待某個(gè)不穩(wěn)定外設(shè)的握手信號(hào)。3. 啟動(dòng)階段的故障定位方法論從現(xiàn)象到根因的完整排查鏈路3.1 建立啟動(dòng)階段時(shí)間軸思維講完原理下面進(jìn)入故障定位環(huán)節(jié)。我認(rèn)為做啟動(dòng)階段的問(wèn)題排查第一步不是拿示波器、不是接調(diào)試器而是在紙上畫(huà)出系統(tǒng)從復(fù)位到正常運(yùn)行的時(shí)間軸每一段標(biāo)注出當(dāng)前執(zhí)行什么代碼、輸出什么信息、外設(shè)處于什么狀態(tài)。為什么要畫(huà)時(shí)間軸因?yàn)閱?dòng)階段的問(wèn)題有一個(gè)共同特征信息量極少錯(cuò)誤窗口很短。資源還沒(méi)完全初始化日志系統(tǒng)可能還沒(méi)起來(lái)網(wǎng)絡(luò)?？赡苓€不可用你唯一能依賴的往往是一個(gè)串口、幾行打印、一個(gè)LED或者調(diào)試器。如果沒(méi)有時(shí)間軸意識(shí)你很容易在錯(cuò)誤的時(shí)間點(diǎn)找錯(cuò)誤的信息。比如之前幫一個(gè)客戶排查農(nóng)用設(shè)備控制板現(xiàn)象是上電沒(méi)反應(yīng)LED不亮。乍一看像是電源問(wèn)題但實(shí)測(cè)電源輸出正常、MCU沒(méi)有明顯短路。后來(lái)用調(diào)試器連上發(fā)現(xiàn)CPU已經(jīng)跑在HardFault_Handler里了。再進(jìn)一步從故障寄存器CFSR、HFSR里看到是總線錯(cuò)誤訪問(wèn)了非法地址。順著這個(gè)線索查下去——初始化外設(shè)時(shí)某個(gè)外設(shè)的時(shí)鐘還沒(méi)使能就寫(xiě)了它的寄存器導(dǎo)致總線錯(cuò)誤。這就是典型的時(shí)間軸錯(cuò)位問(wèn)題代碼在A階段啟動(dòng)了某個(gè)外設(shè)的時(shí)鐘卻在B階段時(shí)鐘還沒(méi)起來(lái)時(shí)就開(kāi)始操作那個(gè)外設(shè)的寄存器。畫(huà)時(shí)間軸寫(xiě)清楚每一步的先后順序這種問(wèn)題其實(shí)很好避免。3.2 串口打印是啟動(dòng)階段的第一排障手段但要用對(duì)方法串口打印是最樸素也最有效的啟動(dòng)排障手段。很多工程師用串口打印的方式是這樣的在main入口打一行System Start然后在幾個(gè)關(guān)鍵函數(shù)入口各打一行。這個(gè)思路沒(méi)錯(cuò)但實(shí)際操作中經(jīng)常遇到兩個(gè)問(wèn)題第一個(gè)問(wèn)題是打印本身會(huì)改變啟動(dòng)時(shí)序。如果用的是阻塞式串口發(fā)送每條打印都可能耗時(shí)幾十微秒到幾毫秒在高波特率下還好波特率低時(shí)影響就很明顯。如果做的是對(duì)時(shí)序敏感的外設(shè)初始化比如某些傳感器上電后要求在一定時(shí)間內(nèi)完成初始化打印日志反倒可能引入故障。我的建議是在排障階段盡量使用調(diào)試串口不參與業(yè)務(wù)邏輯并且把關(guān)鍵日志放到初始化完成之后再集中打印。第二個(gè)問(wèn)題是打印信息太泛濫真正有用的信息被淹沒(méi)。啟動(dòng)排查階段我習(xí)慣這么做每條關(guān)鍵打印都帶一個(gè)編號(hào)和縮寫(xiě)比如[P1] CLK INIT OK、[P2] SDRAM SELF-TEST PASS、[P3] LOAD KERNEL FROM EMMC。這樣一旦問(wèn)題發(fā)生只需要看最后一個(gè)編號(hào)就知道卡在哪里。比一屏亂糟糟的日志高效得多。這個(gè)方法在排查U-Boot啟動(dòng)異常時(shí)尤為好用。U-Boot默認(rèn)打印信息量很大但很多關(guān)鍵階段并沒(méi)有明確的標(biāo)記。我會(huì)在board_init_f、board_init_r、main_loop這些關(guān)鍵函數(shù)里手動(dòng)加帶編號(hào)的打印重編一個(gè)排障版U-Boot跑一次就知道問(wèn)題發(fā)生在哪一級(jí)。3.3 實(shí)戰(zhàn)案例一個(gè)啟動(dòng)卡死問(wèn)題從無(wú)任何輸出到定位根因的完整過(guò)程分享一個(gè)我真實(shí)處理過(guò)的案例盡量還原完整的排查鏈路其中包括每一次嘗試和反復(fù)而不是只給結(jié)論?，F(xiàn)象描述一塊基于Cortex-M7內(nèi)核的板子上電后串口無(wú)任何輸出調(diào)試器加載固件后可以正常跑說(shuō)明固件本身沒(méi)問(wèn)題但斷電重新上電就完全沒(méi)反應(yīng)?？蛻魬岩墒怯布?wèn)題板子發(fā)過(guò)來(lái)讓我?guī)兔?。第一步確認(rèn)電源、時(shí)鐘、復(fù)位。用示波器測(cè)各路電源的上升沿確認(rèn)上電時(shí)序是否滿足要求測(cè)復(fù)位引腳發(fā)現(xiàn)復(fù)位釋放正常用頻率計(jì)測(cè)外部晶振發(fā)現(xiàn)時(shí)鐘輸出正常。這說(shuō)明硬件的最小系統(tǒng)大概率沒(méi)問(wèn)題。第二步用調(diào)試器掛上單步執(zhí)行。從復(fù)位向量開(kāi)始單步走發(fā)現(xiàn)代碼停在了一個(gè)奇怪的地址不是HardFault_Handler也不是Default_Handler而是一個(gè)看起來(lái)像是隨機(jī)的地址。查map文件這個(gè)地址在某個(gè)外設(shè)寄存器的地址范圍內(nèi)——說(shuō)明代碼訪問(wèn)了非法地址觸發(fā)了總線錯(cuò)誤但異常處理本身也有問(wèn)題所以沒(méi)有跳轉(zhuǎn)到預(yù)期的地方。第三步回到啟動(dòng)文件檢查棧指針。再看一遍硬件復(fù)位行為CPU復(fù)位后先從0x00000000取初始棧指針再?gòu)?x00000004取復(fù)位向量。問(wèn)題就出在這里**0x00000000處的值**不是合法的RAM地址。用調(diào)試器讀一下內(nèi)存發(fā)現(xiàn)Flash的前4個(gè)字節(jié)全是0xFFFFFFFF——等于說(shuō)Flash根本沒(méi)燒錄成功或者燒錄的地址不對(duì)。第四步查燒錄配置。打開(kāi)燒錄算法配置發(fā)現(xiàn)客戶用的是外部QSPI Flash啟動(dòng)方案但燒錄時(shí)把固件下載到了內(nèi)部Flash的地址0x08000000而芯片實(shí)際是從外部QSPI的0x90000000啟動(dòng)的。燒錄地址和啟動(dòng)地址不匹配導(dǎo)致CPU從QSPI Flash讀到的全是0xFFFFFFFF初始化棧指針就失敗了。復(fù)盤這個(gè)問(wèn)題根因很簡(jiǎn)單但排查過(guò)程走了一些彎路。如果用啟動(dòng)時(shí)間軸的方法第一步就應(yīng)該確認(rèn)芯片實(shí)際是從哪個(gè)地址啟動(dòng)的啟動(dòng)介質(zhì)上有沒(méi)有合法數(shù)據(jù)。有了這個(gè)前提后面的排查會(huì)快很多。這個(gè)案例也說(shuō)明很多啟動(dòng)問(wèn)題不是代碼寫(xiě)錯(cuò)了而是工程配置與硬件設(shè)計(jì)不一致這類問(wèn)題僅靠看代碼是看不出來(lái)的必須結(jié)合硬件實(shí)際情況一起分析。3.4 故障定位的常用工具箱從調(diào)試器到邏輯分析儀啟動(dòng)階段的故障定位工具不在多關(guān)鍵是選對(duì)并用對(duì)。我個(gè)人最常用的組合是一個(gè)帶SWD接口的調(diào)試器J-Link、DAP-Link都行、一個(gè)四通道以上的示波器、一個(gè)邏輯分析儀再加一個(gè)串口調(diào)試助手。調(diào)試器主要用于看CPU的執(zhí)行狀態(tài)停在哪里、PC指針是什么、堆棧回溯到哪個(gè)函數(shù)、寄存器狀態(tài)怎么樣。對(duì)于HardFault類問(wèn)題SWD調(diào)試器幾乎是必備的。我特別推薦在啟動(dòng)階段就給項(xiàng)目配置好異常回溯功能——Cortex-M系列可以注冊(cè)一個(gè)HardFault_Handler在異常發(fā)生時(shí)把CFSR、BFAR、MMFAR這些寄存器的值保存下來(lái)同時(shí)做一次?；厮莅押瘮?shù)調(diào)用鏈打印到串口。這套東西在量產(chǎn)階段排查偶發(fā)問(wèn)題能省大量時(shí)間。示波器用來(lái)驗(yàn)證時(shí)序上電時(shí)序、復(fù)位釋放時(shí)序、時(shí)鐘穩(wěn)定時(shí)間、某些外設(shè)的使能信號(hào)是否按照預(yù)期先后產(chǎn)生。啟動(dòng)時(shí)對(duì)外設(shè)有嚴(yán)格的時(shí)序要求比如先穩(wěn)定供電、再釋放復(fù)位、再開(kāi)始初始化這些時(shí)序用示波器一看便知。邏輯分析儀在排查通信類外設(shè)啟動(dòng)問(wèn)題時(shí)很有用。比如設(shè)備啟動(dòng)后要跟外部芯片通過(guò)I2C/SPI做握手如果軟件里初始化順序不對(duì)可能會(huì)在總線協(xié)議層面違反時(shí)序要求。這時(shí)候邏輯分析儀可以把總線上的每一筆交易都記錄下來(lái)對(duì)照數(shù)據(jù)手冊(cè)確認(rèn)哪個(gè)字節(jié)沒(méi)對(duì)上。4. OTA升級(jí)工程化實(shí)戰(zhàn)從方案選型到版本回滾的完整設(shè)計(jì)4.1 OTA升級(jí)的本質(zhì)不是加個(gè)下載功能而是保證設(shè)備永遠(yuǎn)可救很多人理解OTA升級(jí)就是設(shè)備通過(guò)WiFi/4G下載固件然后寫(xiě)入Flash重啟。這個(gè)理解太簡(jiǎn)單了。真正的OTA升級(jí)從設(shè)計(jì)層面要回答的問(wèn)題比怎么寫(xiě)Flash多得多下載過(guò)程中斷電了怎么辦新固件啟動(dòng)失敗怎么辦存儲(chǔ)空間不夠怎么辦大批量設(shè)備同時(shí)升級(jí)服務(wù)器扛得住嗎升級(jí)失敗導(dǎo)致設(shè)備變磚售后成本誰(shuí)來(lái)承擔(dān)所以我在專欄里反復(fù)強(qiáng)調(diào)一個(gè)觀點(diǎn)OTA升級(jí)的本質(zhì)不是加個(gè)下載功能而是保證設(shè)備永遠(yuǎn)可救。圍繞這個(gè)目標(biāo)工程上要做的事情包括但不限于分區(qū)規(guī)劃、雙備份機(jī)制、升級(jí)狀態(tài)記錄、斷點(diǎn)續(xù)傳、版本校驗(yàn)、失敗回滾、灰度發(fā)布。4.2 Flash分區(qū)設(shè)計(jì)A/B分區(qū)方案與單分區(qū)方案的取舍在嵌入式設(shè)備上做OTA最核心的問(wèn)題就是新固件放哪里、舊固件怎么處理、失敗了怎么辦。由此引出兩種主流的Flash分區(qū)方案。單分區(qū)方案整個(gè)應(yīng)用區(qū)域只有一個(gè)固件槽位。升級(jí)時(shí)新固件直接覆蓋舊固件的空間。這種方案優(yōu)點(diǎn)是Flash占用小缺點(diǎn)是升級(jí)過(guò)程中如果發(fā)生斷電或?qū)懭脲e(cuò)誤設(shè)備直接變磚沒(méi)有回退手段。所以單分區(qū)方案必須配合Bootloader的恢復(fù)機(jī)制——Bootloader檢測(cè)到應(yīng)用區(qū)校驗(yàn)失敗就進(jìn)入等待下載模式等待主機(jī)重新下發(fā)固件。這方案對(duì)Bootloader的設(shè)計(jì)要求很高。A/B雙分區(qū)方案Flash里同時(shí)保留兩份固件一個(gè)稱為A槽一個(gè)稱為B槽。Bootloader每次啟動(dòng)時(shí)根據(jù)升級(jí)標(biāo)志決定從哪個(gè)槽啟動(dòng)。升級(jí)時(shí)新固件寫(xiě)入非當(dāng)前運(yùn)行的槽位寫(xiě)入完成后標(biāo)記該槽位為待驗(yàn)證狀態(tài)重啟后Bootloader從新槽位啟動(dòng)應(yīng)用運(yùn)行正常則標(biāo)記為已確認(rèn)如果運(yùn)行異常比如看門狗超時(shí)、啟動(dòng)失敗則回滾到舊槽位。A/B方案在消費(fèi)電子和車機(jī)領(lǐng)域幾乎成了標(biāo)配原因很簡(jiǎn)單它把升級(jí)失敗變磚的概率壓縮到極低。代價(jià)是Flash容量要求翻倍。在MCU資源受限的場(chǎng)景下需要在Flash容量和安全性之間做一個(gè)權(quán)衡。我個(gè)人的建議是如果Flash剩余空間充足比如有2MB固件只有500KB優(yōu)先上A/B方案如果Flash吃緊至少也要保證Bootloader里有可靠的恢復(fù)接口串口、USB、網(wǎng)絡(luò)等能讓設(shè)備恢復(fù)到可下載狀態(tài)。單分區(qū)不是不能用但必須有后手。下面是兩種方案的核心對(duì)比對(duì)比維度單分區(qū)方案A/B雙分區(qū)方案Flash占用低只需一份固件空間高需要兩份固件空間升級(jí)失敗恢復(fù)依賴Bootloader恢復(fù)下載自動(dòng)回滾舊版本實(shí)現(xiàn)復(fù)雜度較低較高斷電風(fēng)險(xiǎn)高寫(xiě)入中斷可能變磚低最多啟動(dòng)一次未驗(yàn)證版本適用場(chǎng)景Flash極小的低成本MCU對(duì)可靠性和可維護(hù)性要求高的產(chǎn)品4.3 OTA升級(jí)的關(guān)鍵工程細(xì)節(jié)校驗(yàn)、斷電保護(hù)、狀態(tài)機(jī)確定了分區(qū)方案下面聊幾個(gè)OTA升級(jí)必須處理的工程細(xì)節(jié)。校驗(yàn)是最基本的要求。固件包下載完成后必須做完整性校驗(yàn)——常見(jiàn)的是CRC32或者M(jìn)D5/SHA256。我建議至少兩層校驗(yàn)第一層固件包本身的校驗(yàn)下載完成后對(duì)整個(gè)包做哈希比對(duì)第二層寫(xiě)入Flash后的再校驗(yàn)寫(xiě)入完成后讀回來(lái)重新計(jì)算哈希防寫(xiě)入過(guò)程出錯(cuò)。如果用的是帶加密的固件簽名方案那校驗(yàn)邏輯還要加上簽名驗(yàn)證防止偽造固件。斷電保護(hù)是OTA的生死線。以STM32為例寫(xiě)入內(nèi)部Flash時(shí)如果中間斷電可能會(huì)出現(xiàn)兩種情況一是正在寫(xiě)入的扇區(qū)數(shù)據(jù)損壞二是擦除了一半導(dǎo)致整個(gè)扇區(qū)內(nèi)容不可用。解決辦法有三個(gè)層次第一使用雙分區(qū)方案前文已說(shuō)第二在寫(xiě)入前先對(duì)目標(biāo)扇區(qū)做擦除備份比如把舊數(shù)據(jù)先搬到一個(gè)備份區(qū)域但這會(huì)占用額外Flash第三設(shè)計(jì)一個(gè)升級(jí)狀態(tài)機(jī)每次寫(xiě)入都把當(dāng)前升級(jí)進(jìn)度記錄在一個(gè)專門的狀態(tài)存儲(chǔ)區(qū)重啟后Bootloader讀取狀態(tài)機(jī)知道前一次升級(jí)進(jìn)行到第幾步從而決定是繼續(xù)、回滾還是重新下載。升級(jí)狀態(tài)機(jī)設(shè)計(jì)空閑→下載中→校驗(yàn)→寫(xiě)入A→校驗(yàn)A→等待重啟→標(biāo)記A有效→運(yùn)行新固件→等確認(rèn)。狀態(tài)機(jī)每一步都持久化到狀態(tài)區(qū)。這個(gè)狀態(tài)機(jī)的價(jià)值在于在升級(jí)的任何一步斷電系統(tǒng)都能在重啟后明確知道自己該干什么。沒(méi)有狀態(tài)機(jī)的OTA本質(zhì)上是在賭運(yùn)氣好不會(huì)斷電。固件包的管理也是工程化的重頭。正式產(chǎn)品建議用固件包格式來(lái)封裝版本信息、平臺(tái)信息、硬件版本、CRC、簽名等元數(shù)據(jù)。比如定義文件頭Magic4字節(jié) 版本號(hào)4字節(jié) 硬件平臺(tái)ID2字節(jié) 固件大小4字節(jié) CRC324字節(jié) 簽名可選 固件數(shù)據(jù)原始的BIN文件Bootloader在升級(jí)前先解析文件頭檢查平臺(tái)ID是否匹配、版本號(hào)是否合法、CRC是否正確全部通過(guò)才允許寫(xiě)入。這一步能攔住很多誤操作比如拿A型號(hào)的固件去刷B型號(hào)的設(shè)備。4.4 回滾機(jī)制與容錯(cuò)設(shè)計(jì)如何保證升級(jí)后設(shè)備還活著雙分區(qū)方案天然支持回滾但回滾邏輯本身也是需要精心設(shè)計(jì)的。不可能出現(xiàn)任何異常都立刻回滾——有些情況是臨時(shí)性故障比如升級(jí)完后第一次啟動(dòng)時(shí)外設(shè)還沒(méi)穩(wěn)定給新固件一個(gè)試運(yùn)行窗口期是更合理的做法。我常用的一種做法是新固件啟動(dòng)后主動(dòng)向一個(gè)日志區(qū)寫(xiě)新固件啟動(dòng)標(biāo)記。應(yīng)用在正常運(yùn)行一段時(shí)間比如5分鐘后如果一切正常則向狀態(tài)區(qū)寫(xiě)確認(rèn)OK。如果在窗口期內(nèi)發(fā)生看門狗復(fù)位或者應(yīng)用主動(dòng)報(bào)告啟動(dòng)失敗Bootloader判定新固件不可用回滾到舊槽位。窗口期的長(zhǎng)度要根據(jù)產(chǎn)品場(chǎng)景設(shè)定傳感器類設(shè)備可以很短30秒~1分鐘復(fù)雜的工業(yè)設(shè)備可能需要更長(zhǎng)的驗(yàn)證時(shí)間比如一次完整的自檢流程。窗口期太短可能導(dǎo)致誤判太長(zhǎng)則可能讓壞固件跑太久影響生產(chǎn)。這個(gè)需要權(quán)衡。另外要說(shuō)一個(gè)常見(jiàn)的工程失誤回滾之后沒(méi)有限制反復(fù)升級(jí)的次數(shù)。如果新固件一直有問(wèn)題設(shè)備就會(huì)陷入升級(jí)→啟動(dòng)失敗→回滾→再次檢測(cè)到新版本→再次升級(jí)→再次回滾的循環(huán)。正確的做法是在狀態(tài)區(qū)記錄連續(xù)升級(jí)失敗的次數(shù)超過(guò)N次比如3次之后系統(tǒng)暫停自動(dòng)升級(jí)進(jìn)入僅手動(dòng)恢復(fù)模式等待運(yùn)維人員介入。4.5 一個(gè)低配版OTA的具體實(shí)現(xiàn)思路基于Ymodem或HTTP的入門方案講完工程化整體思路給一個(gè)可以落地的入門方案。如果你的產(chǎn)品還在早期驗(yàn)證階段不需要一步到位上A/B分區(qū)可以先實(shí)現(xiàn)一個(gè)最小可用OTA。思路Bootloader 應(yīng)用層雙區(qū)架構(gòu)應(yīng)用區(qū)32KBBootloader區(qū)16KB中間用一個(gè)標(biāo)志扇區(qū)記錄升級(jí)狀態(tài)和信息。升級(jí)方式用Ymodem協(xié)議——因?yàn)閷?shí)測(cè)顯示它比Xmodem更穩(wěn)而且支持文件名傳輸可以順便傳遞版本信息——或者如果你設(shè)備有網(wǎng)絡(luò)能力用HTTP下載固件包也行。大致流程是應(yīng)用收到新固件包先把固件包放到外部Flash或文件系統(tǒng)的臨時(shí)區(qū)應(yīng)用校驗(yàn)固件包完整性CRC/哈希應(yīng)用把升級(jí)標(biāo)志寫(xiě)入標(biāo)志扇區(qū)狀態(tài)為準(zhǔn)備升級(jí)系統(tǒng)軟復(fù)位進(jìn)入BootloaderBootloader讀取標(biāo)志扇區(qū)發(fā)現(xiàn)準(zhǔn)備升級(jí)狀態(tài)從臨時(shí)區(qū)讀取固件并寫(xiě)入應(yīng)用區(qū)寫(xiě)入完成后再次校驗(yàn)通過(guò)則把標(biāo)志改為已升級(jí)待確認(rèn)跳轉(zhuǎn)到應(yīng)用應(yīng)用確認(rèn)運(yùn)行正常后把標(biāo)志改為OK這套方案的好處是即使升級(jí)失敗由于Bootloader還在而且臨時(shí)區(qū)的固件包還在Bootloader可以重新嘗試寫(xiě)入。只有一種情況會(huì)變磚Bootloader自身被破壞。所以Design上要避免把Bootloader和應(yīng)用放在同一個(gè)升級(jí)包里面Bootloader只通過(guò)燒錄器更新。如果你第一次做OTA我強(qiáng)烈建議先在開(kāi)發(fā)板上完整走一遍這個(gè)流程手動(dòng)模擬各種異常寫(xiě)一半斷電、固件包損壞、新固件啟動(dòng)即崩把這些場(chǎng)景全部驗(yàn)證通過(guò)再考慮上量產(chǎn)。5. 上篇課后思考題完整解析啟動(dòng)流程核心問(wèn)題的拆解與延展5.1 思考題一為什么復(fù)位后必須先設(shè)置棧指針再跳轉(zhuǎn)C語(yǔ)言入口函數(shù)這道題看起來(lái)簡(jiǎn)單但考察的是對(duì)C語(yǔ)言運(yùn)行時(shí)環(huán)境的理解。CPU的棧是用來(lái)支持函數(shù)調(diào)用、局部變量、中斷嵌套的沒(méi)有合法的棧指針C語(yǔ)言代碼根本無(wú)法執(zhí)行。跳轉(zhuǎn)到C函數(shù)的第一步通常就是壓棧保存現(xiàn)場(chǎng)如果棧指針指向的是非法地址壓棧操作直接觸發(fā)總線錯(cuò)誤或內(nèi)存保護(hù)錯(cuò)誤整個(gè)系統(tǒng)瞬間崩潰。更深一層棧初始化的正確性還關(guān)系到后續(xù)的所有中斷處理。Cortex-M系列的異常處理會(huì)自動(dòng)使用MSP主棧指針如果MSP在上電后沒(méi)有被正確設(shè)置任何中斷發(fā)生都可能導(dǎo)致HardFault。所以啟動(dòng)文件里第一條指令之前必須先把MSP設(shè)置好。手寫(xiě)鏈接腳本或移植啟動(dòng)文件時(shí)一個(gè)常見(jiàn)的錯(cuò)誤就是棧的地址和大小定義錯(cuò)了——比如定義在了一個(gè)保留給外設(shè)用的地址段或者超出了RAM的實(shí)際大小。這種錯(cuò)誤在調(diào)試器里看往往是莫名其妙的HardFault。5.2 思考題二在main函數(shù)最開(kāi)頭加一條打印語(yǔ)句為什么有時(shí)會(huì)觸發(fā)HardFault這個(gè)問(wèn)題問(wèn)的其實(shí)是運(yùn)行時(shí)環(huán)境有沒(méi)有完全準(zhǔn)備好很多工程師以為從復(fù)位向量跳轉(zhuǎn)到main就萬(wàn)事大吉了其實(shí)main能被執(zhí)行只說(shuō)明棧指針和復(fù)位向量是好的不代表全部環(huán)境都已就緒。會(huì)出現(xiàn)HardFault的情況主要有幾類打印功能依賴的外設(shè)還沒(méi)初始化。比如printf重定向到串口USART1但在main最開(kāi)始還未完成USART1的時(shí)鐘和GPIO配置直接寫(xiě)串口寄存器可能訪問(wèn)到未使能的外設(shè)引發(fā)總線錯(cuò)誤。.data段的全局變量還沒(méi)拷貝完畢。如果printf的實(shí)現(xiàn)內(nèi)部依賴某個(gè)全局變量比如緩沖區(qū)指針而這個(gè)全局變量還處于未初始化狀態(tài)行為就是未定義。C運(yùn)行庫(kù)的初始化如堆的初始化還沒(méi)執(zhí)行而printf內(nèi)部用了malloc或動(dòng)態(tài)內(nèi)存堆指針是空的。所以規(guī)范的做法是main函數(shù)里第一條有意義的代碼應(yīng)該是初始化最基礎(chǔ)的環(huán)境——比如重定向串口所需的時(shí)鐘和GPIO、系統(tǒng)時(shí)鐘配置等。先保證最小輸出能力可用再逐步擴(kuò)展其他功能。這也是為什么很多工程模板的main函數(shù)總是有一個(gè)固定的初始化順序系統(tǒng)時(shí)鐘→調(diào)試串口→其他外設(shè)。這不是習(xí)慣問(wèn)題而是有邏輯依據(jù)的。5.3 思考題三Bootloader跳轉(zhuǎn)到應(yīng)用前為什么要關(guān)中斷、關(guān)外設(shè)、重置棧指針這是Bootloader設(shè)計(jì)中一個(gè)極其關(guān)鍵的細(xì)節(jié)。如果Bootloader不處理干凈就直接跳轉(zhuǎn)應(yīng)用啟動(dòng)時(shí)大概率出問(wèn)題。第一必須關(guān)中斷。Bootloader運(yùn)行期間可能已經(jīng)打開(kāi)了定時(shí)器中斷、串口接收中斷等。跳轉(zhuǎn)到應(yīng)用時(shí)應(yīng)用的向量表地址和應(yīng)用代碼是新的但中斷控制器的使能位還是Bootloader配的舊狀態(tài)。此時(shí)如果有中斷觸發(fā)CPU會(huì)跳到應(yīng)用的中斷向量表去執(zhí)行——但應(yīng)用可能還沒(méi)來(lái)得及初始化對(duì)應(yīng)的中斷源或者根本沒(méi)有處理這個(gè)中斷源的代碼系統(tǒng)直接就崩了。正確做法是跳轉(zhuǎn)前把NVIC里所有已使能的中斷全部失能清除pending狀態(tài)然后才執(zhí)行跳轉(zhuǎn)指令。第二必須關(guān)閉外設(shè)。Bootloader里打開(kāi)的DMA、串口、SPI等外設(shè)如果不關(guān)閉它們可能在應(yīng)用啟動(dòng)過(guò)程中繼續(xù)產(chǎn)生傳輸請(qǐng)求、修改內(nèi)存數(shù)據(jù)。特別是DMA——如果Bootloader有個(gè)正在進(jìn)行的DMA傳輸跳到應(yīng)用后DMA還會(huì)繼續(xù)跑往內(nèi)存里寫(xiě)數(shù)據(jù)可能覆蓋應(yīng)用正在使用的關(guān)鍵變量。跳轉(zhuǎn)前的標(biāo)準(zhǔn)影式是停掉所有外設(shè)、停掉DMA、關(guān)掉中斷、清理緩沖區(qū)。第三必須重置棧指針MSP。Bootloader自身的棧地址可能跟應(yīng)用定義的棧地址不同尤其在Bootloader和應(yīng)用是獨(dú)立編譯、獨(dú)立鏈接的情況下。跳轉(zhuǎn)時(shí)如果沿用Bootloader的棧指針應(yīng)用代碼一執(zhí)行就可能棧溢出或者使用了非預(yù)期內(nèi)存區(qū)域。規(guī)范做法是跳轉(zhuǎn)前從應(yīng)用向量表的首地址讀取出初始棧指針值手動(dòng)寫(xiě)到MSP然后再跳轉(zhuǎn)。還有一個(gè)容易被忽略的點(diǎn)如果在FreeRTOS、RT-Thread這種RTOS環(huán)境下做跳轉(zhuǎn)跳轉(zhuǎn)前必須確保調(diào)度器已停止、所有任務(wù)已刪除、SysTick已關(guān)閉。否則跳進(jìn)應(yīng)用后應(yīng)用的調(diào)度器剛初始化舊任務(wù)的上下文還掛在中斷里隨時(shí)可能出詭異問(wèn)題。5.4 思考題四RTOS的啟動(dòng)流程和裸機(jī)啟動(dòng)流程本質(zhì)差異在哪里這道題更開(kāi)放一些我給一個(gè)參考答案框架。裸機(jī)啟動(dòng)流程核心是從復(fù)位向量到main函數(shù)講的是把C語(yǔ)言運(yùn)行環(huán)境準(zhǔn)備好、把硬件初始化好然后程序順序執(zhí)行。它的主線是線性的先準(zhǔn)備環(huán)境再執(zhí)行用戶邏輯邏輯跑完就死循環(huán)或返回。RTOS啟動(dòng)流程核心是先建內(nèi)核再開(kāi)調(diào)度。在進(jìn)入main之前或進(jìn)入main之后系統(tǒng)要完成內(nèi)核對(duì)象的創(chuàng)建——調(diào)度器、定時(shí)器、信號(hào)量、隊(duì)列等——然后創(chuàng)建第一個(gè)任務(wù)通常是main線程或startup線程最后啟動(dòng)調(diào)度器。一旦調(diào)度器啟動(dòng)代碼的主體就不再是用戶程序順序執(zhí)行而是由調(diào)度器根據(jù)優(yōu)先級(jí)和時(shí)間片決定哪個(gè)任務(wù)在哪個(gè)時(shí)刻執(zhí)行。這兩個(gè)流程的本質(zhì)差異我覺(jué)得可以這樣概括裸機(jī)啟動(dòng)的最終目標(biāo)是跑用戶代碼RTOS啟動(dòng)的最終目標(biāo)是啟動(dòng)調(diào)度器讓用戶代碼以任務(wù)的形式并發(fā)運(yùn)行。這個(gè)差異帶來(lái)了一系列連鎖反應(yīng)裸機(jī)程序里全局變量隨便用RTOS里要考慮多任務(wù)并發(fā)訪問(wèn)的互斥問(wèn)題。裸機(jī)里中斷處理函數(shù)可以做很多事只要改全局變量RTOS里中斷處理函數(shù)要盡量短更多要做的是發(fā)消息給任務(wù)讓任務(wù)去處理。裸機(jī)里主循環(huán)就是程序的全部RTOS里主循環(huán)只是一個(gè)優(yōu)先級(jí)最低的任務(wù)隨時(shí)可能被搶占。如果你從裸機(jī)轉(zhuǎn)RTOS最先要扭轉(zhuǎn)的不是API用法而是這個(gè)思維模型你已經(jīng)不是在寫(xiě)一個(gè)程序而是在管理一組并發(fā)任務(wù)。代碼質(zhì)量評(píng)估標(biāo)準(zhǔn)隨之變了——不再是邏輯是否正確而是任務(wù)間的協(xié)作是否安全、是否高效。6. 從專欄連載到工作實(shí)戰(zhàn)我的幾點(diǎn)經(jīng)驗(yàn)總結(jié)寫(xiě)這個(gè)專欄的過(guò)程其實(shí)就是我把自己多年做嵌入式底層的經(jīng)驗(yàn)重新梳理一遍的過(guò)程。很多知識(shí)平時(shí)用的時(shí)候覺(jué)得只是常識(shí)真正要寫(xiě)成系統(tǒng)性的文章時(shí)才發(fā)現(xiàn)很多細(xì)節(jié)從前只是得過(guò)且過(guò)的理解——比如U-Boot為什么要分兩個(gè)階段比如Reset_Handler里那一大段匯編到底每行在干嘛。第一個(gè)建議把啃啟動(dòng)代碼當(dāng)成必修課而不是選修課。無(wú)論你做裸機(jī)還是RTOS無(wú)論是MCU還是SoC花一個(gè)完整的時(shí)間段把廠家提供的啟動(dòng)文件、鏈接腳本一行一行讀明白比刷十篇應(yīng)用層框架文章都值。你以后遇到的80%的疑難雜癥都能回溯到這個(gè)階段。第二個(gè)建議每個(gè)項(xiàng)目都要有一個(gè)多級(jí)打印的啟動(dòng)日志體系。從開(kāi)機(jī)到正常運(yùn)行的每個(gè)關(guān)鍵階段都設(shè)置不同級(jí)別的日志輸出線上出問(wèn)題后哪怕只拿回一段串口日志你也大概率能判斷問(wèn)題出在哪個(gè)模塊。我見(jiàn)過(guò)太多項(xiàng)目量產(chǎn)之后的日志系統(tǒng)被精簡(jiǎn)得干干凈凈現(xiàn)場(chǎng)出問(wèn)題時(shí)連一點(diǎn)排查線索都沒(méi)有。省那幾KB Flash往往得不償失。第三個(gè)建議OTA不是功能是系統(tǒng)設(shè)計(jì)。別等產(chǎn)品量產(chǎn)出問(wèn)題后才想要不要加個(gè)升級(jí)功能。在項(xiàng)目架構(gòu)設(shè)計(jì)階段就要規(guī)劃好分區(qū)、Bootloader、升級(jí)協(xié)議、回滾策略。等設(shè)備鋪了幾千臺(tái)再想改啟動(dòng)機(jī)制成本完全不是一個(gè)量級(jí)。說(shuō)了這么多還是那句話嵌入式這個(gè)行當(dāng)沒(méi)有捷徑但有很多前人踩過(guò)的坑可以避開(kāi)。上面這些內(nèi)容如果你能吸收一半并且在下一個(gè)項(xiàng)目里實(shí)際用上相信你也會(huì)感受到那種從只會(huì)點(diǎn)燈到能hold住整個(gè)系統(tǒng)的質(zhì)變。