關于stm32 HardFault_Handler 異常的處理 死機
一般來說運行操作系統(tǒng) 是以下幾個問題
1.開始的時候給ucos分配的堆棧太小了,隨著項目做多了,這類問題一般很容易解決
#define TASK_IO_SIZE 300
#define TASK_IO_PRIO 6
OS_STK TASK_IO_STK[TASK_IO_SIZE];
比如修改300到 1000,做開發(fā)的時候 如果ram允許,盡量大些,免的麻煩
2.數(shù)組溢出
這類問題一般在通信中,接受數(shù)據(jù)的時候,特別是長度不定的時候
比如協(xié)議為 :開始 功能碼 長度 數(shù)據(jù)1 數(shù)據(jù)2 。。結束
長度決定了后面的數(shù)據(jù)多少,在分配接受緩沖的時候 ,突然來了個錯誤的長度比如255
但是我們分配buffer[100],只定義了100,這樣數(shù)組就溢出了
所有在放數(shù)據(jù)之前要對長度進行判斷是否合理,以后 如果有長度 或者索引就要想到溢出。。
3.使用了非法的指針 ,比如空指針 ,編譯對的但是運行就錯了
u8 *p = null;
*p = 1; 把0地址的數(shù)據(jù)強制設置為1, 不錯才怪
4.使用 OS_ENTER_CRITICAL();
使用了 OS_ENTER_CRITICAL(); 卻忘了OS_EXIT_CRITICAL(); 退出臨界區(qū)
特別是在這個函數(shù)OS_ENTER_CRITICAL(); 調用了子函數(shù)也有的這類情況,很容易忘記關閉的這樣就造成了“死機現(xiàn)象”
因此如果調用的話 建議在函數(shù)中加入OS_CPU_SR cpu_sr = 0u;局部變量 在管理臨界區(qū) os的內核程序也是這么用的 ,而且要注意,臨界區(qū)一般用于全局變量的寫操作,時間要非??斓模蝿罩械淖兞靠梢圆挥锰砑?。
常見的就上面幾種了,說說硬件異常了 怎么來發(fā)現(xiàn),這個才是主要的
舉個例子:
a.仿真,運行程序的時候點紅色X進入異常
b.調出堆棧窗口,也就是黑匣子
c.查找問題
d.找出出錯的函數(shù)
e.解決問題
f 一些思考
很久之前在研究stm32 庫源碼的時候 發(fā)現(xiàn)基本上 每個函數(shù)進入之前都做了參數(shù)的檢測,當初還覺得檢查不檢查貌似沒什么大的作用,自己使用的時候注意就好了,現(xiàn)在是不是改變看法了嗎?編程的時候很多問題,在參數(shù)檢查的時候被過濾掉了,這樣在開發(fā)大型項目的時候,可以給您免去很多不必要的麻煩,反而會提供開發(fā)效率哦
當然網上也有很多,檢查寄存器LR SP等地址 來反推出最后運行的匯編函數(shù)調用地址的,但是肯定沒有上面的直觀。
評論