問題描述

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

問題解析

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

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

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

因為客戶的異常處理函數(shù)中并沒有做任何動作，導(dǎo)致獨(dú)立看門狗IWDG復(fù)位?；诖?，我們先關(guān)閉IWDG，然后在所有的異常處理中，先加入死循環(huán)并打上斷點(diǎn)，對異常原因進(jìn)行捕捉。

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

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

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

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

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

問題一時陷入了僵局。但有一點(diǎn)是確定的，是因為棧的區(qū)域被異常覆蓋或者改寫導(dǎo)致產(chǎn)生hardfault。

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

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

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

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

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

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