1. 啟動(dòng)流程深度拆解從CPU上電到main函數(shù)之間到底發(fā)生了什么先拋一個(gè)問題。做嵌入式開發(fā)的朋友應(yīng)該都有這種感覺點(diǎn)開調(diào)試器點(diǎn)擊全速運(yùn)行程序總能跑到main函數(shù)里好像這是天經(jīng)地義的事。但如果你真去追問一句——CPU上電之后的第一條指令是從哪里取的棧指針是誰設(shè)置的全局變量又是誰幫你初始化的——很多人都答不上來。這不是基礎(chǔ)不基礎(chǔ)的問題而是這些內(nèi)容平時(shí)被編譯器、啟動(dòng)文件和芯片廠商的SDK層層封裝藏得太深了。真正做固件開發(fā)做到一定深度尤其是開始調(diào)啟動(dòng)異常、做OTA、做單片機(jī)安全啟動(dòng)的時(shí)候這層窗戶紙就必須捅破。這一篇我就把這個(gè)過程完整拆開來講從ARM Cortex-M系列最典型的啟動(dòng)路徑說起再對(duì)比MCU和帶MMU的SoC在啟動(dòng)上的差異最后聊幾個(gè)我在實(shí)際項(xiàng)目中踩過的啟動(dòng)階段的坑。內(nèi)容會(huì)偏實(shí)操盡量用大家都見過的工程場(chǎng)景來說話。1.1 中斷向量表、啟動(dòng)文件與第一行代碼的真實(shí)來源很多人第一次接觸“啟動(dòng)流程”是在Keil或者IAR里看到startup_stm32f407xx.s這個(gè)匯編文件。它的開頭是一張表上面依次排列著__initial_sp、Reset_Handler、NMI_Handler、HardFault_Handler等等。這張表就是中斷向量表的關(guān)鍵它的布局和Cortex-M內(nèi)核的硬件設(shè)計(jì)是嚴(yán)格對(duì)應(yīng)的。Cortex-M內(nèi)核復(fù)位后硬件會(huì)自動(dòng)完成兩件事從地址0x00000000處加載主棧指針MSP的初始值從地址0x00000004處加載復(fù)位向量也就是Reset_Handler的地址然后跳過去執(zhí)行。這里就有很多人忽略的細(xì)節(jié)不同的芯片廠商會(huì)把Flash映射到不同的地址STM32默認(rèn)是0x08000000但Cortex-M內(nèi)核復(fù)位后仍然是從0x00000000去取向量表的。芯片內(nèi)部之所以能正常工作是因?yàn)镕lash的0x08000000地址被同時(shí)映射到了別名區(qū)0x00000000在芯片出廠時(shí)就已經(jīng)由硬件完成了這種重映射邏輯。所以你去查啟動(dòng)文件__initial_sp的值通常是RAM的末尾地址比如0x20020000而Reset_Handler的地址在0x08000000附近。硬件把這套關(guān)聯(lián)關(guān)系定死了你只要把兩張表的前兩個(gè)word放對(duì)位置CPU就能自動(dòng)完成初始化。這也是為什么“把一張完整的向量表放在Flash頭部”是所有嵌入式固件的基本素養(yǎng)。Reset_Handler里做的事情才是固件啟動(dòng)的核心。絕大多數(shù)廠商的啟動(dòng)文件會(huì)在這個(gè)Handler里按順序做以下幾件事先把.data段從Flash拷貝到RAM.data段里存放的是已初始化的全局變量接著把.bss段清零該段存放的是未初始化或默認(rèn)置零的全局變量然后調(diào)用SystemInit這個(gè)函數(shù)一般由芯片廠商封裝負(fù)責(zé)配置Flash等待周期、時(shí)鐘樹、PLL之類的底層環(huán)境最后才調(diào)用__main在ARMCC里或者entry在GCC里由C運(yùn)行時(shí)庫完成C環(huán)境的建立最終進(jìn)入main。很多從Linux應(yīng)用開發(fā)轉(zhuǎn)過來的朋友第一次看這個(gè)過程會(huì)不習(xí)慣因?yàn)樵趹?yīng)用層你完全不需要關(guān)心這些。但在MCU里啟動(dòng)文件就是整個(gè)固件的地基地基不穩(wěn)后面全是隱患。比如你在啟動(dòng)文件里漏掉了.bss段的清零操作所有默認(rèn)值為0的全局變量就可能是隨機(jī)值而且這個(gè)問題通常特別隱蔽它不會(huì)直接崩潰而是在業(yè)務(wù)跑起來之后以非常奇怪的行為方式暴露出來。1.2 MCU與帶MMU的SoC在啟動(dòng)路徑上的關(guān)鍵差異雖然標(biāo)題講的是嵌入式固件但很多做MCU的人會(huì)逐漸過渡到帶操作系統(tǒng)的平臺(tái)所以有必要把MCU和SoC的啟動(dòng)差異講清楚。舉一個(gè)大家比較熟悉的場(chǎng)景你在STM32上裸機(jī)開發(fā)上電后從Flash取指令就能跑但你在樹莓派或者全志、瑞芯微這些板子上BootROM先于任何用戶代碼運(yùn)行它負(fù)責(zé)從SD卡或者eMMC里加載引導(dǎo)程序然后一級(jí)一級(jí)跳轉(zhuǎn)。這種差異本質(zhì)上是架構(gòu)設(shè)計(jì)取向不同。MCU的內(nèi)部Flash可以映射到固定地址上電即可取指執(zhí)行所以啟動(dòng)路徑特別短SoC為了靈活支持從SD卡、USB、網(wǎng)絡(luò)、eMMC等多種介質(zhì)啟動(dòng)但片上存儲(chǔ)太少或者壓根沒有必須由BootROM先初始化最基本的存儲(chǔ)接口然后按順序去探測(cè)啟動(dòng)介質(zhì)。這個(gè)探測(cè)順序就是大家熟悉的“啟動(dòng)撥碼開關(guān)”對(duì)應(yīng)的邏輯。另一個(gè)重大差異是地址映射和MMU的處理。MCU啟動(dòng)階段沒有虛擬地址的概念所有地址都是物理地址指針是多少就是多少直接訪問。SoC則會(huì)在引導(dǎo)過程中逐步打開MMU開啟指令緩存、數(shù)據(jù)緩存把DDR的物理地址映射到虛擬地址空間里運(yùn)行。如果你在做引導(dǎo)程序相關(guān)開發(fā)就需要特別留意這個(gè)臨界點(diǎn)MMU尚未開啟時(shí)訪問外設(shè)寄存器必須使用物理地址而MMU開啟后代碼和數(shù)據(jù)引用的是虛擬地址此時(shí)再去訪問物理外設(shè)地址就會(huì)觸發(fā)異常除非做了映射或使用固定的設(shè)備映射區(qū)域。拿我實(shí)際調(diào)過的一塊板子為例它的BootROM先初始化了DDR控制器然后把U-Boot從eMMC加載到DDRU-Boot啟動(dòng)后會(huì)重新初始化一遍DDR控制器和MMU頁表。這中間就有一個(gè)經(jīng)典的問題如果U-Boot階段調(diào)試串口打印正常但跳到內(nèi)核后串口打印亂碼或者直接無輸出通常不是串口驅(qū)動(dòng)本身的問題而是控制臺(tái)設(shè)備樹里設(shè)置的時(shí)鐘頻率和U-Boot階段初始化出來的時(shí)鐘頻率不一致。CPU主頻變了串口的波特率分頻系數(shù)就變了信息就花了。這種問題放在啟動(dòng)流程的語境下去看往往一下就能定位到。1.3 啟動(dòng)階段容易被忽略的工程排查點(diǎn)啟動(dòng)階段的問題排查和運(yùn)行時(shí)的問題是兩種完全不同的思路。運(yùn)行時(shí)出了問題你可以掛調(diào)試器、看日志、抓現(xiàn)場(chǎng)但啟動(dòng)階段如果連調(diào)試器都連不上、串口連一句打印都沒有那才是真正的“兩眼一抹黑”。我自己的習(xí)慣是收到一塊新板子或者說拿到一個(gè)陌生固件的時(shí)候先按四條線去查啟動(dòng)問題第一電源和復(fù)位時(shí)序。MCU的NRST引腳如果在啟動(dòng)瞬間被外部的RC電路拉低太久單片機(jī)就會(huì)一直卡在復(fù)位狀態(tài)你燒錄器連上了也會(huì)提示“no target connected”。很多看似復(fù)雜的問題最后查出來就是復(fù)位電路電容值選得偏大復(fù)位時(shí)間拉長(zhǎng)到了幾百毫秒而你的看門狗芯片等不及就把電源拉斷了。第二時(shí)鐘電路是否起振。對(duì)需要外部晶振的MCU來說如果晶振沒起振單片機(jī)內(nèi)部會(huì)一直等待HSE就緒卡在SystemInit里出不來。用示波器直接測(cè)晶振引腳是最快的方式如果看到的是直流電平而不是正弦波基本可以確定是晶振虛焊、負(fù)載電容不匹配或者晶振本身損壞。第三啟動(dòng)引腳的電平配置。很多MCU有BOOT0、BOOT1引腳如果配置成了從SRAM啟動(dòng)或者從系統(tǒng)存儲(chǔ)器啟動(dòng)而你期望的是從主Flash啟動(dòng)那程序自然跑不起來。這個(gè)我在實(shí)際項(xiàng)目中真的遇到過樣機(jī)階段飛線沒拔干凈BOOT0被拉高導(dǎo)致從系統(tǒng)存儲(chǔ)器啟動(dòng)進(jìn)入了BootROM模式看起來像固件損壞了實(shí)際上只是引腳電平不對(duì)。第四向量表偏移。如果你把應(yīng)用程序放在Flash的偏移地址啟動(dòng)比如Bootloader占用了0x08000000App放在0x08008000那么App里的向量表就也必須跟著偏移否則芯片復(fù)位后仍然從0x08000000取向量表取到的是Bootloader的Reset_Handler于是App就永遠(yuǎn)啟動(dòng)不了。Cortex-M提供了VTOR寄存器來設(shè)置向量表偏移幾乎所有的Bootloader側(cè)代碼都會(huì)在進(jìn)入App前設(shè)置好這個(gè)寄存器。這個(gè)點(diǎn)非常重要后面講OTA升級(jí)的時(shí)候還會(huì)再提到。2. 故障定位方法論嵌入式固件最該練的排查本領(lǐng)接下來聊一個(gè)比寫代碼更重要的能力——故障定位。嵌入式開發(fā)和純軟件開發(fā)有一個(gè)非常大的不同純軟件出Bug最壞情況是服務(wù)崩潰你還能拿核心轉(zhuǎn)儲(chǔ)去分析嵌入式固件出Bug輕則功能異常重則產(chǎn)線停線、設(shè)備變磚。而且嵌入式現(xiàn)場(chǎng)往往沒有IDE、沒有調(diào)試器、沒有完整的日志系統(tǒng)你只有一塊跑飛了的板子和一臉懵的客戶反饋。所以我覺得一個(gè)嵌入式工程師從初級(jí)到高級(jí)的分水嶺不在于你背了多少芯片手冊(cè)而在于遇到一個(gè)棘手問題時(shí)你有沒有一套穩(wěn)定高效的排查方法論。這一章我會(huì)把我在實(shí)際項(xiàng)目中反復(fù)用到的故障定位框架分享出來它不玄學(xué)每一步都有明確的輸出物和判斷依據(jù)。2.1 先給故障分門別類不要拿到Bug就悶頭查很多人拿到問題的第一反應(yīng)是打開代碼從頭到尾讀一遍試圖用肉眼找到Bug。但說實(shí)話對(duì)于編譯期能暴露的問題編譯器早就幫你抓了而運(yùn)行期的問題光看代碼是找不出真相的它更像一個(gè)系統(tǒng)性的證據(jù)收集過程。我的做法是先把故障按現(xiàn)象分成幾類第一類是“確定性崩潰”也就是只要跑到某一段代碼就必死比如空指針解引用、數(shù)組越界寫壞了相鄰內(nèi)存、硬件外設(shè)未初始化就使用。這種問題通常有穩(wěn)定的復(fù)現(xiàn)路徑掛上調(diào)試器看HardFault的現(xiàn)場(chǎng)基本都能揪出來。第二類是“間歇性故障”它可能跑幾小時(shí)才出現(xiàn)一次或者跟溫度、電壓、電磁干擾有關(guān)。這種問題最折磨人因?yàn)樗蛔裱?jiǎn)單的因果邏輯往往需要長(zhǎng)時(shí)間抓記錄、加日志、做壓力復(fù)現(xiàn)才能有所突破。第三類是“狀態(tài)錯(cuò)誤”程序沒有崩潰但功能表現(xiàn)不對(duì)比如屏幕花屏、通信報(bào)文丟字節(jié)、傳感器讀值亂跳。這類問題通常指向狀態(tài)機(jī)跑偏、DMA緩沖區(qū)競(jìng)爭(zhēng)、外設(shè)配置不對(duì)等方向。分好類之后定位方向就完全不同了。確定性崩潰可以快速上調(diào)試器間歇性故障需要先構(gòu)建壓力環(huán)境和監(jiān)控體系狀態(tài)錯(cuò)誤則需要先從數(shù)據(jù)結(jié)構(gòu)、狀態(tài)機(jī)的角度去審查代碼邏輯。盲目地從頭讀代碼效率往往是最低的。2.2 HardFault現(xiàn)場(chǎng)分析從寄存器反推崩潰原因的標(biāo)準(zhǔn)姿勢(shì)說到崩潰定位HardFault估計(jì)是Cortex-M開發(fā)者最熟悉的異常了。程序一跑飛就進(jìn)了HardFault_Handler然后死循環(huán)。很多初學(xué)者到這里就懵了其實(shí)HardFault并不可怕關(guān)鍵是你會(huì)不會(huì)讀現(xiàn)場(chǎng)。當(dāng)Cortex-M處理器發(fā)生HardFault時(shí)內(nèi)核會(huì)自動(dòng)把一部分寄存器壓入當(dāng)前棧中包括R0、R1、R2、R3、R12、LR、PC、xPSR。這些寄存器就是破案的關(guān)鍵線索。你可以從HardFault_Handler里讀出當(dāng)前使用的棧指針判斷是MSP還是PSP然后從棧上把這些寄存器的值恢復(fù)出來。PC就是觸發(fā)異常的指令地址LR是調(diào)用關(guān)系里的返回地址這兩個(gè)值基本能把你引導(dǎo)到出錯(cuò)的函數(shù)。舉個(gè)例子我調(diào)過一個(gè)問題固件在跑了一段時(shí)間后進(jìn)入HardFault崩潰點(diǎn)看似隨機(jī)?；謴?fù)現(xiàn)場(chǎng)后發(fā)現(xiàn)PC值指向了某個(gè)外設(shè)庫函數(shù)內(nèi)部而LR指向的是調(diào)用它的業(yè)務(wù)代碼。再往下一看R0的值是一個(gè)外設(shè)句柄的地址那是一個(gè)全局結(jié)構(gòu)體指針正常情況下是不應(yīng)該為空的。繼續(xù)排查發(fā)現(xiàn)這個(gè)全局結(jié)構(gòu)體是由某個(gè)初始化函數(shù)創(chuàng)建的但該函數(shù)在另一次初始化流程中被提前返回了導(dǎo)致指針一直是NULL。到了業(yè)務(wù)代碼實(shí)際使用它時(shí)訪問了地址0觸發(fā)總線錯(cuò)誤最終進(jìn)HardFault。整個(gè)過程看起來像隨機(jī)崩潰其實(shí)只要學(xué)會(huì)讀現(xiàn)場(chǎng)邏輯鏈?zhǔn)呛芮宄?。還有一個(gè)非常典型的場(chǎng)景棧溢出導(dǎo)致的HardFault。Cortex-M的棧指針一旦越界訪問了無效地址同樣會(huì)觸發(fā)總線錯(cuò)誤。你在現(xiàn)場(chǎng)讀出的SP如果非常接近RAM的邊界而且?；厮莺驼Ｕ{(diào)用鏈明顯對(duì)不上那基本可以判定就是棧溢出。這種問題在RTOS環(huán)境下要額外檢查任務(wù)棧是否分配足夠很多RTOS都會(huì)提供任務(wù)棧高水位標(biāo)記的鉤子函數(shù)建議從一開始就打開這個(gè)功能提前發(fā)現(xiàn)棧吃緊的任務(wù)。2.3 一套可復(fù)用的排查流程與日志設(shè)計(jì)經(jīng)驗(yàn)故障定位有沒有一套通用的流程我的答案是有的而且它相當(dāng)樸素可能是大家都會(huì)說但很少堅(jiān)持做完整的東西第一步確認(rèn)環(huán)境。硬件版本、軟件版本、供電方式、外接設(shè)備、溫度濕度這些信息先記錄下來。很多時(shí)候Bug只出現(xiàn)在某個(gè)硬件版本的某個(gè)批次的板子上如果不記錄環(huán)境信息你會(huì)在錯(cuò)誤的代碼上浪費(fèi)大量時(shí)間。第二步盡量縮小復(fù)現(xiàn)范圍。如果每次都在執(zhí)行某條特定命令后崩潰就把這條命令單獨(dú)拎出來跑。如果崩潰發(fā)生在特定外設(shè)通信過程中就嘗試關(guān)掉DMA改成輪詢方式接收看問題是否消失。這叫二分法隔離變量。第三步加入可觀測(cè)性。所謂可觀測(cè)性就是你得讓程序把“自己正在干什么、干到了哪一步”給暴露出來。最簡(jiǎn)單的做法就是串口日志稍微進(jìn)階一點(diǎn)就是用SEGGER RTT不占串口且速度快再進(jìn)階就是使用ITM/SWO輸出調(diào)試器能全速抓取。我的經(jīng)驗(yàn)是日志輸出必須分等級(jí)并且上線版本要把DEBUG級(jí)別的日志關(guān)掉或者用條件編譯剔除否則日志本身的時(shí)序會(huì)掩蓋定時(shí)類Bug的復(fù)現(xiàn)。第四步用調(diào)試器抓現(xiàn)場(chǎng)。掛上調(diào)試器等它進(jìn)入異常斷點(diǎn)然后讀取PC、LR、棧上的殘留數(shù)據(jù)。注意不要輕易復(fù)位因?yàn)閺?fù)位會(huì)把所有現(xiàn)場(chǎng)證據(jù)都清掉。我在項(xiàng)目里經(jīng)常是讓HardFault_Handler里做一個(gè)死循環(huán)加一個(gè)脈沖翻轉(zhuǎn)方便在下位機(jī)接入示波器時(shí)確認(rèn)是否真的進(jìn)了異常。日志這塊我再多說兩句。嵌入式固件的日志不能像寫應(yīng)用一樣隨意要把日志設(shè)計(jì)和狀態(tài)機(jī)設(shè)計(jì)結(jié)合起來。我常用的做法是定義一個(gè)統(tǒng)一的日志模塊支持模塊編號(hào)和等級(jí)兩個(gè)維度。模塊編號(hào)用于過濾、等級(jí)用于控制輸出量。每條日志建議帶上單調(diào)遞增的計(jì)數(shù)器這樣哪怕沒有時(shí)間戳也能推斷出各事件之間的先后順序。另外一個(gè)重點(diǎn)是上線版本一定要把printf重定向到RTT或Flash記錄而不是簡(jiǎn)單地從串口刪除。因?yàn)楝F(xiàn)場(chǎng)出問題時(shí)串口是完全不可用的你根本沒有機(jī)會(huì)插上串口線。3. OTA升級(jí)工程化實(shí)戰(zhàn)從原理到量產(chǎn)的全鏈路設(shè)計(jì)OTA升級(jí)是嵌入式固件進(jìn)階繞不開的硬骨頭。我見過太多團(tuán)隊(duì)功能開發(fā)得飛起一到OTA就翻車升級(jí)過程中斷電了設(shè)備變磚升級(jí)包校驗(yàn)沒做好寫入了損壞的鏡像分區(qū)規(guī)劃不合理Bootloader和App的空間互相擠壓更常見的是升級(jí)到一半發(fā)現(xiàn)新版本本身有Bug想回退卻根本沒有回退機(jī)制。OTA這個(gè)東西表面看就是把新固件下載到Flash里然后跳轉(zhuǎn)過去跑。但真要做得可靠需要考慮的問題遠(yuǎn)比想象得多分區(qū)怎么劃分、升級(jí)包怎么校驗(yàn)、Bootloader怎么跳轉(zhuǎn)、失敗怎么回滾、廣播域怎么控制、弱網(wǎng)下怎么續(xù)傳、設(shè)備電池容量夠不夠支撐一次升級(jí)。這一章我從工程化落地的角度把整條鏈路講透徹。3.1 兩類主流升級(jí)架構(gòu)與適用場(chǎng)景談OTA升級(jí)一定先談升級(jí)架構(gòu)。沒有架構(gòu)的OTA就是耍流氓。我在實(shí)際項(xiàng)目里見過兩種主流方案它們各有勝負(fù)關(guān)鍵看你的產(chǎn)品形態(tài)。第一種是整體鏡像升級(jí)也就是設(shè)備只有一個(gè)App分區(qū)升級(jí)時(shí)把整片App區(qū)數(shù)據(jù)全部替換掉。這種方案實(shí)現(xiàn)簡(jiǎn)單占用Flash小成本低適合存儲(chǔ)資源非常緊張的單芯片方案比如很多8位MCU或者低成本的Cortex-M0方案。它的缺點(diǎn)也很明顯升級(jí)過程中一旦斷電或?qū)懭氘惓Ｕ麎KApp區(qū)就是不可用的設(shè)備直接變磚。第二種是A/B雙分區(qū)方案。Flash里放兩份App鏡像一份當(dāng)前運(yùn)行在A區(qū)另一份空閑的B區(qū)。升級(jí)時(shí)把新鏡像寫入B區(qū)寫完校驗(yàn)通過后把啟動(dòng)標(biāo)志翻轉(zhuǎn)下次啟動(dòng)Bootloader加載B區(qū)。如果B區(qū)啟動(dòng)失敗或者校驗(yàn)不通過Bootloader會(huì)自動(dòng)回滾到A區(qū)。這種方案最大的優(yōu)點(diǎn)是安全性極高幾乎沒有“變磚”的可能性代價(jià)是Flash占用翻倍對(duì)存儲(chǔ)要求高。目前很多車規(guī)、醫(yī)療、物聯(lián)網(wǎng)網(wǎng)關(guān)產(chǎn)品都傾向用這種方案一套Bootloader代碼自身可以保持極簡(jiǎn)把安全性放在架構(gòu)這一層去保證。還有一種是介于兩者之間的“雙備份恢復(fù)區(qū)”設(shè)計(jì)App區(qū)之外單獨(dú)劃一個(gè)極小的高可靠恢復(fù)區(qū)里面只放一個(gè)能接收新固件的最小引導(dǎo)程序。正常升級(jí)流程和整體鏡像升級(jí)一樣只不過把升級(jí)工具和恢復(fù)引導(dǎo)拆開。當(dāng)升級(jí)失敗導(dǎo)致App不可用時(shí)恢復(fù)區(qū)接管通過通信接口重新接收固件。這種方案兼顧了Flash占用和安全性我在一些NB-IoT和低功耗廣域物聯(lián)網(wǎng)設(shè)備上用過效果也很不錯(cuò)。核心區(qū)別就是當(dāng)設(shè)備出問題時(shí)業(yè)務(wù)仍然能恢復(fù)而不是需要拆機(jī)燒錄。3.2 分區(qū)規(guī)劃與地址映射這一步錯(cuò)了后面全亂不管是哪種升級(jí)架構(gòu)分區(qū)規(guī)劃都是第一步。以一塊帶512KB Flash的MCU為例我會(huì)大致這么規(guī)劃Bootloader區(qū)放32KBApp區(qū)放240KB升級(jí)緩存區(qū)放240KB參數(shù)存儲(chǔ)區(qū)放4KB剩余預(yù)留。具體大小要根據(jù)你的Bootloader復(fù)雜度和App大小來調(diào)但有幾個(gè)原則是通用的。第一Bootloader區(qū)必須放在Flash起始地址因?yàn)樾酒瑥?fù)位后是從起始地址取中斷向量表的這個(gè)沒辦法繞開。第二App區(qū)必須按向量表對(duì)齊通常就是Flash最小擦除塊的整數(shù)倍否則后續(xù)生成打包文件時(shí)地址對(duì)不上。第三把參數(shù)存儲(chǔ)單獨(dú)劃區(qū)不要和App共享Flash扇區(qū)。因?yàn)閰?shù)區(qū)修改頻繁如果和代碼混在一起每一次參數(shù)寫入都可能觸發(fā)扇區(qū)擦寫極大增加代碼區(qū)Flash的磨損嚴(yán)重時(shí)直接破壞代碼。你想想看正常老化測(cè)試跑幾個(gè)月參數(shù)區(qū)寫了幾萬次好端端的不用OTA程序就壞了這鍋只能甩給自己。地址映射這塊推薦一開始就把所有區(qū)域的定義做成統(tǒng)一的頭文件比如memory_map.hBootloader和App編譯時(shí)都引用這一份定義。千萬不要在Bootloader里手寫一遍App起始地址、又在App工程里再手寫一遍Bootloader大小兩邊一旦不一致后面查起來會(huì)懷疑人生。我在一個(gè)A/B雙分區(qū)的項(xiàng)目里就把A區(qū)、B區(qū)、升級(jí)緩存區(qū)、參數(shù)區(qū)、Bootloader區(qū)的起始地址和大小全部做成宏定義兩邊共用后來驗(yàn)證跳轉(zhuǎn)時(shí)省了至少一天的聯(lián)調(diào)時(shí)間。3.3 升級(jí)流程的狀態(tài)機(jī)設(shè)計(jì)與異常兜底OTA升級(jí)的流程看起來簡(jiǎn)單但工程化的核心在于狀態(tài)機(jī)的設(shè)計(jì)。我會(huì)把一個(gè)完整的升級(jí)過程拆成這么幾個(gè)狀態(tài)空閑態(tài)、下載態(tài)、校驗(yàn)態(tài)、寫入態(tài)、待生效態(tài)、回滾態(tài)。每個(gè)狀態(tài)之間跳轉(zhuǎn)的條件必須明確并且每個(gè)狀態(tài)都要能處理意外情況。以A/B分區(qū)方案為例升級(jí)過程大致是這樣設(shè)備從云平臺(tái)或手機(jī)App收到升級(jí)通知進(jìn)入下載態(tài)把新固件分塊寫入B區(qū)對(duì)應(yīng)的Flash地址。下載過程中每寫一包都要做CRC校驗(yàn)校驗(yàn)失敗可以請(qǐng)求重傳但重傳次數(shù)要有限制一般是3次超過就終止本次升級(jí)回到空閑態(tài)。整個(gè)固件下載完成后進(jìn)入校驗(yàn)態(tài)對(duì)整個(gè)B區(qū)鏡像計(jì)算哈希值或數(shù)字簽名。校驗(yàn)通過后進(jìn)入待生效態(tài)再寫一個(gè)標(biāo)志位告訴Bootloader下次啟動(dòng)嘗試加載B區(qū)。這個(gè)“寫標(biāo)志”的動(dòng)作很關(guān)鍵它必須在所有升級(jí)數(shù)據(jù)都落盤且校驗(yàn)通過之后才能做。很多方案在這里會(huì)多設(shè)計(jì)一個(gè)步驟讓設(shè)備先重啟一次Bootloader嘗試啟動(dòng)B區(qū)但App啟動(dòng)代碼在正常運(yùn)行一段時(shí)間后如果檢測(cè)到硬件看門狗沒有被正常喂狗或者健康檢查失敗會(huì)主動(dòng)把啟動(dòng)標(biāo)志改回A區(qū)并再次重啟。這種機(jī)制做的就是把“瞬時(shí)校驗(yàn)”升級(jí)為“運(yùn)行期校驗(yàn)”可以有效防止“新固件雖然能啟動(dòng)但隨后死機(jī)”的情況。車規(guī)領(lǐng)域很多方案都采用這種雙保險(xiǎn)設(shè)計(jì)工程實(shí)踐也證明它的魯棒性遠(yuǎn)比單純依賴上電校驗(yàn)要高得多。另外一個(gè)容易被忽視的點(diǎn)是整個(gè)升級(jí)過程必須考慮功率預(yù)算。本來正常的設(shè)備待機(jī)電流是微安級(jí)優(yōu)化得好一點(diǎn)可能能用兩三年但如果你在低電量時(shí)啟動(dòng)一次固件下載無線模塊全功率發(fā)射瞬間就把電池拉垮了。所以O(shè)TA的功能必須增加一個(gè)電量門檻低于某個(gè)閾值時(shí)不允許升級(jí)或者要求必須插著充電器。這個(gè)在電池類設(shè)備上是硬性需求不是可選項(xiàng)。3.4 升級(jí)過程中的安全校驗(yàn)與簽名機(jī)制OTA升級(jí)如果只做CRC32校驗(yàn)?zāi)沁€遠(yuǎn)遠(yuǎn)不夠。CRC32只能檢測(cè)數(shù)據(jù)傳輸過程中的隨機(jī)錯(cuò)誤它無法防止惡意篡改。現(xiàn)在的物聯(lián)網(wǎng)設(shè)備暴露在公網(wǎng)環(huán)境固件被篡改后的危害是很大的。所以工程化的OTA升級(jí)一定要引入簽名校驗(yàn)機(jī)制核心思路是固件在廠商側(cè)簽名設(shè)備側(cè)驗(yàn)簽驗(yàn)簽通過才允許寫入和啟動(dòng)。常見的做法是對(duì)整個(gè)固件鏡像做哈希計(jì)算然后廠商用私鑰對(duì)哈希結(jié)果進(jìn)行非對(duì)稱簽名設(shè)備側(cè)內(nèi)置公鑰升級(jí)時(shí)先用公鑰驗(yàn)證簽名是否匹配。只要私鑰不泄露攻擊者就算拿到了你的固件包也沒有辦法制作出簽名合法的惡意固件。這種做法在車規(guī)和金融支付領(lǐng)域已經(jīng)是標(biāo)配。不過引入簽名校驗(yàn)后會(huì)帶來另一個(gè)問題就是數(shù)字簽名和哈希算法的計(jì)算時(shí)間。在低主頻MCU上計(jì)算一個(gè)SHA-256如果是幾十KB的小鏡像還能接受但對(duì)幾百KB甚至幾MB的固件全量計(jì)算的耗時(shí)可能會(huì)達(dá)到幾十秒升級(jí)的用戶體驗(yàn)就很差。我的經(jīng)驗(yàn)是分塊簽名把固件分成多個(gè)塊每塊單獨(dú)簽名下載完成后按塊驗(yàn)證簽名即驗(yàn)即寫這樣既避免了一次全量計(jì)算帶來的長(zhǎng)時(shí)間等待也能在發(fā)現(xiàn)某一包被篡改時(shí)及時(shí)停止寫入。安全這塊我再提醒一句千萬不要只驗(yàn)證簽名不驗(yàn)證版本號(hào)。曾經(jīng)有團(tuán)隊(duì)在升級(jí)流程里漏了版本號(hào)校驗(yàn)結(jié)果設(shè)備往舊版本降級(jí)了而舊版本存在安全漏洞整批設(shè)備就變成了可被遠(yuǎn)程利用的狀態(tài)。版本號(hào)校驗(yàn)邏輯雖然簡(jiǎn)單但它和簽名校驗(yàn)一樣重要屬于OTA設(shè)計(jì)里不可分割的一部分。4. 上篇課后思考題完整解析順著問題把知識(shí)點(diǎn)真正吃透連載文章配上思考題是我個(gè)人比較喜歡的一種形式。因?yàn)楹芏鄸|西光看一遍以為自己懂了但真正動(dòng)手去解答或者給別人講一遍就會(huì)發(fā)現(xiàn)一堆模糊的地方。這一次上篇的課后思考題我挑選了四道覆蓋啟動(dòng)、故障定位和OTA三個(gè)方向的典型問題逐一展開解析。這四道題不偏不怪都是實(shí)際工程里反復(fù)出現(xiàn)的場(chǎng)景。4.1 題目一為什么Cortex-M的復(fù)位向量要同時(shí)占用兩個(gè)word直接放PC入口地址可不可以這道題問的其實(shí)是向量表的前兩個(gè)word到底是什么。第一個(gè)word是初始棧指針MSP第二個(gè)word才是復(fù)位向量也就是Reset_Handler的地址。對(duì)于Cortex-M內(nèi)核硬件在復(fù)位后會(huì)自動(dòng)讀取這兩個(gè)值并把它們分別寫入SP和PC。所以如果你的設(shè)備一直從復(fù)位地址啟動(dòng)而執(zhí)行流不對(duì)那大概率是向量表的前兩個(gè)word寫錯(cuò)了。更深一層的知識(shí)點(diǎn)是Cortex-M的向量表中每一項(xiàng)都是一個(gè)地址值低1位必須是1表示Thumb模式。如果你不小心把一個(gè)奇數(shù)值之外的地址寫進(jìn)了向量表程序跳轉(zhuǎn)后就會(huì)觸發(fā)UsageFault因?yàn)閮?nèi)核認(rèn)為是非法指令狀態(tài)。這類錯(cuò)誤在手動(dòng)修改鏈接腳本或做啟動(dòng)文件裁剪時(shí)特別容易出現(xiàn)。我在一次把App放在偏移地址的改造中就因?yàn)樵阪溄幽_本里把向量表的對(duì)齊邊界算錯(cuò)了導(dǎo)致跳轉(zhuǎn)到App后直接HardFault最后查看反匯編才發(fā)現(xiàn)是向量表偏移沒有生效Reset_Handler的地址和中斷向量沒對(duì)上。所以這道題的完整答案應(yīng)該是不能只放PC地址必須把SP和PC配套放好并且所有向量地址都要保持Thumb位為1。理解了這一點(diǎn)你就不會(huì)再對(duì)“為什么向量表占的Flash空間是中斷數(shù)量的4倍”感到困惑了。4.2 題目二RTOS任務(wù)棧和系統(tǒng)棧各自的溢出會(huì)有什么表現(xiàn)這道題很經(jīng)典很多項(xiàng)目死在這里。系統(tǒng)棧也叫主棧它在啟動(dòng)文件和鏈接腳本里定義通常由__initial_sp指向RAM頂部。中斷、異常、初始化調(diào)用都會(huì)使用主棧。如果你的工程使用了RTOS每個(gè)任務(wù)還有自己的任務(wù)棧使用PSP指針訪問。正常情況下任務(wù)運(yùn)行使用任務(wù)棧進(jìn)入異常后用主棧。所以系統(tǒng)棧溢出和任務(wù)棧溢出的表現(xiàn)是完全不同的。系統(tǒng)棧溢出的典型表現(xiàn)是第一次進(jìn)入某個(gè)中斷時(shí)設(shè)備直接復(fù)位或HardFault因?yàn)樵谥袛鄩簵r(shí)SP已經(jīng)越界。而且這種問題有一大特征如果你在中斷里調(diào)用了比較深的函數(shù)或者大量使用局部變量它就會(huì)出現(xiàn)如果你把中斷函數(shù)改簡(jiǎn)單了問題就消失。我在一個(gè)項(xiàng)目里遇到過串口接收中斷里解析Json導(dǎo)致主棧溢出當(dāng)時(shí)設(shè)備在長(zhǎng)時(shí)間運(yùn)行后偶發(fā)重啟排查了很久才定位到是主棧開得太小只有1KB而Json解析的局部變量棧幀動(dòng)輒就是幾百字節(jié)。任務(wù)棧溢出的表現(xiàn)則更多樣可能是某個(gè)任務(wù)跑飛、某個(gè)隊(duì)列數(shù)據(jù)被覆蓋、或者調(diào)度器行為異常。很多RTOS會(huì)提供棧溢出檢測(cè)鉤子比如FreeRTOS的configCHECK_FOR_STACK_OVERFLOW它可以在任務(wù)切換時(shí)檢查棧指針是否越界。但要注意這種檢測(cè)只能在切換時(shí)刻抓如果任務(wù)在運(yùn)行中途就溢出了必須等它切換到別的任務(wù)時(shí)才能發(fā)現(xiàn)。更穩(wěn)妥的做法是在產(chǎn)品開發(fā)階段打開任務(wù)棧高水位統(tǒng)計(jì)功能周期性地把每個(gè)任務(wù)棧的最大使用深度上報(bào)出來這樣你就能提前預(yù)判哪些任務(wù)棧偏小并在正式版本中留出足夠余量。4.3 題目三Bootloader跳轉(zhuǎn)App前需要做哪些收尾動(dòng)作這道題考察的是跳轉(zhuǎn)的完整流程很容易踩坑。很多人以為只需要把函數(shù)指針指到App的Reset_Handler然后調(diào)用一下就完事了。但工程上遠(yuǎn)遠(yuǎn)不止這些尤其是工程用到了RTOS或復(fù)雜外設(shè)時(shí)。首先進(jìn)App之前必須關(guān)閉全局中斷。跳轉(zhuǎn)過程發(fā)生在Bootloader的上下文里如果你不關(guān)中斷在跳轉(zhuǎn)瞬間中斷來了一下執(zhí)行的還是Bootloader的中斷服務(wù)函數(shù)但它訪問的設(shè)備可能已經(jīng)被App重新初始化過了這就可能產(chǎn)生不可預(yù)料的行為。關(guān)閉全局中斷通常用__disable_irq()并清掉所有掛起的中斷標(biāo)志。其次要確認(rèn)外設(shè)處于復(fù)位狀態(tài)。尤其是DMA、定時(shí)器、看門狗這類會(huì)自主運(yùn)行的設(shè)備跳轉(zhuǎn)前如果不復(fù)位它們它們可能繼續(xù)以Bootloader的配置狀態(tài)工作App里初始化時(shí)沒注意就會(huì)出錯(cuò)。硬件看門狗尤其危險(xiǎn)它會(huì)因?yàn)榈貌坏剿⑿露鴱?fù)位整個(gè)芯片導(dǎo)致“跳轉(zhuǎn)App后不停重啟”的奇怪現(xiàn)象。再次要設(shè)置好向量表偏移。前文講過App里的向量表通常按鏈接腳本放在新的Flash地址必須通過SCB-VTOR寄存器告訴內(nèi)核向量表的新位置。否則一旦發(fā)生中斷內(nèi)核仍會(huì)從舊的向量表取入口取到的還是Bootloader的中斷處理函數(shù)。最后棧指針必須重新初始化。App的啟動(dòng)文件里會(huì)定義自己的初始SP跳轉(zhuǎn)前把SP重新指向App的棧頂避免遺留的棧污染影響App的初始環(huán)境。實(shí)際操作時(shí)從向量表第一個(gè)word讀取MSP值寫入SP再從第二個(gè)word讀取Reset_Handler地址然后切換到Thumb模式跳轉(zhuǎn)過去。這個(gè)過程在main函數(shù)里不要返回跳轉(zhuǎn)后最好加一個(gè)死循環(huán)防止異常路徑回來。4.4 題目四OTA升級(jí)失敗后如何設(shè)計(jì)一套可回滾的兜底策略這個(gè)問題沒有唯一的標(biāo)準(zhǔn)答案但核心目標(biāo)是明確的設(shè)備不能因?yàn)橐淮紊?jí)失敗就變磚。前面講A/B雙分區(qū)的時(shí)候其實(shí)已經(jīng)把答案說了一半這里再補(bǔ)充兩個(gè)實(shí)操中的細(xì)節(jié)。第一個(gè)細(xì)節(jié)是啟動(dòng)標(biāo)志的磨損均衡。A/B雙分區(qū)方案里Bootloader需要記錄“下一次啟動(dòng)哪個(gè)區(qū)”這個(gè)狀態(tài)如果每次升級(jí)都寫同一個(gè)Flash扇區(qū)頻繁升級(jí)會(huì)把這個(gè)扇區(qū)寫穿。工程上的做法是使用多扇區(qū)輪詢或者每個(gè)升級(jí)事件都換一個(gè)新地址記錄Bootloader通過地址和時(shí)間戳來判斷哪條是最新的啟動(dòng)記錄。這種設(shè)計(jì)在量產(chǎn)設(shè)備上很有必要因?yàn)樵O(shè)備可能在生命周期內(nèi)升級(jí)幾十次扇區(qū)壽命必須納入考慮。第二個(gè)細(xì)節(jié)是對(duì)“啟動(dòng)成功”的定義。Bootloader判斷一個(gè)鏡像能啟動(dòng)成功不應(yīng)該只是“跳轉(zhuǎn)過去沒復(fù)位”而應(yīng)該是App正常運(yùn)行到一定階段主動(dòng)上報(bào)“我起來了”。實(shí)現(xiàn)方式可以是在App初始化末尾寫一個(gè)標(biāo)志位Bootloader在跳轉(zhuǎn)前清零這個(gè)標(biāo)志如果在設(shè)定時(shí)間內(nèi)沒有被置位說明App啟動(dòng)失敗回滾條件成立。配上外部看門狗這個(gè)機(jī)制會(huì)更可靠即使App卡在“寫標(biāo)志之前”的初始化流程里看門狗也會(huì)把芯片復(fù)位回BootloaderBootloader檢測(cè)到標(biāo)志未置位自動(dòng)回滾到舊版本。結(jié)合這些細(xì)節(jié)你會(huì)發(fā)現(xiàn)OTA的工程化設(shè)計(jì)其實(shí)并不復(fù)雜但它要求你對(duì)啟動(dòng)流程、Flash器件特性、異?；謴?fù)機(jī)制有完整的認(rèn)知。離開了這些底層的理解任何上層的升級(jí)策略都是空中樓閣。5. 一些實(shí)操中的體會(huì)與建議寫到這里我想聊聊自己這幾年做嵌入式固件的一些真實(shí)體會(huì)也算給這個(gè)連載主題做一個(gè)階段性的沉淀。第一點(diǎn)調(diào)試啟動(dòng)類問題時(shí)耐心比技巧重要。有一段時(shí)間我頻繁處理“上電沒反應(yīng)”的板子一開始總想找到某個(gè)“大招”一針見血后來發(fā)現(xiàn)最有效的工具仍然是示波器、萬用表和邏輯分析儀。測(cè)電源、測(cè)復(fù)位、測(cè)時(shí)鐘、測(cè)Boot引腳按部就班地過一遍多數(shù)問題半小時(shí)內(nèi)就能定位。很多人覺得這種排查方式太基礎(chǔ)、沒有技術(shù)含量但真正到了現(xiàn)場(chǎng)它就是你最快的保命手段。第二點(diǎn)故障定位方法論需要在平時(shí)就建立起來而不是等到Bug來了才臨時(shí)想。我建議每個(gè)嵌入式工程師都維護(hù)一份自己的排障清單內(nèi)容包括板子沒反應(yīng)查什么、串口無輸出查什么、系統(tǒng)跑飛查什么、外設(shè)不工作查什么。這份清單會(huì)隨著你的經(jīng)驗(yàn)不斷變厚它會(huì)成為你面對(duì)未知問題時(shí)最可靠的導(dǎo)航。沒有這套清單很多時(shí)候你是在靠直覺和運(yùn)氣在排查問題。第三點(diǎn)OTA升級(jí)方案要從產(chǎn)品立項(xiàng)時(shí)就納入架構(gòu)設(shè)計(jì)而不是最后功能做完了再補(bǔ)。分區(qū)是一開始就要定好的Bootloader的升級(jí)能力和回滾機(jī)制是要和硬件方案一起評(píng)審的安全簽名體系更是需要后端配合的。如果把OTA當(dāng)成一個(gè)“后面再補(bǔ)的模塊”你會(huì)發(fā)現(xiàn)它處處受制于人Flash空間不夠了、Bootloader能力不足了、通信帶寬有限了、設(shè)備端安全密鑰沒有預(yù)置進(jìn)去。這已經(jīng)不是改代碼能解決的范疇了而是架構(gòu)層面的返工代價(jià)非常大。最后再分享一個(gè)小技巧。啟動(dòng)階段和OTA階段最容易出現(xiàn)的Bug有一個(gè)共同點(diǎn)它們都和時(shí)間強(qiáng)相關(guān)。啟動(dòng)問題和上電時(shí)序強(qiáng)相關(guān)OTA問題和通信時(shí)長(zhǎng)強(qiáng)相關(guān)。所以排查這兩類問題時(shí)請(qǐng)務(wù)必在代碼里加上時(shí)間戳或者計(jì)數(shù)器的記錄哪怕只是一個(gè)簡(jiǎn)單的循環(huán)計(jì)數(shù)都能讓現(xiàn)場(chǎng)信息變得可分析。我見過太多設(shè)備死機(jī)后只剩一個(gè)“復(fù)位了”的結(jié)論沒有任何中間態(tài)記錄那后續(xù)的定位就只能靠猜。如果你的固件從一開始就把可觀測(cè)性當(dāng)成一等公民很多故障其實(shí)都可以在第一時(shí)間被鎖死。