STM32芯片異常復(fù)位的原因有哪些

問題描述

某STM32用戶反饋，當(dāng)使用STM32L4芯片的時(shí)候，程序運(yùn)行一段時(shí)間后，會(huì)忽然復(fù)位。復(fù)位后程序繼續(xù)運(yùn)行，但是還會(huì)繼續(xù)復(fù)位，原因不詳。

問題解析

初步確定復(fù)位的原因，是硬件復(fù)位，如外部NRST被拉低，還是軟件復(fù)位，包括軟件直接調(diào)用復(fù)位，或者看門狗復(fù)位，還是低功耗模式如standby模式被喚醒時(shí)產(chǎn)生中斷。

查看復(fù)位狀態(tài)寄存器了解復(fù)位大方向，然后做進(jìn)一步得拆解分析。

目前客戶項(xiàng)目的復(fù)位原因是因?yàn)榭撮T狗復(fù)位，即客戶使用了IWDG，但由于某種原因沒有及時(shí)喂狗，導(dǎo)致IWDG超時(shí)復(fù)位。初步懷疑由于客戶軟件的問題，程序跑飛，進(jìn)入異常處理。

因?yàn)榭蛻舻漠惓Ｌ幚砗瘮?shù)中并沒有做任何動(dòng)作，導(dǎo)致獨(dú)立看門狗IWDG復(fù)位?；诖耍覀兿汝P(guān)閉IWDG，然后在所有的異常處理中，先加入死循環(huán)并打上斷點(diǎn)，對(duì)異常原因進(jìn)行捕捉。

正如我們所猜測(cè)，的確是由于程序跑飛導(dǎo)致。程序停在了voidHardFault_Handler(void) 。

通過查看SP以及回溯棧里面的內(nèi)容，找到了對(duì)應(yīng)的LR，具體方法如下：

當(dāng)中斷產(chǎn)生時(shí)，按照上圖所示的順序進(jìn)行壓棧，同時(shí)棧指針SP--，即： R0, R1, R2, R3, R12, LR, PC, xPSR。

如上圖所示，當(dāng)產(chǎn)生異常時(shí)，如果call stack窗口顯示不出來的話，只能根據(jù)core的寄存器手動(dòng)回溯棧，以找到出錯(cuò)時(shí)的指針。根據(jù)ARM core的說明，SP+6，即紅框的部分，為中斷處理后LR和PC，據(jù)此可以追溯函數(shù)異常時(shí)的位置。

根據(jù)出錯(cuò)時(shí)的PC和LR，發(fā)現(xiàn)是浮點(diǎn)運(yùn)算的函數(shù)，初步判斷是因?yàn)楦↑c(diǎn)運(yùn)算導(dǎo)致，比如沒有對(duì)齊導(dǎo)致的Hardfault，但實(shí)際檢查發(fā)現(xiàn)，并不是浮點(diǎn)運(yùn)算的問題。

問題一時(shí)陷入了僵局。但有一點(diǎn)是確定的，是因?yàn)闂５膮^(qū)域被異常覆蓋或者改寫導(dǎo)致產(chǎn)生hardfault。

由于問題可以穩(wěn)定復(fù)現(xiàn)，采取逐個(gè)排除法最終發(fā)現(xiàn)了問題的所在：

當(dāng)把一個(gè)局部數(shù)組變量改為全局?jǐn)?shù)組時(shí)，問題消失！

由于局部數(shù)組變量是保存在棧當(dāng)中，所以懷疑是對(duì)這個(gè)局部數(shù)組變量使用不當(dāng)導(dǎo)致了棧被覆蓋或者改寫。

追查這個(gè)局部變量數(shù)組：

經(jīng)檢查發(fā)現(xiàn)，這個(gè)原先是8bit的局部變量的數(shù)組，在最后被強(qiáng)制轉(zhuǎn)換成了uint32_t*類型的指針，由于是指針，在對(duì)其進(jìn)行++或--操作時(shí)，都是按照4字節(jié)寬帶操作的，這就相當(dāng)于擴(kuò)大了4倍，覆蓋了后面的棧的內(nèi)容，導(dǎo)致了程序跑飛。

當(dāng)芯片異常復(fù)位或者進(jìn)入異常處理 (如Hard fault, Mem Manage, Bus fault等)時(shí)，首先考慮的是，如何快速的復(fù)現(xiàn)這個(gè)問題，當(dāng)問題被穩(wěn)定復(fù)現(xiàn)的時(shí)候，可以通過調(diào)試工具在異常處理的地方打上斷點(diǎn)停留，這樣就可以獲取到棧指針SP，通過SP去看棧里面的內(nèi)容去回溯棧。當(dāng)然，如果棧的內(nèi)容被無端改寫時(shí)，棧里面的內(nèi)容，如保存的LR就沒有太大的參考意義。不過，可以通過觀察棧里面的內(nèi)容，去估測(cè)是哪個(gè)模塊或者函數(shù)異常修改了棧的內(nèi)容，進(jìn)而定位最終的問題源。