現(xiàn)場還原程序在初始化時(shí)徹底卡死是什么表現(xiàn)先說現(xiàn)象。我最近在調(diào)一批基于STM32WLE5的LoRa節(jié)點(diǎn)設(shè)備用的協(xié)議棧是ST官方I-CUBE-LRWANCubeMX生成工程后在主循環(huán)里調(diào)用MX_LoRaWAN_Init()。代碼編譯干凈、燒錄正常但程序跑到這里就再也沒下文了——串口調(diào)試打印只有LoRaWAN init begin后面的LoRaWAN init done永遠(yuǎn)等不到。用ST-LINK連上Keil全速運(yùn)行然后點(diǎn)暫停程序計(jì)數(shù)器不偏不倚停在一個(gè)叫modem_supervisor_init()的函數(shù)內(nèi)部準(zhǔn)確說是一個(gè)while循環(huán)里。單步執(zhí)行循環(huán)體一直在轉(zhuǎn)。這個(gè)問題最有迷惑性的地方是它不報(bào)錯、不觸發(fā)HardFault、不進(jìn)Error_Handler()也沒有看門狗復(fù)位。程序就像被按了暫停鍵一樣靜靜地掛在那里。遇到這種情況很多人的第一反應(yīng)是檢查堆棧溢出或者懷疑是HAL_Delay()這類依賴SysTick的函數(shù)卡住。但堆棧檢查之后一切正常SysTick在跑LED還能正常閃爍。當(dāng)時(shí)我判斷這絕對不是隨機(jī)死機(jī)而是在某個(gè)明確的軟件邏輯點(diǎn)上主動陷入死循環(huán)。modem_supervisor_init()這個(gè)名字直譯過來是調(diào)制解調(diào)器監(jiān)管器初始化它卡住大概率是在等待什么東西而這個(gè)東西一直沒來。不管你是用NUCLEO-WL55JC官方板還是自研的最小系統(tǒng)板出現(xiàn)的現(xiàn)象基本一致。區(qū)別只在于官方板上大概率是配置被人為改動過而自研板上則要多排查一部分硬件設(shè)計(jì)問題。后面我會把這個(gè)排查鏈路完整走一遍。從代碼走查開始modem_supervisor_init()到底在哪個(gè)循環(huán)里轉(zhuǎn)2.1 協(xié)議棧調(diào)用鏈從MX_LoRaWAN_Init到modem_supervisor_init要弄懂死循環(huán)先得看清調(diào)用鏈。代碼執(zhí)行從MX_LoRaWAN_Init()這里進(jìn)入它的內(nèi)部邏輯可以簡化為下面的鏈路MX_LoRaWAN_Init() └── LoRaWAN_Init(LoRaWAN_Config) └── ModemInit() └── modem_supervisor_init()這段鏈路對應(yīng)ST LoRaWAN協(xié)議棧里三個(gè)文件應(yīng)用層調(diào)用入口在LoRaWAN_App.c或main.c協(xié)議棧核心在LoRaWAN.c而modem_supervisor.c則負(fù)責(zé)整個(gè)modem生命周期的狀態(tài)監(jiān)管。modem_supervisor_init()做的事情第一項(xiàng)就是初始化射頻收發(fā)器Radio。它調(diào)用Radio.IoInit()去配置射頻核心相關(guān)引腳和中斷調(diào)用Radio.Init()把發(fā)射功率、擴(kuò)頻因子、帶寬、頻率等參數(shù)寫入射頻核心。但注意所有這些配置并不是直接寫寄存器就完事而是通過一條命令通道發(fā)送給一個(gè)獨(dú)立子系統(tǒng)去執(zhí)行。2.2 STM32WLE5的雙核結(jié)構(gòu)應(yīng)用核心與射頻核心的主仆通信ST官方對STM32WLE5的描述是單芯片LoRa無線SoC但芯片內(nèi)部其實(shí)分成兩個(gè)邏輯上獨(dú)立的單元一是用戶程序所運(yùn)行的主核心Cortex-M4二是ST出廠固件里預(yù)設(shè)的射頻調(diào)制解調(diào)器核心簡稱RF核心或radio core。主核心和射頻核心之間是怎么通信的答案是通過內(nèi)部SPI接口和一組中斷信號線。主核心把一條命令通過SPI寫入射頻核心的命令隊(duì)列射頻核心執(zhí)行完成后把結(jié)果寫回狀態(tài)寄存器再通過一個(gè)DIO引腳觸發(fā)主核心的中斷事件主核心在中斷回調(diào)里更新radio狀態(tài)標(biāo)志。這套機(jī)制和我們平時(shí)用外部SPI從設(shè)備非常像只是物理層換了。modem_supervisor_init()里那個(gè)while循環(huán)等的本質(zhì)上就是射頻核心完成初始化后返回的我已經(jīng)就緒標(biāo)志。2.3 死循環(huán)的直接觸發(fā)條件打開modem_supervisor.c源碼modem_supervisor_init()內(nèi)部結(jié)構(gòu)我這邊簡化成核心邏輯void modem_supervisor_init(void) { // 初始化射頻接口 Radio.IoInit(); Radio.Init(RadioInitConfig); // 配置公共網(wǎng)絡(luò)、信道、負(fù)載長度等參數(shù) Radio.SetPublicNetwork(LORAWAN_PUBLIC_NETWORK); Radio.SetChannel(LORAWAN_DEFAULT_CHANNEL); // 等待射頻核心返回 Idle 狀態(tài) while (Radio.GetStatus() ! RF_IDLE) { // 在這里死循環(huán)說明射頻核心始終沒有進(jìn)入 Idle } }Radio.GetStatus()這里讀取的是radio驅(qū)動層的狀態(tài)變量而這個(gè)變量默認(rèn)值是RF_BUSY只有射頻核心成功完成初始化并上報(bào)事件后才會被更新為RF_IDLE。所以判斷條件很簡單射頻核心沒有完成初始化狀態(tài)變量永遠(yuǎn)停留在RF_BUSYwhile永遠(yuǎn)為真。那么問題鏈條就明確收窄到兩個(gè)方向主核心發(fā)的SPI命令射頻核心根本沒收到或者收到后沒執(zhí)行。射頻核心執(zhí)行完了但主核心沒收到它的中斷通知狀態(tài)變量沒被更新。這兩個(gè)方向各有各的觸發(fā)原因下面逐一展開。射頻核心不響應(yīng)RCC、SPI、中斷和復(fù)位鏈路全面排查3.1 第一個(gè)檢查點(diǎn)SUBGHZ外設(shè)時(shí)鐘是否被打開在所有可能的原因里這個(gè)問題最常見也最容易被忽視。STM32WLE5的RCC時(shí)鐘樹里SUBGHZ是一個(gè)獨(dú)立的外設(shè)時(shí)鐘域它控制著整個(gè)射頻核心的時(shí)鐘供應(yīng)。如果這個(gè)時(shí)鐘沒開射頻核心就是一塊死鐵SPI寫進(jìn)去的命令全部石沉大海。CubeMX里正常配置LoRaWAN middleware時(shí)生成的代碼會自動帶上__HAL_RCC_SUBGHZ_ENABLE()。但只要你手動調(diào)整過時(shí)鐘樹比如把系統(tǒng)時(shí)鐘從MSI換成HSI并重新配置PLLCubeMX重新生成代碼時(shí)有可能覆蓋掉這部分配置或者你裁剪外設(shè)時(shí)把這個(gè)選項(xiàng)去掉射頻核心就失聯(lián)了。檢查方法非常直接// 檢查RCC中SUBGHZ對應(yīng)的使能位是否置位 if (__HAL_RCC_SUBGHZ_IS_CLK_ENABLED()) { // 時(shí)鐘已開啟 } else { // 時(shí)鐘未開啟這是首要嫌疑 __HAL_RCC_SUBGHZ_ENABLE(); }3.2 第二個(gè)檢查點(diǎn)內(nèi)部SPI配置是否有細(xì)微偏差STM32WLE5的主核心和射頻核心之間的SPI是芯片內(nèi)部的物理總線不經(jīng)過芯片引腳但它依然遵循SPI協(xié)議規(guī)則。CubeMX生成的內(nèi)部SPI配置里有幾個(gè)參數(shù)任何一個(gè)不對命令就傳不過去。重點(diǎn)看這三項(xiàng)時(shí)鐘極性CPOL和相位CPHA必須與射頻核心的默認(rèn)期望一致。SPI分頻系數(shù)內(nèi)部SPI速率越高越容易出問題建議先降到較低頻率跑通后再調(diào)高。傳輸格式必須是8位數(shù)據(jù)幀MSB先出。如果CubeMX把內(nèi)部SPI當(dāng)作普通外部SPI來配置默認(rèn)的極性和相位很可能不匹配。我遇到過一個(gè)案例就是因?yàn)閺墓俜嚼虒?dǎo)入工程時(shí)SPI的CPOL被改成了High射頻核心永遠(yuǎn)收到的是錯亂數(shù)據(jù)初始化卡死。3.3 第三個(gè)檢查點(diǎn)射頻核心中斷鏈路是否完整Radio.Init()之后射頻核心完成第一輪配置會觸發(fā)一次中斷通知主核心去讀取狀態(tài)。這個(gè)中斷在硬件上是一條內(nèi)部INT線映射到具體EXTI線。軟件層面由radio.c里的Radio.IoInit()去做初始化。中斷鏈路如果中斷主核心就永遠(yuǎn)等不到射頻核心的通知radio狀態(tài)變量就一直停留在RF_BUSY。要驗(yàn)證中斷是否正常去NVIC配置里看HAL_NVIC_SetPriority(SUBGHZ_Radio_IRQn, 0, 0); HAL_NVIC_EnableIRQ(SUBGHZ_Radio_IRQn);關(guān)鍵問題是SUBGHZ_Radio_IRQn是否真的被使能了中斷優(yōu)先級是否被別的代碼意外修改如果開啟了全局中斷屏蔽比如在__disable_irq()之后沒有重新使能射頻核心中斷就會被卡住。另外檢查中斷服務(wù)函數(shù)里是否完整調(diào)用了HAL_GPIO_EXTI_IRQHandler()有些人在精簡啟動代碼時(shí)把GPIO中斷處理環(huán)節(jié)刪掉了導(dǎo)致事件丟失。3.4 第四個(gè)檢查點(diǎn)復(fù)位后的射頻核心是否在運(yùn)行RCC除了提供時(shí)鐘還承擔(dān)復(fù)位控制。射頻核心在上電默認(rèn)狀態(tài)下是否從復(fù)位中釋放取決于RCC的復(fù)位寄存器配置。在CubeMX中System Core-RCC-Sub-GHz這里有顯式的管理項(xiàng)如果生成了代碼會調(diào)用__HAL_RCC_SUBGHZ_RELEASE_RESET();如果這一行缺失射頻核心一直處于復(fù)位狀態(tài)所有SPI命令都會失敗。這個(gè)問題的排查方式和時(shí)鐘缺失類似但它更隱蔽因?yàn)闀r(shí)鐘和復(fù)位的英文注釋在CubeMX配置頁里挨得很近容易看漏。3.5 第五個(gè)檢查點(diǎn)調(diào)試器和供電的干擾STM32WLE5的射頻核心和主核心共享同一片電源域。自研板上如果射頻部分供電紋波較大或者在初始化瞬間電流被其他外設(shè)拉低射頻核心可能出現(xiàn)內(nèi)部上電時(shí)序錯誤。這一類問題的典型表現(xiàn)是程序單獨(dú)用電池供電一切正常插上調(diào)試器就開始卡死。因?yàn)檎{(diào)試器會引入額外的地環(huán)路和電源噪聲。如果你的問題是調(diào)試時(shí)必現(xiàn)斷電重跑有時(shí)正常有時(shí)卡死那多半和電源穩(wěn)定性有關(guān)。檢查射頻核心的供電引腳附近有沒有足夠的去耦電容官方參考設(shè)計(jì)上通常每個(gè)電源引腳配置一個(gè)100nF電容如果有遺漏補(bǔ)上再試。3.6 第六個(gè)檢查點(diǎn)協(xié)議棧版本與射頻固件版本是否匹配STM32WLE5出廠時(shí)射頻核心里面燒錄的是一個(gè)黑盒固件用戶不可修改。ST的LoRaWAN協(xié)議棧和射頻核心固件之間需要相互匹配。如果你的協(xié)議棧是從舊版本工程里移植的而芯片是近期批次可能內(nèi)部固件版本更新兩者之間可能出現(xiàn)命令不兼容初始化命令發(fā)出去射頻核心不認(rèn)。這個(gè)檢查起來略微麻煩需要先繞過MX_LoRaWAN_Init()單獨(dú)跑一次射頻核心的命令讀取把固件版本讀出來SML_GetFwVersion(fw_version);讀出來的版本號再去對照ST官方Release Note里要求的協(xié)議棧版本。這種情況不多見但一旦遇到表現(xiàn)為整片板子都一樣且換一個(gè)舊批次芯片就正常。一次完整的實(shí)戰(zhàn)排查從CubeMX工程到修好只用了半小時(shí)4.1 排查工具準(zhǔn)備遇到這種問題別急著改代碼先把戰(zhàn)場布置好。我建議準(zhǔn)備三類工具缺一不可調(diào)試器ST-LINK或J-Link連接主核心的SWD接口。一個(gè)帶時(shí)間戳的串口工具波特率115200起步關(guān)鍵是能看到最后一條日志的時(shí)間點(diǎn)。一塊最少帶兩個(gè)IO的控制板或者直接用板載LED用來標(biāo)記代碼執(zhí)行到的位置。串口日志這里有個(gè)小技巧不要只在初始化前后各加一條打印要在Radio.IoInit()前、Radio.Init()前、進(jìn)入while之前各加一條帶編號的日志。這樣一旦卡住你知道卡在哪一步之間排查范圍直接縮小一大半。4.2 逐步定位用日志把卡死點(diǎn)精確到函數(shù)內(nèi)部我那個(gè)案例當(dāng)時(shí)的日志是這樣的[0ms] MX_LoRaWAN_Init called [1ms] LoRaWAN_Init begin [2ms] ModemInit begin [4ms] modem_supervisor_init begin [4ms] Radio.IoInit done [4ms] Radio.Init begin [5ms] Radio.Init done [5ms] before while(Radio.GetStatus ! RF_IDLE) -- 卡在這里日志很明確Radio.Init()已經(jīng)返回了說明主核心這一側(cè)把配置命令發(fā)出去這件事沒有卡住。問題出在命令發(fā)出去了但射頻核心的狀態(tài)一直沒變成Idle。接下來在while循環(huán)里加入一個(gè)運(yùn)行計(jì)數(shù)器順便把Radio.GetStatus()的返回值打印出來uint8_t radio_status; uint32_t loop_count 0; while (Radio.GetStatus() ! RF_IDLE) { radio_status Radio.GetStatus(); loop_count; if ((loop_count % 100000) 0) { printf(radio_status 0x%02X, loop %lu\n, radio_status, loop_count); } }串口輸出的radio_status一直沒變過。這就說明射頻核心那邊沒有一個(gè)事件來更新這個(gè)狀態(tài)。問題要么是射頻核心根本沒有收到命令要么是收到了但沒法回應(yīng)。4.3 三板斧RCC檢查、IRQ檢查、SPI檢查按照上文排查清單的優(yōu)先級我先查RCC。在modem_supervisor_init()函數(shù)開頭臨時(shí)加入printf(SUBGHZ clk enabled %d\n, __HAL_RCC_SUBGHZ_IS_CLK_ENABLED());串口輸出為0問題找到了SUBGHZ時(shí)鐘壓根沒開。用CubeMX重新檢查工程配置發(fā)現(xiàn)外設(shè)列表中Sub-GHz模塊前面的復(fù)選框沒有被勾選。我回憶了一下這次工程是從一個(gè)裁剪過的BLE工程模板修改而來裁剪模板時(shí)把Sub-GHz選項(xiàng)連帶刪除了。CubeMX重新勾選Sub-GHz并重新生成代碼后__HAL_RCC_SUBGHZ_ENABLE()自動被加入初始化代碼。但這里有個(gè)坑即使CubeMX自動生成了RCC使能代碼它生成的順序在SystemClock_Config()之后、在MX_LoRaWAN_Init()之前。而我們的LoRaWAN初始化如果在定時(shí)器或外設(shè)還沒初始化時(shí)就被調(diào)用仍然可能出現(xiàn)問題。保險(xiǎn)起見我在main()里、MX_LoRaWAN_Init()調(diào)用之前手動加了一行__HAL_RCC_SUBGHZ_ENABLE();修好這一行再跑程序radio_status開始變化了從RF_BUSY先變成某個(gè)中間態(tài)最終變成RF_IDLEmodem_supervisor_init()順利退出。整個(gè)排查過程不到半小時(shí)。4.4 如果時(shí)鐘沒問題下一步怎么查如果時(shí)鐘檢查正常我會建議按這個(gè)順序加打印驗(yàn)證在EXTI中斷處理回調(diào)里加一個(gè)計(jì)數(shù)器跑完Radio.Init()之后回來看看這個(gè)計(jì)數(shù)器有沒有變化。如果中斷計(jì)數(shù)始終為0說明射頻核心的中斷根本沒觸發(fā)。如果中斷有觸發(fā)但RF_IDLE狀態(tài)還是沒更新看看中斷回調(diào)里是否真正調(diào)用了RadioIrqProcess()以及這個(gè)函數(shù)里更新的是哪個(gè)狀態(tài)變量。用邏輯分析儀去抓射頻核心的輸出引腳確認(rèn)硬件層面是否有脈沖輸出。這一步在沒有邏輯分析儀的情況下可以改用示波器。這套流程走下來基本能把問題鎖定在命令沒發(fā)出去命令發(fā)出但沒回應(yīng)回應(yīng)了但中斷丟了中斷到了但狀態(tài)沒更新四個(gè)環(huán)節(jié)之一。對應(yīng)的修復(fù)手段分別是查SPI參數(shù)、查SUBGHZ復(fù)位/時(shí)鐘、查NVIC配置、查radio驅(qū)動回調(diào)。工程化規(guī)避給初始化循環(huán)加超時(shí)和狀態(tài)可視的三種做法5.1 為什么不能直接改ST庫函數(shù)很多人在定位到問題之后會想直接改modem_supervisor_init()里的while加上一個(gè)超時(shí)跳出邏輯。我的建議是調(diào)試時(shí)可以臨時(shí)改但不要作為最終方案提交到工程里。原因有二。一是ST在協(xié)議棧后續(xù)版本升級時(shí)modem_supervisor.c會整體替換你做的修改如果是以diff補(bǔ)丁形式維護(hù)每次升級都要重打非常容易漏。二是這個(gè)while循環(huán)本質(zhì)是協(xié)議棧的啟動同步點(diǎn)如果強(qiáng)行加超時(shí)并繼續(xù)往下跑后續(xù)LoRaWAN join流程在一個(gè)射頻核心仍未就緒的硬件上繼續(xù)執(zhí)行會出現(xiàn)更多、更奇怪的異常調(diào)試復(fù)雜度不會降低反而更高。正確的做法是把這個(gè)循環(huán)視為一種失敗即停止的快速失敗機(jī)制——硬件或配置不對時(shí)它就停在這里方便你定位。我們要做的不是跳過它而是讓失敗發(fā)生得更快、更明顯。5.2 做法A在函數(shù)外部做健康檢查推薦在調(diào)用MX_LoRaWAN_Init()之前先單獨(dú)做一次Radio層探活用一個(gè)帶超時(shí)上限的輪詢?nèi)プx射頻核心固件版本號static uint8_t CheckRadioCoreAlive(void) { SML_FwVersion_t fw_version; uint32_t tickstart HAL_GetTick(); // 在進(jìn)入?yún)f(xié)議棧完整初始化之前先探一下射頻核心是否響應(yīng) if (SML_GetFwVersion(fw_version) ! SML_OK) { return 0; } // 給射頻核心留出響應(yīng)時(shí)間窗口超時(shí)則判定核心不可用 while (radio_status ! RF_IDLE) { if ((HAL_GetTick() - tickstart) 1000) { return 0; } } return 1; }把這個(gè)檢查放在MX_LoRaWAN_Init()之前一旦返回0直接用串口輸出一行明確的錯誤信息并且讓板上LED進(jìn)入雙閃錯誤模式。這樣的好處是即使協(xié)議棧內(nèi)部仍然卡死你也至少知道卡死之前是哪個(gè)健康檢查沒通過。5.3 做法B復(fù)制協(xié)議棧源文件做本地補(bǔ)丁如果團(tuán)隊(duì)確實(shí)需要絕不能卡死的約束比如設(shè)備要在無人值守的環(huán)境下運(yùn)行可以采用把modem_supervisor.c復(fù)制到用戶代碼目錄、并在源文件基礎(chǔ)上打補(bǔ)丁的做法。具體操作從協(xié)議棧中間件目錄把modem_supervisor.c和對應(yīng)的頭文件復(fù)制到App/目錄下。確保構(gòu)建系統(tǒng)優(yōu)先編譯用戶目錄下的.c文件屏蔽掉中間件目錄里的同名文件。在modem_supervisor_init()的while循環(huán)里增加一個(gè)超時(shí)跳出的變量。uint32_t tickstart HAL_GetTick(); while (Radio.GetStatus() ! RF_IDLE) { if ((HAL_GetTick() - tickstart) 3000) { Error_Handler(); // 或者自己定義可恢復(fù)的錯誤處理 break; } }這套方案的缺點(diǎn)是升級協(xié)議棧時(shí)需要同步你的補(bǔ)丁到新版本但優(yōu)點(diǎn)是代碼行為在團(tuán)隊(duì)內(nèi)部完全可控不依賴ST的更新節(jié)奏。適合固化到企業(yè)級產(chǎn)品基線里。5.4 做法C把radio狀態(tài)注冊到調(diào)試監(jiān)視器I-CUBE-LRWAN協(xié)議棧內(nèi)部的radio狀態(tài)變量在較新版本里是支持訪問的。簡單做法是建立一個(gè)全局狀態(tài)鏡像在中斷回調(diào)里同步更新到調(diào)試監(jiān)視器volatile uint8_t g_radio_status_snapshot; void RadioIrqProcess(void) { g_radio_status_snapshot Radio.GetStatus(); // ... 原有處理邏輯 }調(diào)試時(shí)通過Keil的Watch窗口實(shí)時(shí)觀察g_radio_status_snapshot不需要打斷程序就能看到初始化過程中radio狀態(tài)跳變到哪一步停下來。這比全速運(yùn)行后再暫停去看PC指針要高效得多尤其在狀態(tài)切換頻繁的LoRaWAN join階段價(jià)值更大。我在STM32WLE5開發(fā)初期的幾個(gè)額外心得調(diào)試STM32WLE5這類雙邏輯核心的SoC和調(diào)試普通MCU有個(gè)很大的思維差異你不能想當(dāng)然地認(rèn)為程序沒跑到就是沒執(zhí)行。射頻核心的運(yùn)行狀態(tài)是一個(gè)你看不見的黑盒必須通過SPI命令、中斷回調(diào)、狀態(tài)變量這套顯式機(jī)制來驗(yàn)證。這也是為什么我強(qiáng)調(diào)日志計(jì)數(shù)器狀態(tài)鏡像三件套而不是靠感覺猜。另外我強(qiáng)烈建議在開發(fā)初期就準(zhǔn)備好一個(gè)最基礎(chǔ)的射頻底層自測例程單獨(dú)編譯一個(gè)小工程只做一件事讀取射頻核心固件版本號并打印。在遇到任何LoRaWAN協(xié)議棧層面的疑難問題時(shí)先切到這個(gè)小工程確認(rèn)射頻核心還活著。這能把硬件問題和軟件問題快速切分省下大量無效排查時(shí)間。如果你用的是自研板還有一個(gè)容易被忽略的點(diǎn)射頻核心需要的備用時(shí)鐘源。STM32WLE5上LoRa射頻部分對于時(shí)鐘源的頻率偏差比較敏感。官方例程默認(rèn)使用MSI或HSI作為基礎(chǔ)時(shí)鐘如果你改成外部有源晶振但焊接不良射頻核心同樣無法正常工作。這種問題的詭異之處在于它不是每次必現(xiàn)而是依賴環(huán)境溫度、上電瞬間的晶振起振速度。遇到間歇性卡死時(shí)優(yōu)先用示波器確認(rèn)外部晶振引腳有正常的振蕩波形。最近一次我排查另一塊板子的類似問題后來發(fā)現(xiàn)是地面銅皮鋪得不夠SPI信號回流路徑太長射頻核心偶爾收不到完整命令。這種屬于硬件設(shè)計(jì)問題軟件再怎么調(diào)都無濟(jì)于事。所以當(dāng)你把軟件側(cè)的RCC、SPI、中斷全部查完仍然無解時(shí)不妨把注意力轉(zhuǎn)回硬件本身——檢查射頻核心供電、去耦電容、時(shí)鐘源完整性這三大項(xiàng)。嵌入式調(diào)試驗(yàn)證的就是每個(gè)假設(shè)都花最少的時(shí)間去證明或證偽modem_supervisor_init()這個(gè)死循環(huán)最終不過是整個(gè)系統(tǒng)狀態(tài)機(jī)里一個(gè)誠實(shí)的哨兵它停下來告訴你某個(gè)前提條件沒有滿足。順著這條信號去查前置條件問題就解決了一大半。