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