1. 程式人生 > >STM32 BootLoader跳轉APP跑飛 可能是因為找不到某些中斷函式入口

STM32 BootLoader跳轉APP跑飛 可能是因為找不到某些中斷函式入口

在做嵌入式產品時,有時為方便更新裝置程式(如遠端更新或者只更新模組程式等原因),就要用到bootloader對裝置進行必要的初始化,引導下載APP等。

STM官網下載的bootloader程式中並沒有用到定時器等,很可能遇不到下面的問題。但是小猿猴如我等,會迫不及待的對其進行“魔改”,再經過二手三手,再加上運氣不好,下面的問題就很容易暴露出來了:

現象: 

bootloader 下載並跳轉某些 app 程式時,app執行正常;

對於某些app來說,卻根本跑不起來;  app本身執行沒有問題;  bootlaoder+app執行,J-Link線上模擬時,發現報硬體錯誤;

原因之一:  

bootloader 中開啟了某些中斷(並編寫了中斷函式),bootloader結束時未關閉該中斷;

但是app程式中沒有使用,也沒有定義相關中斷函式;

 這時系統就會因為找不到中斷函式入口而報硬體錯誤,即app跑飛了.

根源: 

       函式被呼叫時,系統根據其入口指標,將指令從ROM中載入到RAM中,函式執行完畢後就會釋放這一塊RAM。即全域性變數定義後是存放在RAM中的,但是"函式"是存放在ROM中的,其入口地址(ROM地址)在程式設計的時候就確定了。

程式下載時,bootloader和app的二進位制程式碼存放在ROM中不同的區域,彼此互不干擾,不會存在函式重定義的問題。作為app來說,會對系統的向量表進行重定位(可搜尋查詢“向量表重定位”的含義,這裡就不說遠了

),並且是不直接呼叫bootloader中的某個函式的;但是這時系統已經被初始化了。

典型的如bootlaoder開啟了定時器中斷(Timer),但是app中沒有用到定時器(Timer)更沒有定義其中斷函式,而已經被初始化了的系統在定時器中斷時,會根據已經被重定位了的向量表去查詢Timer中斷函式,找不到的結果就是報硬體錯誤了。

當然,bootloader不穩定的原因有很多,如乙太網、USB等app更新方式不同,可能的原因也會不盡相同。如果上述方法不能解決您的問題,那麼哪天您解決了此問題時,還請分享出來,大家一起進步^^