基于STM32芯片的工程代碼里有個很重要的文件，即啟動文件。該文件主要由匯編語言寫成，文件名冠以.s結(jié)尾，它是芯片程序運行首先要執(zhí)行的一個文件。其功能及作用簡單點說就是做執(zhí)行用戶程序前的基本準備，比方執(zhí)行復位程序初始化棧、堆，做時鐘系統(tǒng)的默認配置、中斷矢量表的定義與分配等。

網(wǎng)絡上有些文章對該文件做了不錯的整體性介紹，這里僅就該文件中的幾個小問題一起交流分享下?！咀ⅲ合旅嬗玫降墓こ淌腔赟TM32F429的，使用IDE為ARM MDK】

怎么在編譯后的MAP文件里看不到變量__heap_base？

有人發(fā)現(xiàn)在啟動文件里明明有定義__initial_sp和__heap_base，可在MAP文件里只看到__initial_sp的地址安排，卻死活找不到__heap_base的影子。為什么呢？

這是因為我們目前的工程代碼里沒有涉及到堆操作。雖然啟動文件里有針對HEAP的配置，但由于代碼里實際上沒用到堆，編譯時候就沒分配堆的地址相關信息，自然在MAP文件里找不到__heap_base。

以上圖為例，其實此時Heap_Size寫多大是沒啥實際意義的，寫0x200和寫0沒差別。這就像我們在代碼定義一些完全不會被用到的變量一樣，編譯時是不會被安排內(nèi)存空間的。

然而，如果我們在代碼里有涉及HEAP操作，若啟動文件里的HEAP配置依然如上圖所示，那情況就不一樣了。比方我們在用戶代碼做動態(tài)內(nèi)存分配，這里使用malloc函數(shù)進行動態(tài)內(nèi)存分配示例下。

這時我們再去查看MAP文件，就可看到堆的地址信息了，跟啟動文件里分配的一致。順便提醒下，我們在用戶代碼里做內(nèi)存動態(tài)分配時注意分配的空間大小要遵循啟動文件里預設的HEAP大小限制，必要時需做適當調(diào)整。

啟動文件里怎么用掉了1KB的RAM？

有人在查看STM32程序代碼編譯后的MAP文件時，發(fā)現(xiàn)啟動文件就用掉了1024B的RAM，如下圖所示。覺得有點奇怪，想知道這1KB用到哪里去了？是不是固定的？

我們知道啟動文件主要基于匯編寫成，實現(xiàn)些最基本的軟硬件初始化工作，似乎用不到這么多RAM。

其實，這里1KB初始值為0的RAM，是安排給棧用的，而這個棧大小的配置就是在啟動文件里實現(xiàn)，但并非僅限于用在啟動文件里。MAP文件里顯示的啟動文件所用ZI數(shù)據(jù)大小，跟下面棧配置是關聯(lián)的。

顯然，這個RAM開銷并非固定的。

盡管我們建立工程時可能有些默認配置或經(jīng)驗配置，但我們完全可以結(jié)合自身工程代碼的需要靈活調(diào)整。如果說，代碼里函數(shù)調(diào)用涉及到的局部變量較少、中斷嵌套情形也不多，你完全可以將棧數(shù)據(jù)設計得小些，或許很多時候512B【0x200】都綽綽有余了?？傊@個數(shù)據(jù)不是固定不變的，具體開發(fā)時按需調(diào)整。

比方，我將上面的?？臻g大小改為512B，再看看編譯后的結(jié)果。那個ZI Data大小也隨之而變了。

上面是基于?？臻g大小的調(diào)整來解釋啟動文件里ZI數(shù)據(jù)的大小變化。如果說我們的代碼里還用到堆，這時啟動文件里的ZI數(shù)據(jù)就不僅僅是?？臻g大小的數(shù)據(jù)了，還會包括堆空間的大小。比方，我們在代碼里啟用動態(tài)內(nèi)存分配使用到堆。在啟動文件里對堆、棧的配置如下：

按照上面配置并啟用動態(tài)內(nèi)存分配，再去查看編譯結(jié)果，基于啟動文件所用到的ZI數(shù)據(jù)大小變成了棧與堆空間二者之和。如下圖所示【1024+512=1536】：

啟動文件里的RO Data是怎么產(chǎn)生的？

有人在查看MAP文件時，發(fā)現(xiàn)啟動文件里產(chǎn)生了一批RO只讀數(shù)據(jù)，如下圖所示：

上圖是基于STM32F429的工程編譯后產(chǎn)生的，那個428 Bytes只讀數(shù)據(jù)怎么來的？

其實，這個數(shù)據(jù)就是存放中斷向量地址表所用到的，不同的系列這個數(shù)據(jù)會有差異。該向量表除了第一個字單元存放MSP棧頂?shù)刂吠?，其它均為系統(tǒng)異?；蛑袛嗳肟诘刂罚鳛槌Ａ繑?shù)據(jù)存放在FLASH里。我們具體看看這里的428B怎么來的。打開啟動文件，我們可以看到一串連續(xù)的DCD操作，如下圖所示：

以STM32F429為例，在啟動文件里稍微數(shù)數(shù)可得知這里共有107個地址入口項，每項用到一個4字節(jié)字，剛好對應上面的428 Bytes.

啟動文件里的__main函數(shù)跟用戶的main（）有關系嗎？

我們知道，啟動文件的主要功能就是為用戶程序的正常運行做最基本的初始化準備工作，__main（）函數(shù)就是完成該使命的重要一環(huán)。它是一個C庫初始化函數(shù)入口，主要負責執(zhí)行一些必要的代碼及數(shù)據(jù)從裝載區(qū)到執(zhí)行區(qū)的拷貝，將ZI內(nèi)存區(qū)的數(shù)據(jù)初始化為0。對C庫函數(shù)進行初始化，初始化堆、棧等，有時還可能包括一些代碼解壓操作，最后跳轉(zhuǎn)至用戶man（）函數(shù)運行用戶程序。

一般來講，關于這個__main（）函數(shù)的功能及作用大致了解就好，通常將其視為黑盒子。

啟動文件里對中斷矢量表起始地址進行初始化是在哪里實現(xiàn)的？

在STM32 MCU家族里，除了基于Cortex M0內(nèi)核的STM32F0系列外，都有個中斷矢量寄存器【SCB-》VTOR】用來初始化中斷矢量表的起始地址。它的初始化一般在啟動文件的復位程序里的SystemInit（）函數(shù)完成。

最后基于該話題順便給些提醒作為本篇結(jié)尾。我們在基于STM32芯片做IAP應用時，對于APP代碼記得做好VTOR的重定位【注：F0系列操作例外】；在從BOOT區(qū)跳轉(zhuǎn)到APP區(qū)之前先將剛才開啟過的所有中斷使能都禁用掉；如果開啟了Cache的話，也將Cache禁用掉；保證跳轉(zhuǎn)時清清爽爽，不捎一滴水，不帶一片云。

責任編輯：haq