絕大多數(shù)產(chǎn)品開(kāi)發(fā)，軟件一般都會(huì)設(shè)計(jì)成 boot + app 的形式，這是方便后續(xù)軟件更新，否則更新會(huì)變成一個(gè)很麻煩的事情。

網(wǎng)上隨處可見(jiàn)的跳轉(zhuǎn)程序大概如下：

#define APP_START_ADDR          0x08040000 


voidjump2app()
{
typedefvoid(*func_app_start)(void);
   
__disable_irq();

func_app_start app_start=(func_app_start)(*(__IOuint32_t*)(APP_START_ADDR+4));
  
__set_MSP(*(__IOuint32_t*)(APP_START_ADDR));//設(shè)置棧頂?shù)刂?/span>


app_start();
}

大多數(shù)情況下，該程序跳轉(zhuǎn)正常，但當(dāng)你改變了編譯器優(yōu)化級(jí)別時(shí)，可能直接就 hardfault 了。

此時(shí)你會(huì)莫名其妙，為什么？？？

從魚(yú)鷹18年接觸到 boot 知識(shí)以來(lái)，都覺(jué)得這樣的跳轉(zhuǎn)程序理所當(dāng)然，并且也沒(méi)出現(xiàn)過(guò)問(wèn)題，直到最近修改了優(yōu)化級(jí)別，發(fā)現(xiàn)程序直接hardfault 了，根本沒(méi)跳轉(zhuǎn)到 app 中，才發(fā)現(xiàn)了這里隱藏的 bug。

調(diào)試發(fā)現(xiàn)，app_start 這個(gè)函數(shù)指針變成了異常值，但魚(yú)鷹查看0x08040000 處的內(nèi)存空間值是正常的。那只能是代碼問(wèn)題了。

因此結(jié)合匯編和在線調(diào)試，終于發(fā)現(xiàn)，執(zhí)行__set_MSP 這條語(yǔ)句前app_start 的值是正常的，執(zhí)行后，這個(gè)值就異常了。

再結(jié)合 C 語(yǔ)言關(guān)于棧、局部變量的知識(shí)，立刻就知道是因?yàn)橹匦略O(shè)置棧頂?shù)刂罚珔R編代碼不變，但是從新棧位置偏移取函數(shù)地址，因此跳轉(zhuǎn)失敗。

如：

新棧的位置，變量的值是未知的，用它進(jìn)行跳轉(zhuǎn)，失敗是必然的。

但是為什么大部分情況下程序沒(méi)有問(wèn)題呢？

這是因?yàn)樘D(zhuǎn)程序很簡(jiǎn)單，局部變量少，那么這個(gè)app_start 局部變量編譯器可能就不會(huì)從棧中分配，而直接用一個(gè)寄存器存儲(chǔ)數(shù)據(jù)，而寄存器是不受棧頂位置影響的，自然程序能跳轉(zhuǎn)了。

但我們不能讓程序運(yùn)行正常與否由編譯器隨機(jī)決定，因此我們要避免這個(gè) bug，讓程序不管在何種優(yōu)化級(jí)別、函數(shù)多復(fù)雜的情況下，依然可以正常運(yùn)行，因此還是有必要進(jìn)行優(yōu)化的。

最簡(jiǎn)單的方法，就是把這個(gè)app_start 局部變量變成全局變量。這樣變量就不會(huì)受到棧頂位置影響，自然可以避免了。

如：

#define APP_START_ADDR          0x08040000 


voidjump2app()
{
typedefvoid(*func_app_start)(void);
   
__disable_irq();

static func_app_start app_start=(func_app_start)(*(__IOuint32_t*)(APP_START_ADDR+4));
  
__set_MSP(*(__IOuint32_t*)(APP_START_ADDR));//設(shè)置棧頂?shù)刂?/span>


app_start();
}

如有更好的優(yōu)化方法，歡迎留言討論。