前兩周調(diào)試一塊帶著Cortex-M3內(nèi)核的板子IDE里下載固件時(shí)突然彈出一行刺眼的錯(cuò)誤error: flash download failed - cortex-m3。這種報(bào)錯(cuò)在嵌入式開發(fā)里太常見了常見到很多人第一反應(yīng)就是換根數(shù)據(jù)線、重插一下調(diào)試器但重啟三回還在報(bào)錯(cuò)時(shí)就不得不認(rèn)真對(duì)待。我這次遇到的狀況更特殊芯片能識(shí)別、SWD能連上、讀寄存器和內(nèi)存都正常唯獨(dú)燒錄這一步掛掉而且報(bào)錯(cuò)信息里完全沒有指出Flash編程錯(cuò)誤標(biāo)志到底處于什么狀態(tài)。后來翻到廠商的應(yīng)用筆記編號(hào)LAT1210里面恰好分析了一個(gè)Flash編程錯(cuò)誤標(biāo)志的觸發(fā)案例。筆記正文不長(zhǎng)但它把這顆芯片F(xiàn)lash控制器的錯(cuò)誤標(biāo)志行為講得很透。我對(duì)照筆記把這次故障從現(xiàn)象、寄存器、波形到整改完整走了一遍發(fā)現(xiàn)很多看似“玄學(xué)”的燒錄失敗其實(shí)都有清晰的證據(jù)鏈可以追溯。這篇文章就把這段排查過程整理出來重點(diǎn)聊一聊Flash編程錯(cuò)誤標(biāo)志在真實(shí)項(xiàng)目里是怎么產(chǎn)生、怎么讀取、怎么從一堆干擾因素里定位出根因的。適合正在被Flash燒錄問題折磨的嵌入式開發(fā)、量產(chǎn)測(cè)試和硬件調(diào)試工程師參考。1. 編程錯(cuò)誤標(biāo)志背后的“信號(hào)鏈”從請(qǐng)求到置位發(fā)生了什么1.1 編程請(qǐng)求不是一條指令而是一套狀態(tài)機(jī)很多剛接觸MCU開發(fā)的同學(xué)以為Flash編程就是往一個(gè)地址寫數(shù)據(jù)寫完就完事了。實(shí)際上Flash控制器的寫操作是一套完整的狀態(tài)機(jī)每一個(gè)步驟都有對(duì)應(yīng)的控制位和狀態(tài)位順序錯(cuò)了、時(shí)序不對(duì)、電壓不夠都會(huì)在某個(gè)環(huán)節(jié)“卡”住。以典型的Cortex-M3內(nèi)核MCU為例一次Flash編程操作基本是這么走的檢查FLASH_SR里的BSY位確認(rèn)Flash控制器空閑向FLASH_KEYR依次寫入兩個(gè)解鎖鍵值解除Flash控制寄存器鎖定在FLASH_CR里把PGProgramming位置1告訴控制器接下來要執(zhí)行編程向目標(biāo)地址寫入數(shù)據(jù)數(shù)據(jù)寬度取決于Flash接口寬度等待BSY位清零期間不能進(jìn)行任何其他Flash操作讀取FLASH_SR檢查EOP標(biāo)志來判斷本次編程是否正常結(jié)束同時(shí)檢查PGERR、WRPERR等錯(cuò)誤標(biāo)志清掉PG位和EOP標(biāo)志收尾。這套流程里第4步是最容易被低估的。寫入的數(shù)據(jù)寬度如果和Flash接口寬度不匹配比如Flash接口是16位你非要用32位方式寫入控制器會(huì)立刻在內(nèi)部仲裁階段把此操作判定為非法此時(shí)PGERR就會(huì)被硬件置位。這類錯(cuò)誤不會(huì)產(chǎn)生任何異常中斷它只是安靜地在狀態(tài)寄存器里留下一個(gè)標(biāo)記。你不去讀它它就一直掛在那里等下一次編程操作開始時(shí)還可能干擾新的狀態(tài)判斷。LAT1210筆記里強(qiáng)調(diào)了一句話大意是Flash錯(cuò)誤標(biāo)志是“結(jié)果”而不是“原因”它只告訴你編程操作沒有成功但不會(huì)告訴你為什么沒有成功。這句話是我這次排查最大的啟發(fā)。看到PGERR置位之后真正要做的是反向追查是哪一步操作違反了Flash控制器的時(shí)序或電氣要求。1.2 PGERR、WRPERR到底各自在盯什么Flash控制器的狀態(tài)寄存器通常不會(huì)只有一個(gè)錯(cuò)誤位不同廠商、不同內(nèi)核的芯片定義略有差異但大體上會(huì)區(qū)分編程錯(cuò)誤、寫保護(hù)錯(cuò)誤、編程對(duì)齊錯(cuò)誤等幾類。以LAT1210筆記對(duì)應(yīng)芯片的FLASH_SR為例關(guān)鍵位大概長(zhǎng)這樣狀態(tài)位名稱典型置位條件BSY忙標(biāo)志Flash控制器正在執(zhí)行擦除或編程PGERR編程錯(cuò)誤標(biāo)志編程操作不滿足硬件時(shí)序或?qū)懭雽挾纫骔RPERR寫保護(hù)錯(cuò)誤標(biāo)志對(duì)受保護(hù)區(qū)域執(zhí)行了寫或擦除操作EOP編程結(jié)束標(biāo)志編程操作正常完成其他保留位保留讀取值不定忽略PGERR和WRPERR是最容易混淆的兩個(gè)標(biāo)志。WRPERR的觸發(fā)條件比較“實(shí)”你寫了寫保護(hù)寄存器或者芯片本身處于讀保護(hù)級(jí)別不允許修改Flash此時(shí)任何寫入嘗試都會(huì)直接被拒絕WRPERR置1。PGERR則復(fù)雜得多它可能是編程電壓不足、內(nèi)部時(shí)序不滿足、寫入寬度不匹配甚至可能是Flash控制器在編程過程中檢測(cè)到了某種內(nèi)部仲裁沖突。有一個(gè)容易忽略的點(diǎn)多數(shù)芯片在發(fā)生編程錯(cuò)誤后PG位并不會(huì)自動(dòng)清掉。FLASH_CR里的PG還保持著置位狀態(tài)控制器處于一種“騎虎難下”的中間態(tài)。如果軟件沒有做完整的錯(cuò)誤恢復(fù)——清理錯(cuò)誤標(biāo)志、清零PG位——后續(xù)的擦除、編程操作會(huì)一直表現(xiàn)異常。這也是為什么不少工程師遇到一次Flash燒寫失敗后要重新上電才能恢復(fù)因?yàn)橹挥袕?fù)位才能把這些殘留狀態(tài)徹底清干凈。1.3 標(biāo)志置位與中斷回調(diào)的時(shí)空關(guān)系有的MCU支持Flash操作完成中斷或錯(cuò)誤中斷。拿到LAT1210后我還特意確認(rèn)了一個(gè)細(xì)節(jié)這些錯(cuò)誤標(biāo)志和中斷標(biāo)志在時(shí)間上是不同步的讀取時(shí)要注意先后順序。如果程序在Flash編程完成后立刻進(jìn)入中斷回調(diào)回調(diào)里先讀FLASH_SR再清標(biāo)志這個(gè)順序通常沒問題。但如果有多個(gè)中斷源或者Flash編程由DMA參與可能出現(xiàn)“EOP還沒置位、中斷先到了”的情況。更隱蔽的是如果錯(cuò)誤標(biāo)志置位后軟件在中斷里直接返回沒有清標(biāo)志下次編程操作開始時(shí)讀到的還是舊的PGERR就會(huì)產(chǎn)生“每次寫都失敗”的假象。我在一次以前的項(xiàng)目里就踩過這個(gè)坑中斷回調(diào)里只做了標(biāo)志打印沒有清FLASH_SR結(jié)果第二次Flash寫入時(shí)代碼先檢查上一次的錯(cuò)誤標(biāo)志發(fā)現(xiàn)是1直接跳入了錯(cuò)誤處理分支但實(shí)際這次寫入根本沒有執(zhí)行。所以排查時(shí)要記住讀取錯(cuò)誤標(biāo)志和處理錯(cuò)誤標(biāo)志是兩個(gè)動(dòng)作前者是證據(jù)收集后者是狀態(tài)恢復(fù)缺一不可。2. 哪些環(huán)節(jié)最容易讓錯(cuò)誤標(biāo)志“認(rèn)領(lǐng)”到無辜的失敗2.1 時(shí)鐘與等待周期編程窗口的隱形裁判Flash編程對(duì)時(shí)鐘的依賴比很多人想象中要強(qiáng)。LAT1210筆記里專門提了工作電壓和Flash等待周期Flash Latency的匹配表這個(gè)表雖然通常放在數(shù)據(jù)手冊(cè)里但實(shí)際調(diào)試時(shí)很少有人會(huì)主動(dòng)去核對(duì)。Flash編程內(nèi)部有一套時(shí)序邏輯由系統(tǒng)時(shí)鐘或Flash接口時(shí)鐘驅(qū)動(dòng)。如果HCLK頻率超過當(dāng)前電壓等級(jí)下允許的范圍而FLASH_ACR里的等待周期沒有同步調(diào)整Flash讀取時(shí)序就會(huì)出問題。編程階段表現(xiàn)更直接——控制器內(nèi)部的狀態(tài)機(jī)跑飛BSY位遲遲不清零最終PGERR置位。我在調(diào)試一塊主頻72MHz的樣板時(shí)遇到過一種“時(shí)而成功、時(shí)而失敗”的情況。原因是系統(tǒng)初始化代碼里先把PLL切到了72MHz但FLASH_ACR的等待周期還是0相當(dāng)于72MHz下以0等待周期去訪問Flash。程序裝進(jìn)RAM里跑的時(shí)候一切正常一旦涉及Flash編程控制器內(nèi)部就凌亂了。排查這類問題要看兩個(gè)點(diǎn)FLASH_ACR里的LATENCY位是否符合當(dāng)前時(shí)鐘頻率以及切換到高速時(shí)鐘時(shí)是否先配好了Flash等待周期再切換時(shí)鐘源。很多芯片的參考例程里順序都是“先設(shè)等待周期再開PLL”這不是代碼潔癖而是Flash控制器的硬性要求。2.2 供電跌落電荷泵最怕的隱形刺客LAT1210里對(duì)編程錯(cuò)誤的觸發(fā)條件描述得很短但其中有一條被我忽略了很久“編程操作需要內(nèi)部電荷泵介入電荷泵需要穩(wěn)定的供電?！边@句話展開來說就是一個(gè)非常經(jīng)典的問題Flash編程的瞬間電流遠(yuǎn)大于MCU正常運(yùn)行的電流如果供電鏈路撐不住電壓跌落電荷泵就無法產(chǎn)生足夠的編程高壓。MCU在正常運(yùn)行模式下功耗可能只有幾十毫安但Flash擦寫時(shí)電流會(huì)抬升尤其是整片擦除或者連續(xù)多頁編程時(shí)電流尖峰相當(dāng)可觀。如果供電方式是USB口轉(zhuǎn)Type-C線取電線纜本身有內(nèi)阻接觸件也有電阻電流一上去MCU的VDD就會(huì)被拉低。更麻煩的是這種電壓跌落非常短暫可能只有幾百微秒到幾毫秒萬用表根本測(cè)不到示波器不抓瞬態(tài)也看不到。只有把示波器探頭點(diǎn)在MCU的VDD引腳和GND引腳之間設(shè)置好觸發(fā)在編程瞬間抓取波形才能看到那個(gè)“V”字形的跌落坑。2.3 寫保護(hù)、地址邊界與算法加載三個(gè)高頻誤判源除開時(shí)鐘和供電日常項(xiàng)目里還有三個(gè)高頻誤判源經(jīng)常把排查方向帶偏。第一個(gè)是寫保護(hù)。芯片出廠時(shí)可能默認(rèn)某些扇區(qū)處于保護(hù)狀態(tài)或者代碼里之前設(shè)置過寫保護(hù)復(fù)位后依然生效。調(diào)試器在下載時(shí)如果按整個(gè)Flash范圍擦寫遇到保護(hù)扇區(qū)就會(huì)報(bào)錯(cuò)FLASH_SR里的WRPERR會(huì)置位。但很多調(diào)試器報(bào)錯(cuò)信息不會(huì)細(xì)分只給一個(gè)籠統(tǒng)的flash download failed容易誤判成“Flash壞了”。第二個(gè)是地址邊界。Flash編程是以頁或扇區(qū)為單位的操作不能跨越扇區(qū)邊界。比如一個(gè)扇區(qū)大小是1KB地址0x080003FF和0x08000400雖然只差一個(gè)字節(jié)但已經(jīng)跨入了下一個(gè)扇區(qū)。如果程序里沒有做邊界對(duì)齊處理這次編程操作就會(huì)觸發(fā)控制器異常進(jìn)而置位PGERR。第三個(gè)是下載算法Flash Loader與芯片型號(hào)不匹配。使用IDE通過調(diào)試器下載時(shí)會(huì)先在目標(biāo)RAM里加載一個(gè)Flash編程算法文件不同內(nèi)核、不同F(xiàn)lash大小對(duì)應(yīng)的算法是不同的。如果算法文件選錯(cuò)了或者算法需要的RAM空間超出了目標(biāo)芯片實(shí)際RAM大小下載過程會(huì)失敗。此時(shí)的錯(cuò)誤標(biāo)志往往根本沒機(jī)會(huì)置位因?yàn)镕lash控制器壓根沒參與操作錯(cuò)誤發(fā)生在RAM加載階段。這點(diǎn)要特別留意看到PGERR置位可以優(yōu)先懷疑Flash控制器本身如果PGERR沒有置位但下載還是失敗問題很可能出在下載算法或調(diào)試器配置上。3. 一次真實(shí)故障的現(xiàn)場(chǎng)排查從報(bào)錯(cuò)到定位VDD跌落3.1 還原現(xiàn)象報(bào)錯(cuò)文本、復(fù)現(xiàn)率和環(huán)境變量這次故障的現(xiàn)場(chǎng)情況是這樣的目標(biāo)板是一塊以Cortex-M3內(nèi)核MCU為核心的控制板供電來自電腦USB口轉(zhuǎn)Type-C線調(diào)試器是常見的SWD接線方式IDE燒錄時(shí)報(bào)錯(cuò)信息為error: flash download failed - cortex-m3。關(guān)鍵信息先記錄一下芯片能正常連接SWD掃描能識(shí)別到內(nèi)核讀Flash內(nèi)容正常讀RAM正常單步調(diào)試不受影響下載燒錄時(shí)偶爾能成功一次但再燒第二次就報(bào)錯(cuò)報(bào)錯(cuò)后重新插拔USB線可能又恢復(fù)燒一次再次失敗。這種“時(shí)好時(shí)壞”的現(xiàn)場(chǎng)通常不會(huì)指向芯片本身損壞更像是一個(gè)間歇性電氣問題。我在記錄現(xiàn)象時(shí)把環(huán)境變量也列了進(jìn)去使用哪根Type-C線、插在電腦哪個(gè)USB口、調(diào)試器線纜長(zhǎng)度、目標(biāo)板是否接外部供電。事實(shí)證明這些環(huán)境變量最后全都派上了用場(chǎng)。3.2 寄存器取證FLASH_SR讀出0x104意味著什么報(bào)錯(cuò)之后我先通過調(diào)試器命令窗口讀取了FLASH_SR寄存器讀出值是0x104。這個(gè)值的含義需要拆開看按bit從低到高分解0x104 二進(jìn)制 1_0000_0100對(duì)應(yīng)bit2和bit8為1。在這顆芯片的定義里bit2是PGERR編程錯(cuò)誤標(biāo)志bit8是EOP編程結(jié)束標(biāo)志。也就是說這次編程操作實(shí)際上“完成”了控制器也給出了EOP結(jié)束信號(hào)但同時(shí)也報(bào)告了PGERR編程錯(cuò)誤。兩件事同時(shí)發(fā)生并不矛盾控制器的內(nèi)部時(shí)序走了個(gè)過場(chǎng)但編程結(jié)果沒有通過內(nèi)部校驗(yàn)或者編程電壓沒有達(dá)到要求最終把PGERR置上了。這直接排除了下載算法加載失敗的可能——Flash控制器確實(shí)收到了編程請(qǐng)求并且執(zhí)行了只是執(zhí)行失敗了。為了進(jìn)一步排除寫保護(hù)干擾我隨后讀了FLASH_CR和寫保護(hù)配置寄存器。FLASH_CR里的PG位還停在1說明發(fā)生錯(cuò)誤后沒有軟件去清它這符合“報(bào)錯(cuò)后程序已停止調(diào)試器接管現(xiàn)場(chǎng)”的場(chǎng)景。寫保護(hù)寄存器讀出來是全0所有扇區(qū)都是非保護(hù)狀態(tài)WRPERR也沒有置位寫保護(hù)這條線直接排除。3.3 用示波器抓編程瞬態(tài)供電曲線說明了一切寄存器證據(jù)到手后范圍已經(jīng)縮小到了“編程電壓異?！被颉皶r(shí)鐘配置異?！薄？紤]到這塊板子在此之前一直工作正常固件里沒有改過時(shí)鐘配置第一次判斷更傾向于電壓?jiǎn)栴}。我拿示波器探頭接了MCU的VDD引腳和GND引腳觸發(fā)放置在下降沿然后觸發(fā)一次燒錄。抓到的波形非常直觀燒錄啟動(dòng)前VDD穩(wěn)定在3.32V編程指令發(fā)出后VDD在約幾百微秒內(nèi)跌到了3.05V左右跌幅接近270mV隨后緩慢恢復(fù)。對(duì)于內(nèi)部有電荷泵的Flash控制器來說VDD跌到3.0V附近時(shí)電荷泵的輸出裕量已經(jīng)非常小編程高壓建立不充分PGERR置位幾乎是必然結(jié)果。這個(gè)跌落幅度的來源也清楚了Type-C線纜內(nèi)阻加USB口接觸電阻在編程瞬間電流抬升時(shí)形成了明顯的壓降。編程不是持續(xù)耗電而是脈沖式耗電所以萬用表讀數(shù)始終是正常的3.3V只有示波器能看到瞬態(tài)跌落。這也是為什么這類故障非常容易讓人誤判成“調(diào)試器不穩(wěn)定”或“芯片體質(zhì)差”。3.4 整改與驗(yàn)證改線、加電容、重跑十次根因定位到供電跌落后整改方案就很簡(jiǎn)單但也要驗(yàn)證每一種方案的實(shí)際效果。我先換了一根線徑更粗、長(zhǎng)度更短的Type-C線同時(shí)把USB口從電腦前置面板換到后置原生USB口重新燒錄VDD在編程瞬態(tài)的跌幅從270mV降到了130mV左右。這個(gè)跌幅依然不小但錯(cuò)誤基本不再出現(xiàn)。隨后我進(jìn)一步在MCU的VDD和GND之間靠近電源引腳位置并聯(lián)了一顆100uF電解電容和一顆100nF陶瓷電容再測(cè)編程瞬態(tài)VDD跌幅降到了80mV以內(nèi)。為了確認(rèn)徹底解決我連續(xù)燒錄了十次包括全片擦除、增量寫入、反復(fù)擦寫同一扇區(qū)全部通過。之后又把原來的細(xì)線換回去僅僅保留新增電容燒錄依然穩(wěn)定通過。這說明電容對(duì)瞬態(tài)供電的補(bǔ)償起到了主要作用線纜內(nèi)阻只是加重問題的因素之一。這次排查看似簡(jiǎn)單但真正的難點(diǎn)不在于“換線”或“加電容”而在于通過寄存器證據(jù)把方向?qū)?zhǔn)了“供電瞬態(tài)”而不是“芯片故障”。如果一開始就盲目換芯片問題大概率還會(huì)復(fù)現(xiàn)。4. 調(diào)試中容易一腳踩空的邊界場(chǎng)景4.1 擦除失敗和編程失敗共用標(biāo)志但不共用根因Flash的擦除操作和編程操作在FLASH_SR里共用了一部分錯(cuò)誤標(biāo)志但它們背后對(duì)應(yīng)的硬件行為是不同的。編程錯(cuò)誤可能和寫入寬度、內(nèi)部時(shí)序有關(guān)擦除錯(cuò)誤更多和擦除電壓、供電能力、擦除超時(shí)有關(guān)。我在另外一塊板子上遇到過類似現(xiàn)象程序里執(zhí)行扇區(qū)擦除后立刻進(jìn)行編程編程階段報(bào)了PGERR看起來是編程錯(cuò)誤。但把邏輯倒回去看其實(shí)擦除環(huán)節(jié)就已經(jīng)失敗了Flash里殘留的數(shù)據(jù)沒有完全清成0xFF接著的編程操作基于臟數(shù)據(jù)執(zhí)行控制器內(nèi)部無法正確校驗(yàn)最終在編程階段暴露出來。這就是典型的“根因在擦除表現(xiàn)在編程”。處理這類問題排查時(shí)要把時(shí)間線往前拉不能只看當(dāng)前報(bào)錯(cuò)的這步操作。如果程序里先擦除后編程而報(bào)錯(cuò)出現(xiàn)在編程別急著檢查編程寫入邏輯先去確認(rèn)擦除是否真的成功了?？梢栽诓脸蠹右粋€(gè)讀取回讀確認(rèn)步驟確保整片目標(biāo)區(qū)域都是0xFF再進(jìn)入編程流程。4.2 讀回校驗(yàn)不一致未必是編程標(biāo)志的責(zé)任很多固件在編程后會(huì)做一個(gè)讀回校驗(yàn)把寫入的數(shù)據(jù)讀出來和源數(shù)據(jù)比對(duì)。如果比對(duì)不一致第一反應(yīng)往往是對(duì)著Flash編程錯(cuò)誤標(biāo)志查。但有一個(gè)容易忽略的點(diǎn)讀到數(shù)據(jù)不對(duì)可能不是Flash沒寫進(jìn)去而是讀路徑上有緩存干擾。部分Cortex-M內(nèi)核支持指令預(yù)取緩沖、Cache或ART加速器。編程完成后如果沒有執(zhí)行緩存失效操作從同一地址讀數(shù)據(jù)時(shí)可能命中的還是緩存里的舊值或者緩存中的指令預(yù)取內(nèi)容沒有被刷新讀回校驗(yàn)自然對(duì)不上。此時(shí)FLASH_SR里的PGERR明明是0編程是成功的但校驗(yàn)邏輯就是報(bào)錯(cuò)。我建議在編程后的讀回校驗(yàn)之前先做一次緩存清理操作或者直接讀取一個(gè)不在緩存覆蓋范圍內(nèi)的地址來驗(yàn)證比如唯一ID寄存器區(qū)域。做校驗(yàn)時(shí)也要區(qū)分是第一個(gè)字節(jié)就對(duì)不上還是中間某些字節(jié)對(duì)不上。前者更可能是地址或數(shù)據(jù)寬度問題后者更可能是緩存一致性或時(shí)序問題。4.3 標(biāo)志自清零與軟件清零的錯(cuò)位Flash錯(cuò)誤標(biāo)志的清除機(jī)制在不同芯片上不一致有的標(biāo)志在上電復(fù)位時(shí)自動(dòng)清零有的在任何復(fù)位時(shí)都清零還有的必須由軟件寫1清除。如果搞混了這些特性在調(diào)試時(shí)會(huì)做出完全錯(cuò)誤的判斷。LAT1210筆記里提到了一個(gè)細(xì)節(jié)PGERR標(biāo)志在發(fā)生編程錯(cuò)誤后不會(huì)自動(dòng)清軟件需要在讀取并確認(rèn)后通過向FLASH_SR對(duì)應(yīng)位寫1來清除。如果只是調(diào)用了一次“清標(biāo)志”函數(shù)而沒有確認(rèn)復(fù)位源類型很容易把上一次復(fù)位殘留的錯(cuò)誤標(biāo)志誤當(dāng)成當(dāng)前操作的結(jié)果。實(shí)際項(xiàng)目里我在調(diào)試一個(gè)看門狗復(fù)位的應(yīng)用時(shí)遇到過類似問題程序因看門狗復(fù)位后FLASH_SR里殘留了上一次的PGERR新的編程操作還沒執(zhí)行軟件先讀標(biāo)志發(fā)現(xiàn)為1直接跳進(jìn)了錯(cuò)誤處理分支。這個(gè)“幽靈錯(cuò)誤”跟了幾天最后才排查到是復(fù)位后沒有初始化Flash錯(cuò)誤狀態(tài)?，F(xiàn)在我的習(xí)慣是任何復(fù)位后的初始化流程里第一步先把Flash控制器的錯(cuò)誤狀態(tài)清零并且記錄當(dāng)前復(fù)位源避免歷史錯(cuò)誤污染新操作。5. 把錯(cuò)誤標(biāo)志從“報(bào)錯(cuò)器”變成“體檢表”的幾個(gè)習(xí)慣5.1 在固件里內(nèi)置一個(gè)Flash狀態(tài)寄存器快照函數(shù)排查過幾次Flash問題后我養(yǎng)成了一個(gè)習(xí)慣在固件里內(nèi)置一個(gè)Flash狀態(tài)快照函數(shù)把FLASH_SR、FLASH_CR、最近一次編程的目標(biāo)地址、當(dāng)前復(fù)位源全部打包進(jìn)一個(gè)結(jié)構(gòu)體通過串口打印或者存儲(chǔ)到RAM里的固定位置。這樣一旦發(fā)生編程錯(cuò)誤不再是只有一個(gè)孤零零的報(bào)錯(cuò)代碼而是一整套現(xiàn)場(chǎng)數(shù)據(jù)。代碼寫起來并不復(fù)雜核心思路是出錯(cuò)時(shí)保留現(xiàn)場(chǎng)typedef struct { uint32_t flash_sr; uint32_t flash_cr; uint32_t last_write_addr; uint32_t reset_source; } flash_error_snapshot_t; void flash_error_capture(uint32_t addr) { flash_error_snapshot_t snap; snap.flash_sr FLASH-SR; snap.flash_cr FLASH-CR; snap.last_write_addr addr; snap.reset_source RCC-CSR RCC_CSR_RMVF; // 存儲(chǔ)到不參與Flash操作的RAM區(qū)便于復(fù)位后讀取 memcpy((void *)ERROR_SNAPSHOT_ADDR, snap, sizeof(snap)); }出錯(cuò)時(shí)在Flash編程函數(shù)末尾調(diào)用這個(gè)函數(shù)然后用調(diào)試器讀RAM指定地址就能拿到完整的現(xiàn)場(chǎng)快照。這個(gè)方法比單純打印日志可靠因?yàn)橛行╁e(cuò)誤發(fā)生時(shí)會(huì)連帶觸發(fā)復(fù)位串口來不及輸出但RAM里的數(shù)據(jù)不會(huì)丟。5.2 下載腳本里加一道復(fù)位后校驗(yàn)調(diào)試下載時(shí)我習(xí)慣在IDE的下載腳本或命令序列里加上“編程后復(fù)位再運(yùn)行”的步驟而不只是燒完后停在那里。比如使用命令行調(diào)試器時(shí)可以加類似這樣的命令monitor reset run loadfile firmware.hex monitor reset run第一條monitor reset run確保編程前芯片處于干凈的復(fù)位狀態(tài)燒錄完成后再次復(fù)位運(yùn)行可以驗(yàn)證程序能否正常啟動(dòng)。如果程序啟動(dòng)時(shí)做了Flash狀態(tài)自檢這一步幾乎能把編程問題暴露大半。另外在下載前做一個(gè)“解除寫保護(hù)”或“批量擦除”的步驟在某些芯片上很有必要尤其針對(duì)量產(chǎn)夾具。很多芯片出廠時(shí)Flash狀態(tài)不確定直接下載會(huì)踩到保護(hù)區(qū)域。提前執(zhí)行一次全片擦除能讓后續(xù)編程的地址空間處于一致狀態(tài)。5.3 記錄基線每個(gè)板卡的電壓、時(shí)鐘、Flash驅(qū)動(dòng)版本最后分享一個(gè)聽起來“偏管理”但實(shí)際救過我的習(xí)慣給每個(gè)板卡建立一份簡(jiǎn)單基線記錄包含靜態(tài)工作電壓、編程瞬態(tài)電壓跌落幅度、系統(tǒng)時(shí)鐘配置、Flash驅(qū)動(dòng)版本。為什么要做這個(gè)因?yàn)镕lash錯(cuò)誤很多時(shí)候不是芯片問題而是板卡的電氣一致性問題和代碼版本問題。量產(chǎn)時(shí)同一種板子可能有不同批次Type-C座供應(yīng)商換了、電源電容容值降了、甚至PCB走線做了輕微改版這些都會(huì)影響Flash編程的穩(wěn)定性。有了基線數(shù)據(jù)排查時(shí)就能快速對(duì)比“這塊板子編程瞬態(tài)電壓跌幅260mV正常板子是80mV”比“這塊板子燒不進(jìn)去”要高效得多。沒有基線的排查就像在完全沒有參照物的情況下判斷一個(gè)運(yùn)行參數(shù)是否正常只能靠猜。記錄方式不需要復(fù)雜一張簡(jiǎn)單的Excel表就能用。字段也不用多板卡編號(hào)、固件版本、Flash驅(qū)動(dòng)版本、編程瞬態(tài)VDD最低值、復(fù)現(xiàn)次數(shù)、備注即可。等某一天板卡出問題的時(shí)候你回頭看這些基線往往一眼就能看出異常點(diǎn)。這次LAT1210筆記的排查讓我體會(huì)最深的一點(diǎn)是Flash編程錯(cuò)誤標(biāo)志就像設(shè)備上的故障指示燈它亮了表示系統(tǒng)確實(shí)出了問題但它不會(huì)告訴你問題出在哪個(gè)環(huán)節(jié)。把寄存器的位、示波器的波形、供電系統(tǒng)的瞬態(tài)特性串起來才能找到真正的答案。嵌入式調(diào)試沒有太多玄學(xué)多數(shù)“奇怪”的故障只要肯把證據(jù)鏈?zhǔn)占暾寄苈涞揭粋€(gè)具體的物理或邏輯原因上。