關(guān)于stm32 HardFault_Handler 異常的處理 死機(jī)

一般來說運行操作系統(tǒng) 是以下幾個問題

1.開始的時候給ucos分配的堆棧太小了，隨著項目做多了，這類問題一般很容易解決

比如修改300到 1000，做開發(fā)的時候 如果ram允許，盡量大些，免的麻煩

2.數(shù)組溢出

這類問題一般在通信中，接受數(shù)據(jù)的時候，特別是長度不定的時候

比如協(xié)議為 ：開始 功能碼 長度 數(shù)據(jù)1 數(shù)據(jù)2 。。結(jié)束

長度決定了后面的數(shù)據(jù)多少，在分配接受緩沖的時候 ，突然來了個錯誤的長度比如255

但是我們分配buffer[100],只定義了100，這樣數(shù)組就溢出了

所有在放數(shù)據(jù)之前要對長度進(jìn)行判斷是否合理，以后 如果有長度 或者索引就要想到溢出。。

3.使用了非法的指針 ，比如空指針 ，編譯對的但是運行就錯了

u8 *p = null;

*p = 1; 把0地址的數(shù)據(jù)強(qiáng)制設(shè)置為1， 不錯才怪

4.使用 OS_ENTER_CRITICAL();

使用了 OS_ENTER_CRITICAL(); 卻忘了OS_EXIT_CRITICAL(); 退出臨界區(qū)

特別是在這個函數(shù)OS_ENTER_CRITICAL(); 調(diào)用了子函數(shù)也有的這類情況，很容易忘記關(guān)閉的這樣就造成了“死機(jī)現(xiàn)象”

因此如果調(diào)用的話 建議在函數(shù)中加入OS_CPU_SR cpu_sr = 0u;局部變量 在管理臨界區(qū) os的內(nèi)核程序也是這么用的 ，而且要注意，臨界區(qū)一般用于全局變量的寫操作，時間要非?？斓?，任務(wù)中的變量可以不用添加。

常見的就上面幾種了，說說硬件異常了 怎么來發(fā)現(xiàn)，這個才是主要的

舉個例子：

a.仿真，運行程序的時候點紅色X進(jìn)入異常

b.調(diào)出堆棧窗口，也就是黑匣子

c.查找問題

d.找出出錯的函數(shù)

e.解決問題

f 一些思考

很久之前在研究stm32 庫源碼的時候 發(fā)現(xiàn)基本上 每個函數(shù)進(jìn)入之前都做了參數(shù)的檢測，當(dāng)初還覺得檢查不檢查貌似沒什么大的作用，自己使用的時候注意就好了，現(xiàn)在是不是改變看法了嗎？編程的時候很多問題，在參數(shù)檢查的時候被過濾掉了，這樣在開發(fā)大型項目的時候，可以給您免去很多不必要的麻煩，反而會提供開發(fā)效率哦

當(dāng)然網(wǎng)上也有很多，檢查寄存器LR SP等地址 來反推出最后運行的匯編函數(shù)調(diào)用地址的，但是肯定沒有上面的直觀。