昨天有一位讀者剛關(guān)注魚鷹，并且很快加了魚鷹微信，描述了以下問題：

當(dāng)時(shí)也沒有細(xì)看問題，只是大概看了一下，然后簡單的提供了一個(gè)思路給對方，畢竟魚鷹也比較忙，不可能花太多時(shí)間在別人的問題上。

而且也是看對方的問題描述比較清楚，比較有誠意，所以才會提供一個(gè)思路，否則可能懶得回復(fù)了。所以大家問問題的時(shí)候一定要直接詳細(xì)描述，否則沒人不愿意回答。畢竟很多人問完并回復(fù)之后，可能一句謝謝都沒有就沒有下文了，這種事情見多了。好像別人幫助你是理所應(yīng)當(dāng)?shù)摹?/p>

只是沒想到，對方會提出給報(bào)酬，所以看他挺有誠意的，就開玩笑的問問多少錢。然后開始報(bào)價(jià)，并且對方也同意我的報(bào)價(jià)，并愿意多給一倍。

既然他那么有誠意，晚上也沒啥事情，所以還是按自己的報(bào)價(jià)（有原則的魚鷹）確定下來 20 點(diǎn)左右開始遠(yuǎn)程解決問題。

8 點(diǎn)半左右開始正式遠(yuǎn)程解決，原本以為半小時(shí)能搞定，實(shí)際上花了一個(gè)半小時(shí)。這里稍微總結(jié)一下。

首先是讓對方復(fù)現(xiàn)問題，然后和正常的情況一并復(fù)現(xiàn)，這里花了幾分鐘，確定了好的代碼與不好的代碼不同現(xiàn)象。

這里可能有點(diǎn)奇怪，為啥有好的代碼（boot 能正常跳轉(zhuǎn)到 APP），還要找魚鷹解決，魚鷹開始也有點(diǎn)納悶，后來才知道，原來好的代碼只要稍微改點(diǎn)代碼，就不能正常跳轉(zhuǎn)了，這肯定是不行的，因此找上了魚鷹（其實(shí)描述也說了，只是魚鷹沒太在意）。

根據(jù)目前了解的情況來看，怎么說也是 APP 的問題，畢竟 Boot 有成功跳轉(zhuǎn)的情況。

開始的時(shí)候，魚鷹的方向確實(shí)在 APP 上，還仔細(xì)的看了看 APP 的編譯警告問題（很多人不注意警告，總是在工程里面遺留很多警告，雖然很多情況下，這些警告不會有問題，但是萬一呢。所以建議大家盡量解決工程的警告， 0 error 0 warning還是相當(dāng)舒服的），這里也花了幾分鐘確認(rèn)，發(fā)現(xiàn)確實(shí)無關(guān)大雅。

之后又是嘗試了幾次好代碼與壞代碼的差別，發(fā)現(xiàn)在跳轉(zhuǎn)代碼部分，沒有任何區(qū)別，跳轉(zhuǎn)地址： 0x00010000 棧頂?shù)刂罚?nbsp;0xE000ED08（通過匯編代碼分析）。

但這個(gè)反常的現(xiàn)象卻引起了魚鷹的警惕， 因?yàn)閾?jù)魚鷹了解到的 Cortex-M3  內(nèi)核知識《STM32固件升級之基礎(chǔ)知識（一）》，兩個(gè)不同的 APP 這兩個(gè)地址大概率是不同的。

雖然它是 M33 的內(nèi)核，但也不應(yīng)該差別那么大。

而且內(nèi)存地址也不應(yīng)該是 0xE000 開頭的，所以又是查 map 文件，又是看鏈接文件，又是上網(wǎng)（魚鷹對 M33 的跳轉(zhuǎn)不熟悉，所以需要了解情況，否則解決時(shí)間可以縮短不少），又是和提問者溝通，最終得到以下信息：

1、兩個(gè)代碼確實(shí)不同（這個(gè)可以確定編譯沒有問題），通過 map 可以分析出來，但為什么一份可以，一份不可以？boot的跳轉(zhuǎn)地址和棧頂?shù)刂愤€一樣？不符合常理！

2、調(diào)試過程中發(fā)現(xiàn)跳轉(zhuǎn)時(shí)不會運(yùn)行到啟動文件（*.s），這有悖常理！

3、內(nèi)存地址實(shí)際從 0x20000000 開始；

4、APP 鏈接文件修改的地方由 NXP 的 FAE 告知，跳轉(zhuǎn)到 APP 部分的代碼也是 FAE 提供的（一開始就了解了這個(gè)情況，所以沒有一開始就懷疑這部分代碼）。

5、通過查看 flash 0x0001 0000 地址處的內(nèi)容，發(fā)現(xiàn)兩份代碼有不同，確定下載沒有問題。

結(jié)合上面的兩個(gè)地址（跳轉(zhuǎn)地址和棧頂?shù)刂罚ㄏ燃僭O(shè)是這樣，因?yàn)?M3 內(nèi)核就是這樣，M33 內(nèi)核估計(jì)差不了多少）），魚鷹開始重點(diǎn)查看這個(gè)跳轉(zhuǎn)代碼（NXP FAE 提供）

#define ApplicationAddress    0x10000
void JumpToUserApplication(unsigned long userSP, unsigned long userStartup){ // set up stack pointer  __asm("msr msp, r0");  __asm("msr psp, r0");
  // Jump to PC (r1)  __asm("mov pc, r1"); }
void StartUp(void){ // relocate vector table SCB->VTOR = ApplicationAddress;   // Jump to user application JumpToUserApplication(*((unsigned long*)ApplicationAddress), *((unsigned long*)(ApplicationAddress+4)));    }

乍看，和魚鷹理解的 M3 類似，都是在跳轉(zhuǎn)時(shí)取出 APP 首地址處的 8 個(gè)字節(jié)作為 棧頂指針 和 PC 指針。

但是從 C 語言的角度，你看不出任何毛病，很正常，但是它最終到 JumpToUserApplication 時(shí)卻是 0x0001 0000 和 0xE000ED08，這個(gè)和前面的分析完全不符。

沒辦法，只能拿出魚鷹的殺手锏，分析匯編。

之后就發(fā)現(xiàn)，這個(gè)嵌入式匯編在跳轉(zhuǎn)時(shí)，并沒有取出 0x0001 0000 地址的 8個(gè)數(shù)據(jù)，而是直接沿用前面的 SCB->VTOR = ApplicationAddress;  運(yùn)行后的 R0、 R1作為參數(shù)傳遞進(jìn)去，最終導(dǎo)致跳轉(zhuǎn)失敗。

也就是說，問題出在 BOOT 上，而不是 APP 里面，所謂的好代碼只是湊巧趕上了，這也就能解釋為什么跳轉(zhuǎn)時(shí)不會運(yùn)行到啟動文件了。

找到問題，但因?yàn)閷R編不熟，又是一頓改寫，測試，總算成功跳轉(zhuǎn)了。也算是完成了任務(wù)。

從這次解決 BUG 的經(jīng)歷中，各位道友可以發(fā)現(xiàn)，這里運(yùn)用了非常多的基礎(chǔ)知識（內(nèi)存分配、向量表、map文件、鏈接文件、匯編等等），正因?yàn)橛羞@些知識的積累，此案才能順利告破。

解 BUG，就像一個(gè)破案的警察，不僅需要從蛛絲馬跡中尋找線索，還需要很多理論基礎(chǔ)支撐，足夠敏感，才能順利解決，否則只能干瞪眼了。

但個(gè)人又覺得，自己的行為像一個(gè)殺手，你出錢，我辦事，各取所需。

這次是魚鷹第一次有償且親自遠(yuǎn)程解決疑難問題，覺得挺有意義的，故此記錄。

另外如果其他道友有難解的 BUG，同時(shí)又愿意付費(fèi)解決的話，歡迎咨詢魚鷹，魚鷹視情況收費(fèi)（可能不低，但可以節(jié)省時(shí)間，項(xiàng)目緊急的話歡迎找魚鷹），當(dāng)然也可以雇傭魚鷹作為 MCU 技術(shù)顧問，幫助公司解決一些難解問題。

在此感謝大家對魚鷹的關(guān)注與支持！