MCU application

前言 針對驗證簽名部分，因近期客戶需求但MCU部分被綁定無法放入SBSFU去做更新，而且SBSFU更新部分目前提供範例也僅UART，其他interface需要自己coding，最後這邊討論後只做簽名驗證來防程式被修改，該章節會介紹簽名驗證流程和原SBSFU流程 參考軟體包 這邊因單純驗證簽名因此直接參考x-cube-cryptolib即可，因這邊使用F4系列所以這邊參考比較舊相近系列L152，因G4或L4是相對較新的系列避免有些Function不存在 圖解流程基本上如下 其實可以看到MCU會需要處理部分主要是把資料轉換，因這邊選用是SHA256所以是把檔案轉換SHA256格式，再透過ECC校驗，這邊公/私鑰匙的生成是透過OpenSLL生成，使用為外部軟體非在MCU內執行生成 SBSFU簡介 因SBSFU是包含加密更新部分，而F4是屬於比較舊款因此支援部分沒有到這麼多參考圖如下 而已更新步驟來說會如圖，因此你可以看到如果需要加密更新你的code size不能太大另外，或你的Flash size需要夠大(APP Code需要2倍大小，這邊大概說明流程，因這次只使用到驗證簽名部分所以這邊就不詳細說明 ECC驗證簽名Code 在程式上會分成2部分 Boot code和APP code，App code部分比較簡單會透過外部軟體所增加標頭檔部分打包起來 這邊主要2個檔案需要修改1.system_stm32f4xx.c2.ld檔案 這邊是用python寫外部加密打包檔案這邊跟MCU較不相關未來再詳細說明 把APP剛剛規劃標頭檔相關位置填入，因驗證部分會需要知道相關資料位置 在執行檔中需要把Key引用帶入，在執行檔最後加入下方 鑰匙部分也是需要call外部軟體生成(OpenSLL) 最後在main.c部分就比較簡單主要是把加密驗證簽名部分補上即可，前半在做把鑰匙BIN和簽名BIN輸入陣列中 參考

前言 LCD的選擇有很多種，尺寸也很多，但若需要顯示彩色的畫面，這邊推薦ST7735， CP值最高，效果也不錯的。本範例將介紹ST7735 彩色1.8吋顯示螢幕與STM32的使用方式。這邊參考Arduino Adafruit函式庫，函式庫為所有的LCD和OLED顯示器提供了通用語法和圖形功能。 接線說明 這邊可以參考以下說明 Sample Code 這邊可以直接移植Arduino或網路直接抓Driver這塊因為便宜有更多人選用開放資源也很多 以下2個是最常使用到Function 下面可以看到是常用Fuction詳細內容 影片參考 ST7735驅動程式設計要點 參考

前言 這邊因為需求在開發USB DFU 時範例都是使用外部pin腳去做切換，但實際上使用情況是會址接USB或其他Interface去下達指令，使其去切換APP or Bootloader mode，但如果使用Flash當flag使用會受限於10K 次使用次數限制，這邊其實還可以使用SRAM去做 實作 基本上要在SRAM上作區塊來使用，切記要點是不能斷電，因斷電會讓SRAM reset這邊Flag就會被清除下面就可以參考SRAM位置宣告方式 針對SRAM位置可以參考Flash ld檔 因這邊是選用STM32F401RET6因此SRAM起始區域是從0x20000000開始，另外我們要使用區域要不能被初始化，不然每次在MCU reset時會導致SRAM內資料被清除，所以我們這邊選擇的END_SRAM_ADDR 會是從0x20017FEC為最後一個，SIZE也不是原先的96KB而是96KB-所要使用區域，而這個區塊就是不會受到MCU reset等影響 這邊可以看到可以使用指標形式去存取特定位置的address來當成旗標使用 參考

前言 客戶在部分設備中需要加密保護，ST這邊提供2種方式 V4的目錄結構 vs. V3的目錄結構 V3軟件包的目錄結構是每一個STM32系列對應一個單獨的目錄 V4的目錄結構則完全兼容Cube/X-Cube軟件包（STM32Cubexx / X-Cube-xxx）架構，方便與Cube/X-Cube包進行集成。 AES加密 這邊因客戶AES使用較多，會以AES做舉例說明。 AES介紹 AES 是一個 對稱的 加密類型。“對稱”意味著它使用 加密和解密的密鑰相同 信息此外， 都 發送方和接收方 的數據需要它的副本來解密密碼。另一方面， 非對稱 關鍵系統使用 每個不同的鍵 兩個過程：加密和解密。一個對稱系統的優勢 就像 AES 他們是 比非對稱快得多 那些。 這是因為對稱密鑰算法需要 更少的計算能力。 這就是為什麼非對稱密鑰最適合用於 外部文件傳輸。 對稱鍵更適合 內部加密. AES 流程 AES流程可以參考下面影片與圖，可以更加明白其操作 ST AES硬體加密 首先可以看到硬體加密的結構如圖ST也有提供4種模式 ST AES LIB軟體實現 這邊下載軟體包後需要把Lib加入專案中下面為Lib路徑 Middlewares\ST\STM32_Cryptographic 這邊使用以變相當便捷主要是呼叫cmox_cipher_encrypt此函數引用ST Lib即可使用 參考

前言 這邊ST推出STM32CubeAI與NanoEdge AI Studio 2款軟體針對不同用戶族群，這邊會針對SRM32CubeAI做初步介紹與使用(STM32CubeAI 目前是掛載在STM32CubeMX底下的軟體包X-Cube-AI，這邊STM32CubeAI僅針對第3方軟體做轉換，不能自動生成AI model) STM32CubeAI 這邊會由STM32CubeMX去更新下載軟體包，並將其第三方生成的軟體轉譯成C code掛在STM32CubeMX專案中 這邊直接照一般步驟生成專案後把X-cube-AI加上專案中 下一步驟針對STM32CubeMX加入X-Cube-AI轉譯軟體包 如範例這邊如果都完成按下分析會跑成功 在專案上就會出現對應接口，且model也會放置在middlewares上 結構 參考

前言 由於 STM32CubeProgrammer 中，對 Flash 支持的型號有限，只能覆蓋一部分 MCU和 Flash 的型號，無法完全滿足客戶的需求。stm32CubeMX 製作 external Flash loader 的方法。客戶可以根據自己的型號，進行定制化的生成。這邊使用Discovery STM32H750XB為基準-從CubeIDE+CubeMX建立Eternal Loader 給CubeProgrammer使用 STM32CubeMX設定 建立QSPI配置以及DriverFlashMemory 官方有寫好的Code複製到資料夾內 這邊官方有提供範例可以下載，可以再依照範例修改 STM32CubeIDE Code修正 quadspi.h的部份將官方提供的資料複製 要在CubeProgrammer上面顯示的資訊 建立linker.ld檔以及產生出stldr檔 根據所使用的FlashMemory做配置 Complier產生stldr檔 放到STM32CubeProgrammer可以存取到的資料夾內 參考

前言 STM32 微控制器具有內部溫度傳感器。 該傳感器非常粗略 (±1.5 °C)，並在內部連接到 ADC 通道的一個，這使得輕鬆獲取設備溫度成為可能，無需任何額外組件即可使用。但請注意此溫度為相對溫度非絕對溫度，且有溫度最高與最低限制無法完全取代一般sesnor 內部計算方式 這邊選用STM32WB35為主要參考(It support the temperature range –40 to 125 °C.)這部分可以參考各系列的reference manual未經校準的內部溫度傳感器更適合用於檢測的應用溫度變化而不是絕對溫度。 數值位置要點 這邊是TS_CAL1/TS_CAL2要從Datasheet中抓取出對應Flash位置數值TS_CAL1_TEMP與TS_CAL2_TEMP分別就是對應30與130 計算公式及修正如下 STM32CubeMX設定 這邊需要再ADC部份把Temperature Sensor Channel 與Vrefint Channel開啟，針對Vrefint Channel是可選的未得確定內部實際Vref電壓來提高精準度 STM32CubeIDE Code 這邊有2種方式可以選擇一種是直接寫公式如下code區域或使用官方給出Function 這邊主可以參考網路範例TMPSENSOR_getTemperature把其數值抓取下來公式部分修正即可 Note 有反映讀取內部溫度時不是標準3.3V時會建議使用__HAL_ADC_CALC_TEMPERATURE()The value returned by __HAL_ADC_CALC_TEMPERATURE() seems to be closer to the temperature measured on the microcontroller’s casing.在電壓Vref不是3.3時會建議使用__HAL_ADC_CALC_TEMPERATURE() refer Web 參考

IAP前言 IAP（In Application Programming，應用內編程），是指程序在運行過程中對User Flash的部分區域進行燒寫，目的是為了在產品發布後可以方便地通過預留的通信口對產品中的固件程序進行更新升級。 IAP流程 這邊是開啟2包專案，其中一包是DFU另一包APP則是看需求撰寫，流程如圖，為便捷開發我們都會以DFU為起始位置 USB DFU實作注意事項 這邊因是燒2包程式，把Flash切割成2個區塊，因此需要留意DFU在程式中所占比的空間與要轉跳到APP的指向位置 如圖這邊第一步是需要先確認DFU程式占比，一般會預留一些空間避免蓋到APP Flash 這邊要留意預留空間盡可能以一個page為單位，這邊範例以STM32CubeMX生成因DFU抓64kb為主體因此APP會燒入在0x8010000為起始，詳細參考各系列的reference_manual(這邊範例以STM32G0系列為出發) APP端燒入注意事項 使用STM32cubePrg燒入記得要去留意Start address避免去覆蓋到DFU程式區域，且要確定DFU轉跳位置須為APP起始位置 這邊一樣要去修訂ld檔，但要修訂ld檔啟示位置 這邊最後一步是要去修訂中斷向量表的Offset這邊就需要依照各自需求去做變化 這邊有個小要點，就是部分MCU會沒有RCC初始化這區塊，如果APP轉跳後不會動，可以把這塊初始化移植上去這塊在sample code上都會有但由STM32CubeMX生成檔案可能會缺少這區塊 轉跳參考機制 這邊提供官方範例是以按鈕做轉跳，如果也可以變通為特定flash位置數值判斷是否要執行DFU還是直接跳APP，這邊以APP起始位置為0x08010000作為範例 參考