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

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

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

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

這是因?yàn)槲覀兡壳暗墓こ檀a里沒有涉及到堆操作。雖然啟動(dòng)文件里有針對(duì)HEAP的配置，但由于代碼里實(shí)際上沒用到堆，編譯時(shí)候就沒分配堆的地址相關(guān)信息，自然在MAP文件里找不到__heap_base。

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

然而，如果我們?cè)诖a里有涉及HEAP操作，若啟動(dòng)文件里的HEAP配置依然如上圖所示，那情況就不一樣了。比方我們?cè)谟脩舸a做動(dòng)態(tài)內(nèi)存分配，這里使用malloc函數(shù)進(jìn)行動(dòng)態(tài)內(nèi)存分配示例下。

這時(shí)我們?cè)偃ゲ榭碝AP文件，就可看到堆的地址信息了，跟啟動(dòng)文件里分配的一致。順便提醒下，我們?cè)谟脩舸a里做內(nèi)存動(dòng)態(tài)分配時(shí)注意分配的空間大小要遵循啟動(dòng)文件里預(yù)設(shè)的HEAP大小限制，必要時(shí)需做適當(dāng)調(diào)整。

啟動(dòng)文件里怎么用掉了1KB的RAM？

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

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

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

顯然，這個(gè)RAM開銷并非固定的。

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

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

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

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

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

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

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

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

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

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

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

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

啟動(dòng)文件里對(duì)中斷矢量表起始地址進(jìn)行初始化是在哪里實(shí)現(xiàn)的？

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

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

責(zé)任編輯：haq