前段時間接手了一塊板子主控是 STM32U5G9NJH6Q外掛一片 256Mbit 的 Octal NOR Flash用來放 UI 資源和字庫打算直接用 XIP 方式內存映射執行。硬件回來當天板子能通過 STM32CubeProgrammer 正常識別內部 Flash 燒寫也沒問題但一旦勾上 External Loader 去操作 OCTOSPI問題就來了要么 JEDEC ID 讀回來全是 0xFF要么燒寫中途校驗失敗要么直接報 Cannot load external loader。這類問題在 STM32U5 的高配型號上特別容易遇到因為 U5G9 的定位就是大存儲、高集成度很多人都會給它掛一片大型 Octal Flash/PSRAM而工程里最容易被忽略的恰恰是燒錄工具怎么訪問外部存儲器這一段鏈路。這篇文章我把自己排查過程中踩過的坑、驗證過的步驟以及最終沉淀下來的一套可復現流程完整寫出來方向包括工具版本與加載器匹配、OCTOSPI 初始化時序、物理層接線、以及常見的啟動/調試配置問題。做 U5 系列外掛存儲方案的工程師或者只是剛拿到 U5G9 開發板想把外部 Flash 燒錄跑通的入門用戶都可以按這個思路少走彎路。1. 先弄清楚 STM32CubeProgrammer 和 OCTOSPI 之間的真實協作關系1.1 為什么偏偏是 U5G9 上這個問題最讓人頭疼STM32U5G9NJH6Q 這顆料在 U5 家族里屬于性能比較高的配置Cortex-M33 內核內部集成了大容量 Flash 和大塊 SRAM還帶了多個 OCTOSPI 接口。很多人選這顆料就是看中它能外掛大容量 NOR Flash 或者 PSRAM把圖片、字庫、音頻資源甚至代碼放到外部存儲器里通過內存映射直接執行。這個用法本身沒問題但它給燒錄環節增加了一個非常容易被忽略的依賴燒錄工具必須先把外部存儲器初始化好才能往里寫數據。問題就出在這里。STM32CubeProgrammer 對內部 Flash 的燒錄是內置支持的工具通過 SWD 接口把燒錄算法加載進芯片 SRAM 執行一套流程全自動完成。但是外部 OCTOSPI Flash 不存在這種默認支持工具并不知道你的板子上掛了哪顆 Flash、用哪幾個 GPIO、支持什么指令集、Dummy Cycle 怎么配。它必須要一個針對具體板卡的外部加載器才知道怎么操作這顆 Flash這個加載器就是 .stldr 文件。一旦加載器缺失、不兼容、或者初始化時序和實際硬件不匹配你看到的就是各種各樣的燒錄異常。1.2 燒錄工具的執行邊界內部 Flash 能燒不代表外部 Flash 也能燒我一開始也犯過這個認知錯誤覺得STM32CubeProgrammer 能連上芯片外部 Flash 燒不進肯定是工具 bug。后來把原理理清楚才好辦STM32CubeProgrammer 本質上是一個上位機它通過 ST-LINK 等調試器訪問芯片的調試端口然后利用芯片自身執行的代碼去操作外設。內部 Flash 燒錄時工具會向芯片 SRAM 中加載一段由 ST 提供的內部燒錄算法CPU 執行這段算法去操作 FMC/Flash 控制器工具只負責傳輸數據和反饋狀態。外部 OCTOSPI Flash 是同樣的邏輯但燒錄算法換成了你的板級初始化代碼也就是 External Loader。工具先把 .stldr 加載到 RAM讓 CPU 執行其中的初始化函數把 OCTOSPI 外設、GPIO、時鐘、Flash 的讀/寫/擦除指令全部配置好之后才通過調試接口持續訪問內存映射區域完成數據的寫入和校驗。可以這么理解工具是一個發令員真正的搬運工是那段跑在芯片里的 loader 代碼。所以外部 Flash 燒不進八成是搬運工出了問題而不一定是發令員的問題。排查方向應該優先放在 loader 本身、loader 與硬件的匹配、以及 loader 運行所需的基礎環境上而不是一味重裝工具。1.3 我遇到的高頻癥狀一覽下面這個表格是我在實際項目和各種論壇帖子里見過最多的幾類現象后續所有排查思路都是圍繞這些表象展開的。癥狀典型現象最可能的根因外部 Flash 識別失敗Memory 窗口讀外部地址全 0xFF 或全 0x00GPIO 復用錯誤、Dummy Cycle 配置錯誤、Flash 供電/控制腳異常Loader 加載報錯Error: cannot load external loader.stldr 與芯片不兼容、路徑指向錯誤、工具版本過舊燒寫中斷/校驗失敗寫入一部分后報 verify error或擦除后仍讀回舊數據時鐘分頻太高、DTR/SDR 模式不匹配、Flash 指令配置錯誤連接階段失敗ST-LINK 能識別但 Target 無響應TrustZone/RDP 配置、啟動引腳狀態、復位電路異常工具識別型號錯誤U5G9 被識別成其他芯片或 unknownSTM32CubeProgrammer 版本太老、ST-LINK 固件沒升級看到內部 Flash 正常、外部 Flash 異常時可以先排除 SWD 鏈路和工具本身的問題把注意力放到外部存儲器子系統上。如果連型號識別都有問題那就要先解決連接和版本層面的問題再回頭看外部 Flash。2. 問題一外部 Flash 掛死讀 ID 全 0xFF 全 0x00 的排查鏈路2.1 先別改代碼物理層三件事必須確認我遇到讀回全 0xFF 這種情況第一反應是去翻 loader 里的初始化代碼結果翻了半天發現問題根本不在代碼層面而在最基礎的物理連接上。建議所有人先按下面三個順序排查再動軟件。首先是供電。U5G9 的 OCTOSPI 端口可以工作在 1.8V 或 3.3V具體取決于 VDDIO2 或者 IO 口所在的電源域。外部 Flash 的工作電壓必須和 MCU 的 IO 電平匹配。我曾經遇到過一塊板子Flash 供電是 1.8V但 MCU 的 IO 域被配置成 3.3V結果通信極不穩定讀 ID 時好時壞。這個用萬用表量一下就能發現不要想當然認為原理圖上畫的一定對。其次是控制腳的默認狀態。Octal NOR Flash 一般都有 WP#、HOLD#、RESET# 這些控制腳如果它們在初始化過程中沒有被正確拉高或釋放Flash 可能會處于寫保護或者掛起狀態導致所有讀寫命令都沒有響應。很多最小系統圖里只畫了數據線和時鐘線控制腳的處理容易忽略。實際排查時可以先把這些腳手動強制到正確電平比如把 WP# 和 HOLD# 都拉高看讀 ID 是否恢復。最后是接線和測量。OSPI 跑起來之后頻率不低哪怕初始化階段跑得慢IO 線上的干擾也會導致命令字出錯。如果 Flash 和 MCU 之間用了杜邦線或者很長的排線先把連線縮短到 5cm 以內再試。有條件的話用示波器或者邏輯分析儀看 CS、CLK、IO0 這幾個關鍵信號確認時鐘有沒有出來、片選有沒有正常拉低、數據線上有沒有波形這一步能極大縮小排查范圍。2.2 區分命令沒到達 Flash和Flash 有響應但返回錯誤物理層確認沒問題后可以通過現象判斷故障點在鏈路的哪一段。讀外部內存映射區域如果返回全 0xFF通常意味著 Flash 認為當前沒有數據輸出可能原因是命令沒有到達、或者 CS/CLK 時序不對、或者 Flash 處于深度掉電模式。如果返回全 0x00往往說明 Flash 已經在響應但讀到的數據是 0可能是誤觸發了寫操作、地址線配置錯、或者讀命令不對。還有一個很實用的技巧直接把 OCTOSPI 的時鐘分頻調到最低把速率降下來。很多 flash 型號對高速模式有要求比如 DTR 模式下的 tV 時序參數如果 loader 里配置的 dummy cycles 和實際設備不匹配讀操作就會失敗。把頻率降到幾十 MHz 以下用 SDR 模式、單線模式去讀 ID往往能繞過大部分時序問題先確認物理鏈路是否通暢。等能穩定讀到 ID 了再逐步提高速率、切換模式就能定位到具體是哪個參數導致的問題。2.3 Loader 中的 GPIO 復用和 Dummy Cycle 才是重災區排除了物理層之后剩下的基本都在 loader 的配置參數里。我見過最多的問題集中在 GPIO 復用和 Dummy Cycles 這兩個地方。GPIO 復用問題非常隱蔽。很多板卡參考設計里 OCTOSPI 的引腳會被復用為其他功能比如調試串口、LCD 接口、或者普通的 GPIO 控制腳。如果 loader 初始化時把引腳設置成了 AF 模式但 AF 號選錯那通信肯定不通。還有一個細節是 U5G9 的不同封裝、不同引腳映射可能對應不同的 AF 值同樣一個功能在 F4 上是一個 AF 號在 U5 上可能是另一個不能憑經驗照搬。最可靠的做法是在 STM32CubeMX 里根據實際原理圖的引腳分配生成初始化代碼再把它移植到 loader 工程中而不是手寫 GPIO 配置。Dummy Cycles 是另一個高頻坑。Octal Flash 在 Fast Read、Dual/Quad/Octal 模式下通常都需要插入若干 dummy 周期具體數量由 SFDP 表或者數據手冊決定。如果 loader 里配置的 dummy 周期比 Flash 實際需要的少讀數據時 Flash 還沒把數據準備好總線上讀到的就是垃圾數據如果配多了讀取速度會下降但不至于完全失敗。這里最容易踩坑的是讀 JEDEC ID 成功但讀數據失敗的現象因為讀 ID 命令通常不要求 dummy cycle而讀數據命令要求所以有些人會誤以為初始化和接線沒問題實際上數據讀取路徑上的 dummy 配置是錯的。3. 問題二External Loader 加載失敗或燒錄校驗不過3.1 .stldr 文件的本質和兼容性.stldr 文件不是一個配置文件而是一段可執行的固件它面向的是目標芯片而不是 PC。STM32CubeProgrammer 加載它時會把這段代碼下載到芯片 RAM 中特定地址然后通過約定的函數指針調用其中的初始化、讀、寫、擦除等接口。這就帶來一個關鍵約束.stldr 的構建目標必須和實際使用的芯片匹配。我之前遇到過一個案例同事從別的項目里拷貝了一個加載 H7 系列外部 Flash 的 .stldr 文件想著都是 STM32可能通用結果在 U5G9 上怎么都加載不了。原因很簡單不同系列的內核、外設寄存器地址、甚至 RAM 布局都不同這段 loader 在 U5G9 上要么無法運行要么運行后訪問的是錯誤的外設地址。正確做法是去 STM32CubeProgrammer 安裝目錄下的 ExternalLoader 文件夾里找有沒有針對 U5 系列的 .stldr如果沒有就需要自己用 STM32CubeMX 生成一個 external loader 工程編譯出來。還有一種兼容性問題表現得更隱蔽loader 能加載工具也不報錯但燒寫時校驗不過。這時要檢查 loader 的接口版本是否和 STM32CubeProgrammer 匹配。ST 在升級工具時偶爾會調整 loader 的接口結構老的 loader 用新工具加載可能某些功能字段缺省導致讀操作正常、寫操作異常。遇到這種問題優先從官方渠道獲取與工具版本配套的 loader 文件。3.2 CubeProgrammer 版本和 ST-LINK 固件都可能是元兇很多人遇到 U5G9 識別異常第一反應是硬件壞了但我見過更多情況只是工具版本問題。STM32U5G9 屬于較新的型號它的內核 ID、DBGMCU IDCODE、以及調試訪問接口都有特定的標識。早期的 STM32CubeProgrammer 版本內置的設備數據庫里沒有這個型號工具要么識別成未知設備要么連接后 SVD 映射錯誤導致操作外部外設時行為怪異。解決辦法很直接先把 STM32CubeProgrammer 升級到最新版本。另外 ST-LINK 調試器本身也有固件如果固件版本太老它對新款芯片 SWD 協議的支持可能不完整。在 STM32CubeProgrammer 的 Help 菜單里找到 Firmware upgrades把 ST-LINK 固件也一并升到最新很多時候問題就消失了大半。這里提醒一下升級前最好記錄一下當前版本。因為有一次我升級完 STM32CubeProgrammer 之后發現團隊里其他人還在用舊版本兩個版本的工程配置格式有差異結果我生成的燒錄腳本在他們環境里跑不了又折騰了一陣子。版本統一這件事在團隊協作里比個人技巧更重要后面我會專門說。3.3 下載渠道和工具完整度搜索熱詞里很多人問STM32CubeProgrammer 除了官網還有其他下載地址我的建議是別折騰直接用官方渠道。一個原因是第三方下載站經常滯后你明明搜索到的是最新版點進去可能還是幾個月甚至一兩年前的版本對新芯片支持不完整另一個更現實的原因是有安全風險燒錄工具要下載固件到芯片里如果有人篡改過安裝包后果不是藍屏那么簡單。STM32CubeProgrammer 的官方獲取方式有幾種去 ST 官網產品頁面按提示注冊后下載或者如果你的電腦裝了 STM32CubeMX在 Help 菜單里可以檢查并安裝工具鏈更新也可以從 STM32CubeIDE 的安裝目錄里找到它自帶的版本。官方安裝包還包括驅動程序和完整的 ExternalLoader 目錄第三方精簡版經常把 ExternalLoader 目錄、固件升級包、甚至 USB 驅動裁掉這可能正是你外部 Flash 操作失敗的深層原因。4. 問題三連接階段就失敗或識別不準確4.1 連接方式選擇Hot Plug 與 Under Reset如果 STM32CubeProgrammer 連 ST-LINK 都連接不上或者偶爾能連上、第二次就失敗先檢查連接方式。GUI 的連接設置里有 Hot Plug 和 Under Reset 兩種模式本質區別在于連接時是否控制目標芯片的復位引腳。Hot Plug 模式適合目標芯片已經正常運行、調試接口沒有沖突的場景它直接通過 SWD 協議訪問內核不需要復位芯片。Under Reset 模式則是連接前先拉低復位讓芯片保持在復位狀態再初始化調試訪問等調試器接管后再釋放復位。對于 U5G9 這種內置 TrustZone 的芯片如果安全配置或者選項字節已經被改過Hot Plug 模式可能因為調試訪問權限問題導致連接失敗而 Under Reset 模式往往能繞過去。我自己的習慣是新板子第一次連接優先用 Under Reset 模式連接成功后再切回 Hot Plug 驗證。如果 Under Reset 也連不上那基本可以判斷是硬件復位電路或供電問題而不是軟件問題。另外SWD 的復位腳如果被外部電容拉得太死或者復位電路設計不當也可能導致 Under Reset 模式失敗這時可以試一下把 resetHWrst 換成軟件復位。4.2 復位、供電、TrustZone 與 RDP 等級U5 系列比之前的 STM32 多了一個容易踩的坑TrustZone 和讀保護等級 RDP 會直接影響調試連接。如果芯片之前被設置成 RDP Level 1 或更高等級調試端口就不會像默認狀態那樣開放STM32CubeProgrammer 連接時會報錯或者只能執行受限操作。對于工廠新拿到的芯片默認狀態一般沒問題但如果板子被嘗試過加密、或者升級過選項字節就需要先通過全擦除等方式把保護等級降回 Level 0 才能正常調試。TrustZone 開啟后調試訪問還需要區分安全和非安全世界。如果 loader 代碼被放在了非安全區域但 OCTOSPI 外設被配置成僅安全訪問loader 初始化時就會觸發 fault表現就是加載 loader 后沒有反應、讀出來的數據異常。這個問題在只有裸機程序、沒有啟用 TrustZone 的應用里不常見但如果你的工程使用了帶 TrustZone 的軟件包就要特別注意了。供電方面U5G9 有大電流需求的引腳和多個電源域供電不穩時最典型的表現不是完全連不上而是連接后跑一段時間就斷或者燒錄到一半失敗。這種情況用示波器看 VDD 在燒錄瞬間是否有跌落比懷疑工具配置更有效。還有一個容易忽略的點是外部 Flash 的 VCC 是否和 MCU 的電源域同步上電如果 Flash 上電比 MCU 慢loader 初始化時 Flash 還沒準備好讀 ID 也會失敗。4.3 用命令行復現和定位連接問題GUI 界面雖然直觀但連接類問題我更喜歡用命令行來復現因為命令行輸出更明確而且方便把完整命令貼給同事分析。比如STM32_Programmer_CLI -c portSWD modeUR resetHWrst如果這條命令能正常列出 target 信息說明 SWD 鏈路、ST-LINK 固件、工具版本都沒問題。如果報錯錯誤信息里通常會有詳細原因比如 No STM32 target found 或 Error: Activating device failed。命令行還有一個好處是可以在同一條命令里把外部 loader 和操作都串起來方便做最小復現STM32_Programmer_CLI -c portSWD modeUR -el C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\ExternalLoader\xxx.stldr -w app.bin 0x70000000 -v這里的地址 0x70000000 是 U5 系列 OCTOSPI 內存映射區域的常見起始地址具體要以目標芯片參考手冊中的 memory map 為準。如果命令行能完成燒寫而 GUI 不行那就要檢查 GUI 里 External loader 的配置路徑是不是和命令行不一致如果命令行也報錯那錯誤信息能直接把問題定位到 loader 還是連接。5. 一套可以直接抄的排查與恢復流程5.1 環境準備清單下面這幾件事不做完我不會開始排查任何 U5G9 的燒錄問題先列出來給你參考STM32CubeProgrammer 升級到最新版本記錄當前版本號。ST-LINK 固件通過 Help Firmware upgrades 升級到最新確認指示燈狀態正常。安裝官方版本工具確認安裝目錄下有 ExternalLoader 文件夾且能看到至少一個 U5 系列相關的 .stldr。用萬用表確認目標板 VDD、VDDIO 供電正常外部 Flash 的 VCC 符合規格。確認 SWDIO、SWCLK、NRST 三根線連接正確GND 共地排線盡量短。查看芯片選項字節狀態確認 RDP 等級為 Level 0TrustZone 配置符合調試需求。5.2 GUI 操作步驟環境確認后GUI 操作按這個順序來打開 STM32CubeProgrammer在右側選擇 ST-LINK 接口連接方式選 Under Reset點擊 Connect。連接成功后先確認右下角識別出的芯片型號是 STM32U5G9xx不是 Unknown。打開 External programming configuration勾選 External loader瀏覽選擇你板卡對應的 .stldr 文件。下載一個測試用的空 bin 文件到外部 Flash 地址或者直接在 Memory 窗口輸入外部映射地址讀取內容驗證是否能讀到有效數據。如果讀到的內容仍舊全 0xFF 或 0x00切到命令行模式執行同樣的操作對比輸出。這里有一個細節External loader 勾選后工具會自動關聯外部存儲器的訪問區域。如果你在 GUI 里看不到外部 Flash 對應的地址空間先檢查是否是因為連接時沒有加載 loader而不僅僅是配置選項的問題。GUI 的 Memory 窗口如果顯示的是芯片內部映射那說明 loader 沒有被正確掛載。5.3 命令行操作與腳本示例命令行比 GUI 更適合做腳本化量產也更容易復現問題。下面是我常用的幾條命令先驗證目標連接STM32_Programmer_CLI -c portSWD modeUR resetHWrst -ob displ這條命令可以讀取并顯示選項字節狀態確認保護等級和啟動配置。再加載外部 loader 并讀取外部 Flash 內容-r 讀取到本地文件STM32_Programmer_CLI -c portSWD modeUR -el xxx.stldr -r ext_flash.bin 0x70000000 0x1000如果讀取成功說明 loader 和外部 Flash 之間的讀寫鏈路基本沒問題可以嘗試擦除和燒寫STM32_Programmer_CLI -c portSWD modeUR -el xxx.stldr -e 0x70000000 0x100000 -w app.bin 0x70000000 -v注意 -e 擦除的地址和長度都要和實際 Flash 容量匹配不要把長度設置超過 Flash 末尾地址否則操作會失敗。燒寫后加 -v 參數做校驗如果校驗失敗大概率是 loader 配置的擦除/寫入指令與時序不匹配。5.4 還是沒有解決回歸最小系統驗證如果你執行到這一步問題還在我最強烈的一個建議是不要繼續在完整板卡上反復試做一個最小系統出來。把 U5G9 最小啟動電路和一顆已知型號、有官方參考驅動的 Octal NOR Flash 接在一起用 ST 官方評估板的 loader 文件試試。我見過太多問題其實是完整板卡的某個干擾源比如其他外設的 GPIO 沖突、LCD 數據線占了 OCTOSPI 引腳、甚至 PCB 布局導致信號完整性問題這些在最小系統里都會被放大出來更容易定位。最小系統上如果還是讀不到 ID那就耐心地用示波器抓一次 CS、CLK、IO0 的時序。注意讀 JEDEC ID 命令 0x9F 發出后Flash 應該在第八個時鐘之后開始輸出 ID 字節。如果 CLK 有波形但 IO0 一直是高電平說明命令沒被 Flash 正確解析多見于命令編碼或者引腳映射錯誤如果 IO0 有波形但讀出的數值明顯不符合這顆 Flash 的 ID那多半是時序參數問題比如 dummy cycle 或時鐘極性/相位。5.5 我常用的幾個技巧分享幾個不在官方文檔里寫得特別明顯的經驗。第一加載外部 loader 時優先用絕對路徑不要用相對路徑。我曾經在命令行里用相對路徑結果在不同工作目錄下執行一個成功一個失敗排查了好久才發現是路徑問題。第二遇到燒寫中途失敗先把擦除和燒寫分開執行不要一步到位。很多問題其實是擦除沒成功導致燒寫時 Flash 里的數據不是全 0xFF校驗一比對就報錯。先單獨執行擦除讀回確認全 0xFF 后再燒寫能省掉大量時間。第三如果 ST-LINK 連線較長板子供電又偏弱可以在 SWD 時鐘頻率上降速。GUI 里連接設置一般有頻率選項默認自動協商但長線環境下手動降低到 1MHz 以下反而更穩定。這個和 OCTOSPI 的頻率不是一個概念但經常被忽略。6. 一些值得長期記住的工程經驗6.1 版本統一比個人技巧更重要排查完 U5G9 這個問題后我第一個反思是團隊版本一致性。STM32CubeProgrammer、STM32CubeMX、ST-LINK 固件、甚至外部 loader 文件任何一項版本不一致都會復現出不同的現象。一個人的經驗如果建立在特定版本上換一個環境就不適用了這是嵌入式開發的常態。建議在工程文檔里固定一套版本組合并寫明兼容的 .stldr 來源。新成員加入時先按照文檔安裝工具而不是讓每個人自己找最新版。尤其對外部 Flash 燒錄這種強依賴 loader 的流程一個團隊最好共用同一個 ExternalLoader 目錄不要各存各的。6.2 硬件設計時給 OSPI Flash 留條后路這次排查最耗時間的物理層問題如果在原理圖設計階段就規避掉后面能省很多事。我的建議是WP# 和 HOLD# 默認接上拉到 VCC調試時可以通過跳線帽臨時斷開。Flash 的 RESET# 用 MCU 的 GPIO 控制便于軟件復位 Flash而不是強制斷電。給 Flash 的供電單獨加磁珠或去耦電容減少其他外設帶來的電源噪聲。在原理圖中標注清楚 OCTOSPI 數據線用的 AF 號和實際封裝引腳方便寫 loader 時對照。這些不算復雜但能極大降低量產階段燒錄不良的返工成本。6.3 量產燒錄建議走 CLI 腳本量產階段不要用 GUI 手工燒錄一是效率低二是容易誤操作。CLI 腳本的好處是把加載 loader、擦除、燒寫、校驗、讀回都固化成標準流程換任何人都能一鍵執行。腳本里最好加上前置檢查比如先讀取目標型號不等于 STM32U5G9xx 就直接退出避免燒錯板卡。我的一個量產腳本大致長這樣STM32_Programmer_CLI -c portSWD modeUR resetHWrst -ob displ if errorlevel 1 exit /b 1 STM32_Programmer_CLI -c portSWD modeUR -el loader.stldr -e 0x70000000 0x800000 STM32_Programmer_CLI -c portSWD modeUR -el loader.stldr -w firmware.bin 0x70000000 -v每次燒錄完成后把日志保存下來萬一出問題可以追溯是哪一步失敗的。這套流程跑通之后真的能少接很多售后電話。6.4 關于工具下載再啰嗦一句回到很多人搜索的STM32CubeProgrammer 下載地址問題。如果你在某個第三方下載站看到了所謂綠色版完整版我的建議仍然是避而遠之。燒錄工具直接操作芯片固件安全性要求很高一次非官方包導致的驅動缺失、loader 目錄不全、甚至捆綁惡意軟件損失的時間遠超省下來的那點下載步驟。官方渠道需要注冊但也就是幾分鐘的事換來的是可靠和安心。如果實在無法訪問官網也可以通過 STM32CubeMX 的嵌入式軟件包管理器、或者已安裝的 STM32CubeIDE 自帶版本獲取這些都是 ST 官方發布的渠道。回到 OCTOSPI 問題本身我最后想強調一點U5G9 的外掛 Octal Flash 燒錄本質是對芯片 板級 loader 工具版本這三者匹配關系的驗證。工具報錯只是表面現象根因通常藏在更底層。把鏈路逐段打通比盲目重裝工具、換電腦、換調試器有效得多。希望這篇記錄能幫你少走幾個彎路。