前陣子接手一個需要OTA升級和防抄板的產(chǎn)品在選型階段就被安利了ST官方的X-CUBE-SBSFU。說實話第一次看到這個擴展包的名字我以為是某個冷門庫翻完AN5056應(yīng)用筆記才發(fā)現(xiàn)這玩意兒其實是STM32整個安全生態(tài)里非常關(guān)鍵的一環(huán)Secure Boot和Secure Firmware Update也就是安全啟動和安全固件更新。如果你打算做帶遠程升級的物聯(lián)網(wǎng)設(shè)備、表計、網(wǎng)關(guān)或者任何對固件完整性和機密性有要求的嵌入式產(chǎn)品這篇筆記值得花時間看完。1. AN5056到底在解決什么SBSFU在固件安全體系中的位置很多工程師第一次接觸X-CUBE-SBSFU會有一個困惑我已經(jīng)有IAPIn-Application Programming了為什么還需要SBSFU這兩個東西聽起來都是在做引導(dǎo)和固件更新到底有什么區(qū)別答案是SBSFU不是簡單地把Flash里的代碼搬到RAM然后跳轉(zhuǎn)過去它解決的是信任鏈的問題。IAP只是“從A處拷貝到B處”但SBSFU做了三件IAP做不到的事驗簽確認固件來源可信、解密防止固件被逆向提取、回滾保護防止攻擊者刷入舊版本的漏洞固件。AN5056這份應(yīng)用筆記描述的就是整個SBSFU的集成方法。它基于STM32CubeMX這個圖形化配置工具通過勾選X-CUBE-SBSFU擴展包自動生成一個包含安全啟動和安全固件更新的工程骨架。開發(fā)者只需要在這個骨架上掛載自己的應(yīng)用代碼就能獲得一條完整的信任鏈。這個信任鏈的邏輯是這樣的芯片上電后第一個執(zhí)行的代碼不是你的應(yīng)用而是SBSFU自己。SBSFU會先檢查內(nèi)部Flash或者外部Flash里的固件鏡像簽名是否正確、版本號是否高于當前已安裝的版本、加密數(shù)據(jù)能否被正確解密。全部通過后才會把控制權(quán)交給用戶應(yīng)用。如果驗簽失敗或者鏡像損壞SBSFU會進入固件升級模式等待接收新的固件包。這就像機場安檢你應(yīng)用固件需要先過安檢SBSFU驗簽安檢員會核對你的身份證件簽名是不是官方簽發(fā)、有沒有過期版本號確認無誤才放你進入候機廳運行。如果有任何黑名單回滾保護哪怕身份證是合法的也會被攔下來。所以X-CUBE-SBSFU適合哪些場景主要有三類一是需要遠程升級并且擔心固件被篡改的產(chǎn)品二是固件里包含算法或業(yè)務(wù)邏輯、需要防止被逆向提取的商業(yè)設(shè)備三是需要滿足行業(yè)安全規(guī)范比如金融、電力、醫(yī)療的設(shè)備制造商。對于學生項目或者純學習用SBSFU也能幫你理解安全啟動的完整實現(xiàn)。2. 集成前的準備工具鏈、擴展包環(huán)境與真實門檻先別急著打開STM32CubeMX生成工程集成SBSFU之前有幾個前置條件必須確認清楚。很多人在這一步栽了跟頭然后誤以為SBSFU是個“半成品”其實只是準備工作沒做到位。2.1 硬件要求不是所有STM32都支持SBSFUSBSFU對MCU是有要求的。它需要芯片具備以下特性之一支持TrustZoneM33/M55內(nèi)核、帶有OTP一次性可編程區(qū)域、有足夠的內(nèi)部Flash來存放兩份固件鏡像、支持RDP讀保護級別。像STM32L4系列、STM32F4系列、STM32H7系列這些主流型號大概率沒問題但如果是老舊的F1系列或者Flash特別小的型號就得仔細查一下AN5056里面的支持列表了。舉例來說STM32F746和STM32L496都有對應(yīng)的SBSFU工程模板但同一個系列里不同型號的Flash大小差異會導(dǎo)致分區(qū)方案不同。如果你用的是F746ZG1024KB Flash但參考的是F746NG1024KB的模板分區(qū)配置基本可以照搬但如果用的是Flash只有512KB的型號就得自己重新規(guī)劃分區(qū)。2.2 軟件版本STM32CubeMX、擴展包和固件包的三角關(guān)系這是最容易出問題的地方。SBSFU擴展包不是獨立的它依賴對應(yīng)系列的固件包STM32Cube FW F1、FW L4、FW H7這些。在STM32CubeMX的Embedded Software Manager里你選擇MCU型號后會自動列出推薦的固件包版本但X-CUBE-SBSFU擴展包需要單獨在“Additional Software”選項卡里勾選。我遇到過的情況是這樣的打開CubeMX選擇了STM32H743ZI固件包選了STM32Cube FW_H7 V1.11.0然后在Additional Software里找到了X-CUBE-SBSFU V4.0.0看起來一切正常。但點“Generate Code”的時候CubeMX彈出一個錯誤提示大意是the firmware package (stm32cube fw_h7 v1.12.1) or one of its dependencies requires...這個報錯意味著當前安裝的固件包版本比擴展包預(yù)期的版本低需要升級FW_H7到V1.12.1。解決辦法有兩個一是在Help菜單里的Manage Embedded Software Packages中升級固件包二是在Additional Software里選擇與當前固件包匹配的SBSFU版本。這個依賴關(guān)系非常嚴格版本差一點點都過不去。2.3 安裝SBSFU擴展包的正確姿勢如果你用的是較新版的CubeMXV6.8以上安裝擴展包非常方便。打開CubeMX進入“Help” - “Manage Embedded Software Packages”在“STMicroelectronics”標簽下會看到X-CUBE-SBSFU的列表勾選需要的版本后安裝即可。需要注意一個細節(jié)SBSFU包下載非常慢經(jīng)常裝到一半就超時。如果遇到這種情況優(yōu)先檢查網(wǎng)絡(luò)環(huán)境或者手動從ST官網(wǎng)下載壓縮包后導(dǎo)入。具體操作是在Manage Embedded Software Packages窗口里點擊“From Local...”按鈕選擇下載好的包文件CubeMX會解析并安裝。安裝完成后擴展包會出現(xiàn)在STM32CubeMX的嵌入式軟件管理器中并且會在你新建工程時自動匹配對應(yīng)的MCU型號。2.4 深入閱讀AN5056的必要性最后一點是文檔本身的閱讀。AN5056這份應(yīng)用筆記有幾十頁包含了架構(gòu)說明、內(nèi)存映射、集成步驟、錯誤碼定義等多個部分。我建議重點閱讀第三章“Architecture”和第五章“Integration”這兩章解釋了SBSFU代碼在Flash中的布局以及用戶應(yīng)用如何鏈接到SBSFU之后。跳著讀容易漏掉關(guān)鍵的內(nèi)存映射信息后面連接腳本出問題時根本不知道原因。3. 用STM32CubeMX生成SBSFU工程核心配置與分區(qū)規(guī)劃確認前置條件都滿足后接下來的操作就順理成章了。這一節(jié)我把生成SBSFU工程的完整步驟、核心配置項、以及最容易踩的分區(qū)規(guī)劃問題一起說清楚。3.1 創(chuàng)建工程并選擇擴展包打開STM32CubeMX選擇你的MCU型號我以STM32L496ZG為例在頂部菜單欄的“Additional Software”中選擇X-CUBE-SBSFU。選好后CubeMX會自動彈出SBSFU的配置界面核心是“Project Type”里的三項選擇Security BootSecure Firmware Update完整功能Security Boot only僅安全啟動不做固件升級Firmware Update only僅固件升級不校驗啟動對于新項目我會選擇第一項完整功能。原因很簡單SBSFU的兩種功能安全啟動和安全升級本來就是協(xié)同工作的割裂開反而增加了后續(xù)集成的復(fù)雜度。3.2 配置項詳解簽名算法、密鑰長度和Flash布局在SBSFU配置界面里重點需要關(guān)注這些配置項配置項可選值我的建議簽名算法RSA2048 / RSA3072 / ECDSA P-256新項目推薦ECDSA P-256驗簽速度快密鑰短固件加密AES-GCM / AES-CTR如果固件里有敏感算法選AES-GCM更安全用戶應(yīng)用起始地址由SBSFU自動計算默認即可但需要關(guān)注Flash分區(qū)情況Slot數(shù)量1個或2個如果Flash緊張用1個slot也可以啟動時先擦除再寫入回滾保護Enable/Disable必須Enable防止攻擊者降級固件版本配置完這些之后有一個很關(guān)鍵的環(huán)節(jié)內(nèi)存映射檢查。CubeMX會顯示一個Flash分區(qū)的圖包括SBSFU自身存放的區(qū)域一般是Flash起始的幾頁安全配置區(qū)域存放密鑰、版本號等信息Slot 0活動鏡像區(qū)Slot 1下載待激活鏡像區(qū)對于L496ZG這種有1MB Flash的芯片默認分區(qū)方案是SBSFU占128KBSlot 0占400KBSlot 1占400KB剩下的一些頁留給系統(tǒng)數(shù)據(jù)和安全存儲。如果你的應(yīng)用固件本身比較大比如超過了400KB的編譯產(chǎn)物就需要調(diào)整分區(qū)。調(diào)整分區(qū)的操作一定要在CubeMX里做不要手動改連接腳本。因為CubeMX會根據(jù)分區(qū)配置自動生成對應(yīng)MCU的鏈接腳本.icf、.sct或.ld文件手動改的話一旦重新生成代碼就會丟失。3.3 用戶應(yīng)用工程的正確生成方式SBSFU的工程結(jié)構(gòu)是雙工程的一個工程是SBSFU引導(dǎo)程序另一個工程是你的用戶應(yīng)用。在CubeMX里生成時代碼會分成兩個文件夾每個文件夾都有自己的工程文件。有個很多新手都會犯的錯誤直接把應(yīng)用代碼塞進SBSFU工程里寫。這樣做會導(dǎo)致SBSFU代碼和應(yīng)用代碼在同一個鏈接腳本里Flash地址完全錯亂。正確的做法是保持SBSFU工程獨立不要修改它的核心代碼sbsfu.c、sfu_low_level_flash.c這些文件。在生成出來的用戶應(yīng)用工程里寫自己的業(yè)務(wù)代碼。編譯SBSFU工程得到sbsfu.bin編譯用戶應(yīng)用工程得到user_app.bin。用ST提供的簽名工具對user_app.bin進行簽名生成帶簽名的user_app_signed.bin。這里我多說一句關(guān)于簽名工具的使用。AN5056文檔里使用的工具通常是STM32CubeProgrammer配套的腳本或者SBSFU工程里的postbuild.bat。它需要你導(dǎo)入一個私鑰文件PEM格式執(zhí)行后會在編譯輸出的目錄里自動生成已簽名的固件。整個過程看起來像是一個黑盒但實際上只是把二進制文件和RSA簽名以及加密后的AES密鑰拼接到一起。3.4 雙鏡像啟動時的硬件依賴還有一點容易忽略SBSFU在跳轉(zhuǎn)到用戶應(yīng)用之前會重新配置系統(tǒng)時鐘、關(guān)閉之前打開的外設(shè)、清理棧區(qū)。如果你的用戶應(yīng)用沒有自己初始化時鐘而是依賴SBSFU配置的狀態(tài)那么跳轉(zhuǎn)后很可能會跑飛。這一點在AN5056里有明確說明但依然有開發(fā)者忽略它。我的建議是用戶應(yīng)用的啟動代碼SystemInit函數(shù)里顯式重新初始化時鐘和Flash等待周期不要依賴SBSFU留下的任何狀態(tài)。這是一種“互不信任”的安全設(shè)計但恰恰是穩(wěn)定性的保證。4. 安全啟動與安全升級的運行鏈路從驗簽到跳轉(zhuǎn)的原理拆解配置完工程并且能編譯通過你會發(fā)現(xiàn)代碼能跑但這不意味著你真的理解了SBSFU在做什么。為了更好地排查問題和調(diào)整行為必須把它內(nèi)部的運行邏輯搞清楚。4.1 安全啟動的完整流程SBSFU運行起來之后內(nèi)部的執(zhí)行流程大致如下初始化階段SBSFU從Flash起始地址開始執(zhí)行首先初始化堆棧指針、中斷向量表配置系統(tǒng)時鐘。讀取鏡像頭信息在Slot 0和Slot 1的位置讀取固件鏡像的頭部。這個頭部包含了魔數(shù)、版本號、固件大小、簽名區(qū)域偏移、實際固件數(shù)據(jù)的哈希值等信息。版本比較比較兩個Slot中固件的版本號選擇版本號更高且有效的那個作為“候選鏡像”。如果啟用回滾保護還會和OTP中記錄的最低允許版本比較。驗簽用預(yù)置在Flash安全區(qū)域的公鑰對鏡像頭部的簽名進行非對稱解密運算得到摘要值再和實際固件數(shù)據(jù)計算出的哈希值比對。這一步是整個信任鏈的核心因為只有用私鑰簽過名的固件才能通過驗簽。解密與裝載如果啟用了固件加密SBSFU會用存儲在安全區(qū)域的AES密鑰解密固件數(shù)據(jù)然后裝載到RAM或者直接原地解密。跳轉(zhuǎn)執(zhí)行驗簽通過后SBSFU設(shè)置一個有效標志跳轉(zhuǎn)到用戶應(yīng)用的復(fù)位向量。4.2 安全升級流程中Slot切換的關(guān)鍵點安全固件升級的流程通常發(fā)生在用戶應(yīng)用運行時。用戶應(yīng)用接收到新的固件包通過UART、SPI、以太網(wǎng)或者無線鏈路先在RAM里做初步校驗然后通過SBSFU提供的API接口把新固件寫入非活動Slot即Slot 1。寫入完成后應(yīng)用會觸發(fā)一個重啟。重啟后SBSFU再次執(zhí)行第2步和第3步它發(fā)現(xiàn)Slot 1的版本號高于Slot 0于是把Slot 1作為新的候選鏡像驗簽通過后跳轉(zhuǎn)執(zhí)行。如果驗簽失敗SBSFU會回退到Slot 0啟動舊固件同時記錄一個“嘗試過升級但失敗”的事件。這里有個非常重要的概念叫“候選鏡像確認”SBSFU不能一驗簽通過就直接認為新固件永遠可用而是要等待新固件自己運行起來之后通過調(diào)用SBSFU_RequestAppend或SFU_APPLI_SetInstallationStatus之類的API主動確認。如果新固件沒有及時確認下次重啟時SBSFU還會認為它是“未確認”狀態(tài)可能再次回退到舊固件。這個特性很多剛接觸SBSFU的人不理解覺得只要寫完固件重啟就算升級成功了。實際上要讓升級動作“永久生效”你必須在新應(yīng)用的業(yè)務(wù)代碼里主動調(diào)用確認函數(shù)。否則一旦設(shè)備在升級后頻繁掉電重啟每次都會回退到舊版本造成升級失敗的假象。4.3 安全隱患為什么要雙Slot而不是直接覆蓋你可能想問為什么不直接覆蓋舊固件非得搞兩個Slot答案是“原子性”。如果升級過程中突然斷電直接覆蓋會導(dǎo)致舊固件也丟了新固件也沒寫完設(shè)備變成磚。雙Slot方案保證了任何時候都至少有一個有效固件可以啟動。這也是SBSFU的核心理念系統(tǒng)永遠處于可啟動狀態(tài)。所以雙Slot是安全設(shè)計里很值得借鑒的思想很多量產(chǎn)產(chǎn)品寧愿多花一倍Flash空間也要保證升級的穩(wěn)健性。5. 從Demo到量產(chǎn)密鑰管理、安全配置與Flash分區(qū)調(diào)整在MDK工程里編譯通過、用開發(fā)板跑起Demo這只是萬里長征第一步。真正到了產(chǎn)品化階段有幾個環(huán)節(jié)如果處理不好SBSFU形同虛設(shè)。5.1 密鑰管理私鑰等于產(chǎn)品的命脈SBSFU的安全核心在于公鑰驗證、私鑰簽名。理論上即使攻擊者拿到了固件沒有私鑰也做不出一個能通過驗簽的惡意固件。但前提是你的私鑰必須妥善保管。ST默認生成工程時會自帶一組測試密鑰放在工程的SBSFU_Keys目錄或者編譯腳本引用的路徑下。開發(fā)階段用測試密鑰沒問題但量產(chǎn)前必須換成自己生成的密鑰對。否則任何人都可以從網(wǎng)上找到這組默認測試密鑰用它們給惡意固件簽名然后通過SBSFU的正常升級流程刷入設(shè)備。生成新密鑰對的方法很簡單用OpenSSL命令就可以了openssl genrsa -out private_key.pem 2048 openssl rsa -in private_key.pem -pubout -out public_key.pem生成之后把公鑰配置到SBSFU工程中通常是通過key_rsa_pub.c文件或者CubeMX配置界面上導(dǎo)入把私鑰保存在一個離線、安全、有權(quán)限控制的環(huán)境里。私鑰一旦泄露整個安全體系就土崩瓦解了。5.2 安全配置區(qū)域的燒錄RDP和OTPSBSFU的安全性依賴芯片的硬件保護機制。STM32CubeProgrammer支持設(shè)置RDP等級Level 0無保護任何人都能讀出Flash。Level 1禁止通過調(diào)試接口讀寫Flash但可以通過連接復(fù)位等方式恢復(fù)Level 0。Level 2永久鎖定不可回退芯片變磚級保護。SBSFU的Demo工程通常建議燒錄時把RDP設(shè)置為Level 1或Level 2。Level 1可以讓你在開發(fā)階段還有后悔的余地Level 2一旦設(shè)置就永久沒了調(diào)試和讀回Flash的權(quán)限。量產(chǎn)前建議直接用Level 2把產(chǎn)品徹底鎖定。但要注意設(shè)置Level 2之前務(wù)必確認你的SBSFU固件和用戶應(yīng)用固件已經(jīng)完全驗證通過因為一旦鎖死想通過JTAG/SWD重新刷固件是不可能的。OTP區(qū)域用來存什么一部分SBSFU會把“最低允許固件版本號”存在OTP里配合SBSFU的版本號檢查實現(xiàn)強制升級。比如你把min_version 5寫入OTP那么任何版本號低于5的固件都無法啟動。這個機制是用來應(yīng)對“舊固件被破解”的場景的哪怕攻擊者拿到了舊版本固件里面有已知漏洞也無法刷入設(shè)備。5.3 Flash分區(qū)調(diào)整的實戰(zhàn)技巧前面說過可以在CubeMX里調(diào)整Flash分區(qū)。但如果你的產(chǎn)品Flash空間非常局促需要手動調(diào)整分區(qū)時有幾個關(guān)鍵地址需要弄清楚SBSFU_BASESBSFU代碼起始地址。SFU_MEM_APPLI_0Slot 0的起始地址。SFU_MEM_APPLI_SLOT_1Slot 1的起始地址。SE_KEY_BASE安全密鑰存儲區(qū)地址。這些地址在CubeMX生成的sfu_low_level_flash.h或stm32l4xx_hal_flash.h中有定義。調(diào)整分區(qū)的本質(zhì)是修改這些宏定義同時保持Flash頁面對齊。以STM32L4系列為例Flash頁大小是2KB所以你設(shè)置的地址必須是2KB的整數(shù)倍。否則Flash寫入函數(shù)會返回錯誤碼。我在項目里遇到過一個情況默認分區(qū)中Slot 0只給了400KB但應(yīng)用固件編譯出來超過400KB導(dǎo)致簽名工具報錯“image is too big”。解決方案是把Slot 0和Slot 1都調(diào)整為448KB同時把SBSFU區(qū)域從128KB壓縮到64KB。因為我的SBSFU不需要支持外部Flash64KB足夠了。5.4 與VSCode開發(fā)方式結(jié)合的一點思考有些工程師有疑問sbsfu在vscode里怎么用實際上CubeMX生成的工程是包含多個IDE的Keil、IAR、GCCMakefile。VSCode其實是通過打開GCC Makefile工程來開發(fā)的。你只需要在工程根目錄執(zhí)行make或者通過VSCode的Cortex-Debug等插件來完成編譯和燒錄。SBSFU對開發(fā)工具鏈本身沒有綁定關(guān)鍵點是makefile里的路徑要配置正確特別是STM32CubeProgrammer的安裝路徑和Python環(huán)境。如果你習慣VSCode我建議保留CubeMX生成GCC Makefile工程然后用VSCode打開這個文件夾。這樣既保持了CubeMX的圖形化配置能力又能用VSCode的代碼跳轉(zhuǎn)、智能提示、Git管理這些功能。注意每次從CubeMX重新生成代碼后makefile可能會被覆蓋需要留意是否有自定義修改被沖掉。6. 實戰(zhàn)中繞不開的坑包依賴、鏈接腳本與構(gòu)建問題排查最后這部分重點寫踩坑經(jīng)驗。我把常見的SBSFU集成問題整理成一條完整的排查鏈路按“報錯現(xiàn)象 - 原因 - 解決方式”的思路講。6.1 包依賴錯誤FW版本和擴展包不匹配這是我在前面提到的Stm32Cube FW包和擴展包版本不匹配的問題。典型報錯信息有兩種the firmware package (stm32cube fwf1 v1.8.7) or one of its dependencies requires... the firmware package (stm32cube fw_h7 v1.12.1) or one of its dependencies requires...出現(xiàn)這種報錯的原因是X-CUBE-SBSFU的配置腳本在生成代碼時會檢查一個內(nèi)部版本號清單它需要對應(yīng)系列固件包的最低版本。修復(fù)方式分兩步打開STM32CubeMX的“Help” - “Manage Embedded Software Packages”找到對應(yīng)系列FW_F1/FW_H7等點擊升級到報錯信息里提示的版本號?；氐焦こ淘贏dditional Software里重新勾選SBSFU擴展包點“Generate Code”前先確認工程設(shè)置里的固件包版本已切換到了新版本。如果升級后依然報錯重啟一下CubeMX再試有時是因為軟件包管理器沒有自動刷新。6.2 編譯通過但鏈接報錯符號未定義與連接腳本不匹配SBSFU工程用了大量自定義的鏈接段memory region如果你的編譯器版本和CubeMX默認的編譯器不匹配可能會出現(xiàn)這樣的鏈接錯誤undefined symbol: sbsfu_region_start undefined symbol: sbsfu_boot_region_end這類符號定義在SBSFU的連接腳本里例如Keil的.sct文件、IAR的.icf文件或GCC的.ld文件。如果你的工程文件被CubeMX重新生成過而你沒有重新指定連接腳本就會導(dǎo)致符號丟失。排查方法確認工程選項里鏈接腳本指向的是CubeMX生成的那份腳本。如果腳本存在打開腳本搜索這些符號看是否拼寫一致。如果鏈接腳本被無關(guān)的IDE配置覆蓋了從CubeMX重新生成一次工程。6.3 運行后死機或跑飛中斷向量表與Flash等待周期SBSFU跑起來后跳轉(zhuǎn)到用戶應(yīng)用時死機是常遇到的問題?？赡艿脑蛴袃蓚€第一個是中斷向量表沒有重定位。用戶應(yīng)用的啟動文件里必須用SCB-VTOR APP_ADDRESS的方式把中斷向量表偏移到用戶應(yīng)用的起始地址。在SBSFU的Demo工程里這一步一般通過CubeMX生成的SystemInit或startup文件完成。但如果你自己寫啟動代碼很容易漏掉這個操作。第二個是Flash等待周期。STM32的主頻不同需要的Flash等待周期也不同。如果SBSFU里設(shè)置了較高的主頻而你跳轉(zhuǎn)到用戶應(yīng)用后沒有重新初始化時鐘用戶應(yīng)用可能因為Flash等待周期不足而跑飛。解決方式是在用戶應(yīng)用里重新調(diào)用SystemClock_Config把時鐘和Flash等待狀態(tài)重置為正確的值。6.4 簽名工具生成的固件無法通過驗簽開發(fā)階段經(jīng)常遇到的另一個問題是把簽名后的固件燒錄到設(shè)備SBSFU驗簽失敗日志顯示錯誤碼是SFU_ERROR_IMG_AUTH_FAIL或者類似的簽名驗證錯誤。排查思路確認公鑰和私鑰是否匹配。ST默認工程的公鑰是寫死在SBSFU代碼里的簽名工具使用的是私鑰。如果你換過密鑰對必須兩邊一起換。確認固件生成工具的選項。有的簽名工具會根據(jù)鏡像大小自動添加填充字節(jié)如果你在生成時指定了錯誤的slot大小簽名后的固件包含的填充數(shù)據(jù)可能導(dǎo)致哈希不匹配。確認對齊方式。SBSFU要求鏡像首地址對齊到16字節(jié)如果地址不對齊哈希計算時會讀取到不同的數(shù)據(jù)。6.5 燒錄時無法連接RDP等級設(shè)置過高的自救這是開發(fā)過程中最“刺激”的問題把RDP等級設(shè)置成了Level 2然后發(fā)現(xiàn)固件還有Bug需要升級但調(diào)試接口被永久鎖死了。我的建議是開發(fā)階段絕對不要設(shè)置Level 2用Level 1就夠。Level 1雖然也限制了調(diào)試接口但通過STM32CubeProgrammer的“Reset”或者“Remove Protection”操作可以回到Level 0代價是Flash會被全部擦除保不住了但至少芯片還能用。而Level 2一旦寫入就算你用各種手段也救不回來除非器件本身支持與ST的特約服務(wù)接口相關(guān)聯(lián)的暫存解鎖那基本等于送回原廠處理。寫在最后一點個人體會如果讓我用一句話總結(jié)SBSFU的集成經(jīng)驗?zāi)蔷褪窍壤斫庑湃捂溤僮雠渲米詈髮懘a。X-CUBE-SBSFU不是傳統(tǒng)意義上的“庫”它對工程結(jié)構(gòu)、編譯流程、燒錄流程都有影響任何一個環(huán)節(jié)的配置失誤都可能導(dǎo)致固件無法啟動。不要試圖從網(wǎng)上隨便找一段配置直接套在自己的板子上每個MCU的Flash布局、每個工程的鏈接腳本都可能不同。拿到一塊新板子建議按這個順序走一遍先跑通Demo工程確定SBSFU能啟動、能升級再修改密鑰然后調(diào)整分區(qū)最后集成你的應(yīng)用代碼。一步一步驗證能省下大量排查問題的精力和時間。我這里記錄的多半是走過的彎路和最終的解決方式希望你在集成路上少踩幾個和我一樣的坑。