1. 問題現(xiàn)象DFU能燒錄eMMC啟動卻成了“鬼打墻”如果你正在調(diào)STM32MP257F-EV1大概率也遇到過這種讓人血壓飆升的場景板子昨天還用USB DFU好好地?zé)洝印⑴躄inux今天想把系統(tǒng)固化到eMMC按正常流程燒完、撥碼切到eMMC啟動、上電——結(jié)果串口開始刷屏板子無限重啟日志里反復(fù)出現(xiàn)一行刺眼的報錯。我這邊固化的啟動日志就卡死在下面這個狀態(tài)[TF-M] IAC exception 128 [TF-M] System reset due to exception然后就開始循環(huán)復(fù)位、起、再復(fù)位、再起。更抓狂的是這時候你把USB線插到板子的DFU/OTG口主機端完全枚舉不到設(shè)備fastboot devices一直空著STM32CubeProgrammer也連不上。表面看好像“板子變磚了”但扒開日志看問題并沒有那么玄乎。先說清楚這次故障的現(xiàn)場環(huán)境和操作路徑方便你對號入座硬件平臺STM32MP257F-EV1 官方評估板目標(biāo)鏡像基于 STM32CubeMP2 SDK 構(gòu)建的 TF-M FIP含 OP-TEE U-Boot以及 Linux 內(nèi)核鏡像燒錄方式STM32CubeProgrammer 通過 USB DFU 將鏡像寫入 eMMC復(fù)現(xiàn)路徑DFU 模式下一切正常切到 eMMC 啟動后復(fù)現(xiàn)最終表現(xiàn)無限重啟 IAC exception 128 fastboot 不進(jìn)如果你也卡在“DFU好用、eMMC起不來”這個分界點上這篇文章會把異常的含義、啟動鏈路的差異、排查順序和修復(fù)手段都拆開講。我自己已經(jīng)從這套流程里救回來三塊MP2板子了按下面的思路走基本不用懷疑硬件。2. IAC exception 128 到底在說什么先搞懂異常機制再動手排查之前先把報錯本身啃明白。IAC exception的全稱是Instruction Access Constraint它的異常類型編碼EC是0x80十進(jìn)制就是128。這是Armv8-M架構(gòu)Cortex-M33下定義的一類故障異常核心含義是CPU在取指令階段訪問了一個當(dāng)前執(zhí)行狀態(tài)不允許訪問的內(nèi)存地址。對這里的關(guān)鍵詞是“取指令階段”。它和數(shù)據(jù)訪問異常不同IAC管的是“CPU從某個地址去拉下一條要執(zhí)行的指令”這個動作本身的合法性。在STM32MP257這種雙A35加一個M33的異構(gòu)架構(gòu)里TF-M跑在Cortex-M33上負(fù)責(zé)安全啟動、DDR初始化、外設(shè)隔離和跳轉(zhuǎn)控制。啟動早期M33會完成內(nèi)存映射和安全屬性配置然后把非安全側(cè)的鏡像U-Boot、OP-TEE等交給A35去跑。這一跳轉(zhuǎn)過程中如果發(fā)生下面任何一種情況都會捅出IAC exceptionCPU處于非安全狀態(tài)Non-secure卻嘗試從一個被標(biāo)記為安全Secure的地址取指令取指地址落在沒有被映射的地址區(qū)間比如DDR控制器還沒初始化好取指地址所在的內(nèi)存區(qū)域被配置為不可執(zhí)行XNExecute Never跳轉(zhuǎn)目標(biāo)地址本身和實際鏈接地址不一致跑到了一段“什么都不是”的數(shù)據(jù)區(qū)。用大白話講你手里拿著導(dǎo)航但導(dǎo)航里填的終點是錯的或者去終點的路被交警封了CPU一腳油門踩下去直接撞墻。IAC Exception 128就是這堵墻撞出來的巨響。很多人在這一步就開始懷疑“eMMC壞了”“DDR虛焊”其實大可不必。DFU模式下能用、切eMMC才崩說明硬件大概率沒事問題幾乎都出在軟件鏈上TF-M與FIP版本不匹配、鏡像沒有放到eMMC正確的啟動位置、或者啟動源選擇與燒錄內(nèi)容對不上。還有一點要特別說明異常在TF-M早期就發(fā)生了所以你在串口看到的是TF-M打印的異常信息而不是U-Boot的日志。如果TF-M日志只打印到一半就復(fù)位也能進(jìn)一步佐證問題出在M33安全側(cè)而不是A35側(cè)的Linux內(nèi)核。這為后面的排查順序定了方向。3. DFU到eMMC啟動的切換鏈路為什么DFU正常eMMC就崩要理解“為什么DFU好用、eMMC就崩”得先把STM32MP257的啟動鏈路和兩種啟動方式的差異拉通。3.1 STM32MP257F-EV1的完整啟動鏈MP2系列和MP1在啟動流程上有個顯著區(qū)別MP1用的是TF-A BL2而MP2改用TF-MTrusted Firmware-M作為BL2跑在Cortex-M33上。完整鏈路如下ROM (BootROM) - TF-M (BL2, 運行在Cortex-M33) - FIP (包含 TF-A BL31 / OP-TEE / U-Boot) - Linux Kernel關(guān)鍵點在前兩級BootROM從啟動介質(zhì)中加載TF-M鏡像TF-M負(fù)責(zé)DDR初始化、FIP解析、鏡像校驗然后把非安全側(cè)的U-Boot和OP-TEE加載進(jìn)DDR最后釋放A35執(zhí)行。也就是說整個啟動鏈里“第一個吃螃蟹的人”是TF-M它一旦加載失敗或者跳轉(zhuǎn)出錯后面全白搭。3.2 DFU模式與eMMC啟動的本質(zhì)差異DFU模式下STM32CubeProgrammer通過USB把鏡像直接下載到DDR里然后從RAM啟動。你燒錄的內(nèi)容、地址、Flash布局都是CubeProgrammer在PC端算好并控制的TF-M在RAM里被加載后DDR等硬件已經(jīng)被初始化完畢一切看起來“歲月靜好”。但eMMC啟動時情況完全不同BootROM會先讀取eMMC的boot分區(qū)或user area把TF-M鏡像加載到內(nèi)部SRAMTF-M運行后要自己完成DDR初始化再去eMMC讀取FIP包FIP包在eMMC上的物理偏移必須和TF-M編譯時約定的偏移完全一致燒錄到eMMC的TF-M版本、FIP版本必須匹配同一個SDK版本。任何一個環(huán)節(jié)錯位都可能造成TF-M取出錯誤的鏡像數(shù)據(jù)跳到非預(yù)期地址觸發(fā)IAC exception 128。所以不要因為DFU模式下能跑就默認(rèn)eMMC燒錄沒問題——這兩種方式對布局、版本一致性的敏感程度完全不同。3.3 切換時最容易被忽略的三個卡點我在實際排查中總結(jié)出三個高頻卡點基本覆蓋了這類故障的九成原因TF-M沒有更新或者被覆蓋。很多團隊的U-Boot和Linux是頻繁更新的但TF-M一份固件用很久。如果FIP升級了、TF-M還是老的兩邊對DDR安全區(qū)域劃分、FIP偏移的理解不一致啟動時直接跑到安全屬性沖突的地址。燒錄位置和啟動方式不匹配。STM32MP257的eMMC可以從boot partition 1、boot partition 2或者user area啟動燒錄時要根據(jù)flashlayout.tsv的分區(qū)定義把TF-M和FIP寫到正確的位置。比如TF-M要燒到eMMC boot1分區(qū)FIP也在boot1的后續(xù)偏移如果誤燒到user areaBootROM找不到TF-M或者TF-M找不到FIP同樣表現(xiàn)為死循環(huán)。BOOT引腳/OTP配置和實際燒錄介質(zhì)沖突。EV1板上有BOOT撥碼開關(guān)如果撥到了eMMC啟動但eMMC里根本沒有有效鏡像BootROM會反復(fù)嘗試加載失敗表現(xiàn)就是不斷復(fù)位。這里可以做一個快速驗證把BOOT撥回DFU啟動模式如果板子能正常進(jìn)入DFU基本可以判斷硬件沒有損壞問題集中在eMMC內(nèi)容或啟動配置上。4. 系統(tǒng)化排查鏈路從日志定位到根因一步步來面多這類“無限重啟”故障最忌諱的就是一遍遍重?zé)⒎磸?fù)試然后越試越亂。我總結(jié)了一套從日志到配置的排查順序按這個順序走通常兩輪之內(nèi)就能定位。4.1 第一步確認(rèn)異常發(fā)生的具體階段先把串口日志完整抓下來我建議用邏輯分析儀或者串口工具記錄完整的上電日志不要只看最后一段。關(guān)鍵要確認(rèn)日志里有沒有BootROM的打印MP2的BootROM一般會有啟動源信息TF-M有沒有打印出來打印到了哪一行就停止是TF-M自己報的IAC還是U-Boot階段報的異常。如果日志里TF-M打印完IAC exception 128就復(fù)位說明異常發(fā)生在TF-M跳轉(zhuǎn)前后。如果TF-M根本沒打印可能是TF-M鏡像本身沒加載出來或者BootROM根本沒從eMMC讀到數(shù)據(jù)——那就是啟動源和鏡像位置的問題。我之前遇到的情況是TF-M打印正常說明BootROM成功從eMMC讀到了TF-MDDR也初始化了但在跳轉(zhuǎn)U-Boot時崩了。這就把方向直接指向TF-M和FIP的匹配性。4.2 第二步核對TF-M與FIP的版本一致性這是我在多塊板子上踩出來的經(jīng)驗MP2平臺這類跳轉(zhuǎn)失敗第一嫌疑永遠(yuǎn)是TF-M版本和FIP版本不匹配。為什么因為U-Boot的鏈接地址、DDR安全區(qū)域的劃分、FIP的加載地址都在TF-M的配置里。FIP中的U-Boot被加載到哪個DDR地址、以什么安全屬性運行是由TF-M決定的。如果FIP是SDK v4.1構(gòu)建的TF-M卻是v4.0的兩個版本對地址映射和安全屬性的定義有差異跳轉(zhuǎn)時CPU很可能嘗試從一個被標(biāo)記為Secure的地址以Non-secure狀態(tài)取指IAC就來了。驗證方法很簡單# 在SDK目錄下查看當(dāng)前構(gòu)建的版本 git log --oneline -1 # 查看TF-M和FIP的編譯時間 ls -l build/tfm/bin/tfm_bl2.bin build/fip/fip.bin # 用STM32CubeProgrammer讀取eMMC中實際燒錄的TF-M內(nèi)容 STM32_Programmer_CLI -c portUSB1 -r 0x00000000 0x20000 tfm_dump.bin然后把讀取出來的tfm_dump.bin和SDK里編譯出來的tfm_bl2.bin做對比用sha256sum算一下哈希不一致就說明eMMC里的TF-M不是你想燒的那一版。4.3 第三步核實eMMC分區(qū)布局與燒錄內(nèi)容STM32MP2的燒錄依賴flashlayout.tsv文件它定義了每個鏡像燒到eMMC的哪個分區(qū)、哪個偏移。我見過太多人直接把舊工程的tsv拿過來用結(jié)果新工程的FIP偏移變了都不知道。正確的檢查方式有兩個層面第一個層面工程編譯時生成的flashlayout.tsv要和實際燒錄時使用的完全一致。打開文件重點看TF-M和FIP兩行的偏移# 重點關(guān)注兩個關(guān)鍵行 tfm_bl2.bin boot1 0x00000000 fip.bin boot1 0x00004000如果TF-M燒到了boot1起始偏移但FIP被定義到boot2而你的啟動配置恰好選了boot1TF-M在boot1后續(xù)偏移讀FIP就會讀到空數(shù)據(jù)或者舊數(shù)據(jù)跳轉(zhuǎn)自然失敗。第二個層面通過STM32CubeProgrammer的-r命令把eMMC boot1分區(qū)完整讀出來和編譯產(chǎn)物逐個對比偏移處的內(nèi)容# 讀取eMMC boot1前512KB STM32_Programmer_CLI -c portUSB1 -r 0x00000000 0x80000 emmc_boot1_dump.bin對照tsv里的偏移看看對應(yīng)位置的鏡像哈希是否正確。這一步能把“燒錄位置不對”這個根因直接坐實或排除。4.4 第四步檢查BOOT引腳與OTP fuse的啟動源配置如果TF-M、FIP內(nèi)容都正確還是無限重啟就要懷疑啟動源本身是否和燒錄介質(zhì)一致。STM32MP257F-EV1上BOOT撥碼開關(guān)可以直接指定啟動介質(zhì)。DFU燒錄完成后如果撥碼還在DFU位置強行寫好了eMMC但沒切過去自然不會從eMMC啟動反過來如果撥碼在eMMC位置但OTP里fuse也已經(jīng)燒成eMMC啟動那么即使DFU撥碼想臨時覆蓋也可能被OTP的優(yōu)先級壓住。快速驗證方法把BOOT撥碼全部撥到DFU模式看板子能不能穩(wěn)定進(jìn)入DFU。如果能說明板子的基本啟動鏈路是通的。接著檢查OTP區(qū)域STM32_Programmer_CLI -c portUSB1 -otp read在輸出的OTP表里找BOOT相關(guān)字段確認(rèn)沒有寫入強制eMMC啟動的fuse。如果OTP里確實有內(nèi)容并且指向eMMC而你又確實想把系統(tǒng)留在eMMC那問題就回到eMMC內(nèi)部布局如果OTP指向其他介質(zhì)或者為空BOOT引腳就是唯一的決策者撥碼切到DFU后重?zé)纯伞?.5 第五步檢查U-Boot與fastboot的聯(lián)動配置最后再看fastboot為什么起不來。很多人以為fastboot是“USB枚舉層面”的問題但其實在這類故障里它只是結(jié)果系統(tǒng)在TF-M階段就崩了根本沒走到U-BootUSB gadget自然永遠(yuǎn)不會枚舉主機端fastboot waiting for device會一直等下去。如果前面的啟動鏈都正常了fastboot還進(jìn)不去才需要檢查U-Boot配置CONFIG_CMD_FASTBOOT有沒有打開CONFIG_USB_FUNCTION_FASTBOOT有沒有打開U-Boot設(shè)備樹里USB OTG節(jié)點EV1上是DWC3有沒有正確配置為peripheral模式是否設(shè)置了fastboot的啟動命令進(jìn)入方式比如按鍵觸發(fā)或環(huán)境變量控制。這里有個容易忽略的點Windows下fastboot識別設(shè)備需要正確的USB驅(qū)動Linux下需要udev規(guī)則。你可以先把USB線插到板子確認(rèn)系統(tǒng)有沒有新增USB設(shè)備。如果板子U-Boot正常起來了USB枚舉是能看到VID/PID的Linux下用lsusb就能看到一行類似STMicroelectronics的設(shè)備。看不到再往U-Boot配置里查。5. 修復(fù)與驗證強制DFU重刷讓板子回到正軌定位到根因之后修復(fù)本身并不復(fù)雜但每一步都要驗證避免“燒完還是老樣子”。5.1 先讓板子進(jìn)入強制DFU模式不管eMMC里是什么狀態(tài)只要BootROM還活著就能用BOOT引腳強制進(jìn)入DFU模式。具體操作斷開板子電源USB線也拔掉把BOOT撥碼開關(guān)撥到DFU/USB啟動方式EV1板卡上一般有絲印標(biāo)注按用戶手冊確認(rèn)用USB線連接板子的DFU口通常是標(biāo)著USB1或DFU的Type-C口到電腦上電。如果一切正常PC端會枚舉出一個USB設(shè)備Linux下lsusb能看到STMicroelectronics相關(guān)的設(shè)備Windows下設(shè)備管理器會出現(xiàn)一個STM32 Bootloader設(shè)備。此時用STM32CubeProgrammer連接STM32_Programmer_CLI -c portUSB1能連接成功說明BootROM和USB鏈路都沒有問題可以放心刷寫。5.2 校驗eMMC狀態(tài)并重新燒錄進(jìn)入DFU后先做一次eMMC的狀態(tài)檢查特別是boot分區(qū)的寫保護位# 檢查eMMC相關(guān)信息 STM32_Programmer_CLI -c portUSB1 -mmc info如果eMMC的boot分區(qū)被打上了寫保護直接燒錄會失敗或者“假成功”。確認(rèn)寫保護狀態(tài)后需要先解除保護再燒錄。STM32CubeProgrammer通常提供了命令行選項也可以直接在圖形界面里操作。如果有報錯提示寫保護就要先執(zhí)行解除寫保護的操作。接下來重新燒錄完整的Flash布局# 使用與當(dāng)前SDK版本匹配的flashlayout文件燒錄 STM32_Programmer_CLI -c portUSB1 -w flashlayout.tsv燒錄過程中留意每一條Download記錄的偏移和長度確認(rèn)TF-M寫入了boot1的起始地址FIP寫入了正確的偏移。燒錄完成后建議立刻用-r命令回讀校驗一遍不要直接切啟動否則萬一燒錯了還得重新進(jìn)DFU。5.3 切換啟動源并驗證啟動鏈燒錄校驗完成后斷電把BOOT撥碼切到eMMC啟動重新上電。此時串口應(yīng)該能看到完整的啟動日志TF-M: boot stage 2 TF-M: FIP loaded TF-A: BL31 OP-TEE: ... U-Boot: ... Linux: ...如果還是復(fù)現(xiàn)IAC exception 128先別急著重復(fù)燒寫?；氐降?章的排查鏈路重點檢查TF-M/FIP版本和boo1分區(qū)布局。我遇到過一次燒了三遍都沒解決的問題最后發(fā)現(xiàn)是工程里的tfm_bl2.bin和FIP不是同一次make的產(chǎn)物重新統(tǒng)一構(gòu)建后一次就過了。5.4 恢復(fù)fastboot的驗證方法啟動鏈恢復(fù)正常后U-Boot起來fastboot自然就能用了。驗證方法在U-Boot命令行下執(zhí)行fastboot usb 0主機端執(zhí)行fastboot devices能看到設(shè)備時執(zhí)行fastboot getvar version確認(rèn)通信正常。如果你在Linux主機上遇到fastboot waiting for device但USB設(shè)備能看到大概率是udev規(guī)則沒配上。在/etc/udev/rules.d/下加一條規(guī)則把ST的USB VID加入白名單然后udevadm control --reload即可。Windows下則要確認(rèn)設(shè)備管理器里是否識別成ADB Interface或Android Bootloader Interface沒有的話需要手動指定驅(qū)動。6. 把“無限重啟”轉(zhuǎn)化為可復(fù)用的排查方法論這類故障解決完我突然意識到一個問題IAC exception 128這類報錯對老手來說就是“版本不匹配”的代名詞但對剛接觸MP2平臺的人來說光看報錯根本無從下手。如果你把這個故障場景當(dāng)成一個案例從里面抽出一套可復(fù)用的排查方法大概可以濃縮成下面這張表排查維度檢查內(nèi)容快速定位方法異常階段TF-M日志打印到哪里串口完整日志鏡像版本TF-M與FIP是否同一次構(gòu)建sha256sum對比eMMC回讀內(nèi)容燒錄布局flashlayout.tsv是否匹配實際燒錄回讀eMMC分區(qū)并逐偏移檢查啟動源BOOT引腳/OTP fuse與實際介質(zhì)一致強制DFU驗證 otp readU-Boot配置fastboot相關(guān)configmenuconfig檢查 USB枚舉狀態(tài)這張表不僅適用于STM32MP257F-EV1也適用于任何帶TF-M/TrustZone安全啟動鏈的板級調(diào)試。核心思路是一個“從內(nèi)到外、從軟件到硬件”的排查順序先確認(rèn)異常發(fā)生在哪一層再檢查鏡像和布局最后才去動硬件。我個人的幾條實操體會最后分享幾個我踩過坑之后的習(xí)慣不一定寫在哪份文檔里但對板級調(diào)試很管用。第一盡量用同一個SDK版本統(tǒng)一構(gòu)建所有鏡像。TF-M、FIP、U-Boot、Linux全部在同一棵代碼樹下編譯禁止混用不同版本SDK的產(chǎn)物。MP2平臺的啟動鏈?zhǔn)沁B鎖反應(yīng)一個版本錯位就可能導(dǎo)致跳轉(zhuǎn)失敗而這些問題排查起來非常耗時。第二每次燒錄前先看一次eMMC狀態(tài)。特別是boot分區(qū)寫保護位。STM32CubeProgrammer連接后花幾秒鐘看一下mmc info確認(rèn)boot1、boot2都能正常訪問再燒能省掉很多“燒錄成功但起不來”的無效調(diào)試。第三回讀校驗是燒錄后必做的一步。燒完不要急著切啟動先花30秒把關(guān)鍵分區(qū)回讀出來和編譯產(chǎn)物做哈希對比。這個習(xí)慣讓我少走了很多彎路因為燒錄過程中出現(xiàn)“靜默失敗”的概率比想象高。DFU模式下偶爾會出現(xiàn)數(shù)據(jù)超時導(dǎo)致寫入不完整但工具不一定報錯回讀校驗是唯一可靠的兜底手段。第四BOOT引腳狀態(tài)和OTP fuse一致性檢查放在最后一步做。很多工程師一遇到啟動失敗就瘋狂撥BOOT開關(guān)其實是反的。先把內(nèi)容燒對、版本配好再檢查啟動源選擇。順序反了容易陷入“撥碼燒錄、燒錄撥碼”的死循環(huán)越調(diào)越亂。這組問題解決下來我對TF-M在MP2平臺上的定位有了更深的體會——它不只是安全組件更是整個啟動鏈的交通指揮中心。理解了這個角色再回頭看IAC exception 128就不覺得它有多神秘了。無非是“指揮中心給CPU指了一條不該走的路”。順著這個思路復(fù)盤你也能在十分鐘內(nèi)把這個故障從“鬼打墻”變成“一眼看穿”。