芯耀
401
1、問題背景
客戶基于 STM32Cube 包下的 SBSFU 示例工程(STM32Cube_FW_U5_V1.2.0ProjectsB-U585I-IOT02AApplicationsSBSFU)開發(fā)，程序中從 Boot 程序跳轉(zhuǎn)到 Loader 程序是通過檢測 UserButton 是否按下或者 Appli 程序是否為空來決定是否跳轉(zhuǎn)到 Loader 程序。但客戶現(xiàn)實(shí)的應(yīng)用場景是，需要在 APP 中觸發(fā)從 Boot 程序跳轉(zhuǎn)到 loader 程序。這就需要在 Boot 工程中添加一個(gè)每次復(fù)位都能保持原來值的變量，用來標(biāo)記是否需要進(jìn)入到 loader 程序中?？蛻羰褂玫?IDE 為 STM32CubeIDE, 自己嘗試新增這個(gè)變量，但一直失敗。我這里幫客戶弄好后，特整理成文檔，以供后續(xù)有類似需求的客戶借鑒。
2、問題背景知識(shí)
2.1. 三種全局變量介紹
很多用戶以為全局變量只有兩種，一種是帶初始值的，比如 int a=100 ; 還有一種是不帶初始值的，如 int b ; 編譯器在為這兩種變量編譯時(shí)，代碼中會(huì)自動(dòng)(如 IAR)或半自動(dòng)(如STM32CubeIDE)為其生成一些 “拷貝數(shù)據(jù)”的代碼，在 MCU 復(fù)位時(shí)，代碼會(huì)將數(shù)據(jù)從flash 拷貝到內(nèi)存中(帶初始值的全局變量)，或者將對應(yīng)內(nèi)存中的變量初始值設(shè)置為 0(不帶初始值的全局變量)。這兩種變量，在 MCU 復(fù)位并代碼啟動(dòng)時(shí)，代碼均會(huì)將變量對應(yīng)內(nèi)存地址的值修改。因此，很多用戶均以為這是 MCU 的特性，其實(shí)并不是的，而是編譯器干預(yù)的結(jié)果，本質(zhì)上還是由代碼來執(zhí)行的結(jié)果。MCU 內(nèi)存的值，只要 VDD 不掉電，在非上電復(fù)位的情況下，RAM 中的內(nèi)容還是會(huì)保存之前的值的，只不過在復(fù)位且代碼運(yùn)行起來后，代碼去修改了它。這部分代碼往往隱藏在編譯器生成的代碼內(nèi)，在常規(guī) C 代碼內(nèi)是看不到的，從而使用戶產(chǎn)生了 MCU 復(fù)位會(huì)自動(dòng)清空 RAM 的假象。
其實(shí)，除了上述的兩類變量，還存在第三種變量，即 MCU 復(fù)位后其值依然保留，代碼不對其賦初始值，也不清空，僅僅每次復(fù)位(非上電復(fù)位)保持原來的值而已，這種變量即是此文要講的內(nèi)容。
另外，話說回來，STM32U5 的 SRAM 確實(shí)可以讓 MCU 復(fù)位時(shí)通過硬件自動(dòng)清空SRAM，此特性是通過選項(xiàng)字節(jié)來激活的，且默認(rèn)情況下并未激活。這是其一，此外，像STM32F1, F2, F4 這類傳統(tǒng) MCU 芯片并沒有此特性，它們在 MCU 復(fù)位時(shí)默認(rèn)也是保留原始值的(代碼對其賦了初始值或者清空)。有關(guān) U5 的硬件自動(dòng)清空 RAM 的特性后面我們將繼續(xù)講述。
2.2. SBSFU 工程介紹
STM32CubeU5 包下關(guān)于安全啟動(dòng)和安全固件升級(jí)(SBSFU)的示例工程其實(shí)有兩個(gè)，
- 一個(gè)是 TF-M 的實(shí)現(xiàn)方案: STM32Cube_FW_U5_V1.2.0ProjectsB-U585I
IOT02AApplicationsTFM
- 一個(gè)是基于 MCU boot 開源項(xiàng)目的實(shí)現(xiàn)方案(可理解成 TFM 方案的簡化版本):
STM32Cube_FW_U5_V1.2.0ProjectsB-U585I-IOT02AApplicationsSBSFU
SBSFU_Boot : 開源項(xiàng)目 MCU boot 移植后的參考實(shí)現(xiàn)。運(yùn)行在安全區(qū)域。簡稱為 Boot 工程。
SBSFU_Appli：即 APP_S,和 APP_NS。對應(yīng)安全和非安全 APP。
SBSFU_Loader：Loader 程序，也包含 Loader_S, Loader_NS 兩部分。
本文要討論的正是 SBSFU_Boot 工程。在此工程中添加一個(gè) no_init 變量。
