經典案例解析 | STM32芯片異常復位

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

查看復位狀態寄存器了解復位大方向，然后做進一步得拆解分析。

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

因為客戶的異常處理函數中并沒有做任何動作，導致獨立看門狗IWDG復位?；诖?，我們先關閉IWDG，然后在所有的異常處理中，先加入死循環并打上斷點，對異常原因進行捕捉。

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

通過查看SP以及回溯棧里面的內容，找到了對應的LR，具體方法如下：

當中斷產生時，按照上圖所示的順序進行壓棧，同時棧指針SP--，即： R0, R1, R2, R3, R12, LR, PC, xPSR。

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

根據出錯時的PC和LR，發現是浮點運算的函數，初步判斷是因為浮點運算導致，比如沒有對齊導致的Hardfault，但實際檢查發現，并不是浮點運算的問題。 

問題一時陷入了僵局。但有一點是確定的，是因為棧的區域被異常覆蓋或者改寫導致產生hardfault。

由于問題可以穩定復現，采取逐個排除法最終發現了問題的所在：

當把一個局部數組變量改為全局數組時，問題消失！

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

追查這個局部變量數組：

經檢查發現，這個原先是8bit的局部變量的數組，在最后被強制轉換成了uint32_t*類型的指針，由于是指針，在對其進行++或--操作時，都是按照4字節寬帶操作的，這就相當于擴大了4倍，覆蓋了后面的棧的內容，導致了程序跑飛。