STM32 Bootloader與啟動分析

**：

三種啟動模式如下表：

（截圖與stm32中文參考資料）

截圖來自文件an26062

截圖來自文件an26062

截圖來自正點原子開發板

二、stm32啟動分析

預備知識：

dcd指令：用於分配一片連續的字儲存單元(32bit)，並將表示式的值初始化給該字儲存單元，類似於c中定義陣列並初始化。比如： dcd 0 的意思是：分配乙個字儲存單元，並將該單元初始化為0。

分析：

在stm32的啟動檔案中可以看到有如下**：

export __vectors

__vectors

dcd __initial_sp ; top of stack

dcd reset_handler

dcd nmiexception

dcd hardfaultexception

dcd memmanageexception

dcd busfaultexception

dcd usagefaultexception

dcd 0 ; reserved

dcd 0 ; reserved

dcd 0 ; reserved

dcd 0 ; reserved

dcd svchandler

dcd debugmonitor

dcd 0 ; reserved

dcd ospendsv

……這一段是分配stm32的中斷向量表。從dcd後面表示式的名稱可以看出第乙個字儲存單元分配給了棧頂，其值為__initial_sp。第二個字分配給了復位位址，其值為reset_handler，後面接著分配給其他異常或中斷。

這裡的reset_handler，nmiexception等，其實是乙個位址值，也就是中斷處理函式的入口位址。在函式實現時，由編譯器分配乙個位址值。

那麼這裡就有兩個問題。

第乙個是為什麼是這樣的分配順序？

第二個是dcd後面表示式的值，即各個中斷函式的位址值如reset_handler，nmiexception是如何分配的？

第乙個問題的答案好找，我們參考《stm32參考手冊》：

可以看到，啟動檔案中的向量表的分配的順序是按照固定的規則來的。

第二個問題。隨意開啟乙份編譯過的工程，工程配置如下：

我們可以看到.map檔案有這樣一段：

同時使用j-link開啟.hex檔案可以看到

從hex檔，我們可以看到flash的起始區域0x8000000的內容為

0x20000660

0x0800027d

0x08000281

0x08000283

……剛好可以和map檔案對應，也剛好可以和啟動檔案的向量表對應。

按照cortex-m3權威指南，在復位後，有如下動作：

我這裡是選擇從flash啟動，根據暫存器對映，address從0x00000000對映到0x08000000。所以hex檔的內容剛好滿足復位序列的設定。

由此從啟動檔案到.map檔案再到.hex文件，再到cm3復位啟動的脈絡就理清了。

STM32 Bootloader位址跳轉相關

stm32 的向量表 使用者 的首位址處放的是堆疊位址，首位址 4的地方放的是 的復位位址，所以1，是把使用者 的復位位址賦值給 jumpaddress。2 是把使用者 的堆疊位址寫入堆疊指標3，是把使用者 的復位位址付給 pc指標 這句話的意思是把使用者 的首位址裡面的資料拿出來，看看是不是以 0...

STM32 Bootloader與啟動分析

三種啟動模式如下表 截圖與stm32中文參考資料 截圖來自文件an26062 截圖來自文件an26062 截圖來自正點原子開發板 二 stm32啟動分析 預備知識 dcd指令 用於分配一片連續的字儲存單元 32bit 並將表示式的值初始化給該字儲存單元，類似於c中定義陣列並初始化。比如 dcd 0 ...

stm32 復位到內部bootloader

sm32的bootloader一般是通過開機時設定boot0 1來實現的。下面是通過程式來實現 原來的startup檔案是直接把flash的資料載入到ram裡面然後跑main函式迴圈 bootloader的程式在0x1fff d800 那只要在進入main函式之前先判斷是否要進入bootloader...