stm32在manin()前做了什么?
最近要在Cortex-M3上寫一個(gè)簡單的操作系統(tǒng),打算使用IAR,為了寫好啟動(dòng)代碼,花了一些時(shí)間了解了IAR在main()以前做了些什么事。
首先系統(tǒng)復(fù)位時(shí),Cortex-M3從代碼區(qū)偏移0x0000'0000處獲取棧頂?shù)刂?,用來初始化MSP寄存器的值。
接下來從代碼區(qū)偏移0x0000'0004獲取第一個(gè)指令的跳轉(zhuǎn)地址。這些地址,是CM3要求放置中斷向量表的地方。
這里是一個(gè)程序的啟動(dòng)區(qū)的反匯編:
__vector_table:
080040002600
080040022000
080040047E1D
080040060800
這個(gè)程序是由IAP程序來啟動(dòng)的,IAP程序獲取0x0800'4000處的MSP值(0x20002600),并設(shè)置為MSP的值,即主堆棧最大范圍是0x2000'0000~0x2000'25FF。接下來IAP程序獲取0x0800'4004處的Reset_Handler的地址(0x0800'7E1D),并跳轉(zhuǎn)到Reset_Handler()執(zhí)行。
IAP在這里完全是模仿了Cortex-M3的復(fù)位序列,也就是說,在沒有IAP的系統(tǒng)上,CM3只能從0x0800'0000獲取MSP,從0x0800'0004獲取第一條指令所處地址。而IAP就存在在0x0800'0000這個(gè)地址上,IAP的啟動(dòng),已經(jīng)消耗掉了這個(gè)復(fù)位序列,所以IAP要啟動(dòng)UserApp程序的時(shí)候,也是完全模仿Cortex-M3的復(fù)位序列的。
接下來我們看看復(fù)位后第一句指令——Reset_Handler()函數(shù)里有什么。
若我們使用的是ST公司標(biāo)準(zhǔn)外設(shè)庫,那么已經(jīng)有了現(xiàn)成的Reset_Handler,不過他是弱定義——PUBWEAK,可以被我們重寫的同名函數(shù)覆蓋。一般來說,我們使用的都是ST提供的Reset_Handler,在V3.4版本的庫中,可以在startup_stm32f10x_xx.s中找到這個(gè)函數(shù):
PUBWEAK Reset_Handler
SECTION .text:CODE:REORDER(2)
Reset_Handler
LDRR0, =SystemInit
BLXR0
LDRR0, =__iar_program_start
BXR0
看來ST沒有做太多的事,他只調(diào)用了自家?guī)焯峁┑腟ystemInit函數(shù)進(jìn)行系統(tǒng)時(shí)鐘、Flash讀取的初始化,并把大權(quán)交給了__iar_program_start這個(gè)IAR提供的“內(nèi)部函數(shù)”了,我們就跟緊這個(gè)__iar_program_start跳轉(zhuǎn),看看IAR做了什么,上面一段代碼的反匯編如下:
Reset_Handler:
__iar_section$$root:
08007E1C4801LDRR0, [PC, #0x4]; LDRR0, =SystemInit
08007E1E4780BLXR0;BLXR0
08007E204801LDRR0, [PC, #0x4];LDRR0, =__iar_program_start
08007E224700BXR0;BXR0
08007E246C69
08007E260800
08007E287D8D
08007E2A0800
細(xì)心的觀眾會(huì)發(fā)現(xiàn)地址是0x0800'7E1C,比我們查到的0x0800'7E1D差了1,這是ARM家族的遺留問題,因?yàn)锳RM處理器的指令至少是半字對(duì)齊的(16位THUMB指令集or 32位ARM指令集),所以PC指針的LSB是常為0的,為了充分利用寄存器,ARM公司給PC的LSB了一個(gè)重要的使命,那就是在執(zhí)行分支跳轉(zhuǎn)時(shí),PC的LSB=1,表示使用THUMB模式,LSB=0,表示使用ARM模式,但在最新的Cortex-M3內(nèi)核上,只使用了THUMB-2指令集挑大梁,所以這一位要常保持1,所以我們查到的地址是0x0800'7E1D(C=1100,D=1101),放心,我們的CM3內(nèi)核會(huì)忽略掉LSB(除非為0,那么會(huì)引起一個(gè)fault),從而正確跳轉(zhuǎn)到0x0800'7E1C。
從0x0800'7E20處的加載指令,我們可以算出__iar_program_start所處的位置,就是當(dāng)前PC指針(0x0800'7E24),再加上4,即0x0800'7E28處的所指向的地址——0x0800'7D8D(0x0800'7D8C),我們跟緊著跳轉(zhuǎn),__iar_program_start果然在這里:
__iar_program_start:
08007D8CF000F88CBL__low_level_init
08007D902800CMPR0, #0x0
08007D92D001BEQ__iar_init$$done
08007D94F7FFFFDEBL__iar_data_init2
08007D982000MOVSR0, #0x0
08007D9AF7FDFC49BLmain
我們看到IAR提供了__low_level_init這個(gè)函數(shù)進(jìn)行了“底層”的初始化,進(jìn)一步跟蹤,我們可以查到__low_level_init這個(gè)函數(shù)做了些什么,不是不是我們想象中的不可告人。
__low_level_init:
08007EA82001MOVSR0, #0x1
08007EAA4770BXLR
__low_level_init出乎想象的簡單,只是往R0寄存器寫入了1,就立即執(zhí)行"BX LR"回到調(diào)用處了,接下來,__iar_program_start檢查了R0是否為0,為0,則執(zhí)行__iar_init$$done,若不是0,就執(zhí)行__iar_data_init2。__iar_init$$done這個(gè)函數(shù)很簡單,只有2句話,第一句是把R0清零,第二句就直接"BL main",跳轉(zhuǎn)到main()函數(shù)了。不過既然__low_level_init已經(jīng)往R0寫入了1,那么我們還是得走下遠(yuǎn)路——看看__iar_data_init2做了些什么,雖然距離main只有一步之遙,不過這中間隱藏了編譯器的思想,我們得耐心看下去。
__iar_data_init2:
08007D54B510PUSH{R4,LR}
08007D564804LDRR0, [PC, #0x10]
08007D584C04LDRR4, [PC, #0x10]
08007D5AE002B0x8007D62
08007D5CF8501B04LDRR1, [R0], #0x4
08007D604788BLXR1
08007D6242A0CMPR0, R4
08007D64D1FABNE0x8007D5C
08007D66BD10POP{R4,PC}
08007D687C78
08007D6A0800
08007D6C7C9C
08007D6E0800
看來IAR遲遲不執(zhí)行main()函數(shù),就是為了執(zhí)行__iar_data_init2,我們來分析分析IAR都干了些什么壞事~
首先壓R4,LR入棧,然后加載0x0800'7C78至R0,0x0800'7C9C至R4,馬上跳轉(zhuǎn)到0x0800'7D62執(zhí)行R0,R4的比較,結(jié)果若是相等,則彈出R4,PC,然后立即進(jìn)入main()。不過IAR請(qǐng)君入甕是自不會(huì)那么快放我們出來的——結(jié)果不相等,跳轉(zhuǎn)到0x0800'7D5C執(zhí)行,在這里,把R0指向的地址——0x0800'7C78中的值——0x0800'7D71加載到R1,并且R0中的值自加4,更新為0x0800'7C7C,并跳轉(zhuǎn)到R1指向的地址處執(zhí)行,這里是另一個(gè)IAR函數(shù):__iar_zero_init2:
__iar_zero_init2:
08007D702300MOVSR3, #0x0
08007D72E005B0x8007D80
08007D74F8501B04LDRR1, [R0], #0x4
08007D78F8413B04STRR3, [R1], #0x4
08007D7C1F12SUBSR2, R2, #0x4
08007D7ED1FBBNE0x8007D78
08007D80F8502B04LDRR2, [R0], #0x4
08007D842A00CMPR2, #0x0
08007D86D1F5BNE0x8007D74
08007D884770BXLR
08007D8A0000MOVSR0, R0