前言

本篇主要是介紹一種處理問題的思路，即當我們在做STM32應用開發過程中，遇到芯片異常復位，或者進入了異常處理時，如何通過集成開發環境，如IAR，KEIL等查看相應的ARM內核寄存器，定位出應用軟件產生異常的地方！

問題描述

某STM32用戶反饋，當使用STM32L4芯片的時候，程序運行一段時間后，會忽然復位。復位后程序繼續運行，但是還會繼續復位，原因不詳！

問題分析

針對于此類問題，我們可以按照一個統一的思路去處理。分析本案例的大致步驟如下：

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

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

3、目前客戶項目的復位原因是因為看門狗復位，即客戶使用了IWDG，但由于某種原因沒有及時喂狗，導致IWDG超時復位。初步懷疑由于客戶軟件的問題，程序跑飛，進入異常處理。因為客戶的異常處理函數中并沒有做任何動作，導致獨立看門狗IWDG復位。基于此，我們先關閉IWDG，然后在所有的異常處理中，先加入死循環并打上斷點，對異常原因進行捕捉。

4、正如我們所猜測，的確是由于程序跑飛導致。程序停在了void HardFault_Handler(void) 。通過查看 SP 以及回溯棧里面的內容，找到了對應的LR，具體方法如下：

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

如上圖所示，當產生異常時，如果call stack窗口顯示不出來的話，只能根據core的寄存器手動回溯棧，以找到出錯時的指針。根據ARM core的說明，SP+6，即紅框的部分，為中斷處理后LR和PC，據此可以追溯函數異常時的位置！
5、根據出錯時的PC和LR，發現是浮點運算的函數，初步判斷是因為浮點運算導致，比如沒有對齊導致的Hardfault，但實際檢查發現，并不是浮點運算的問題！
6、問題一時陷入了僵局。但有一點是確定的，是因為棧的區域被異常覆蓋或者改寫導致產生hard fault，
7、由于問題可以穩定復現，采取逐個排除法最終發現了問題的所在：當把一個局部數組變量改為全局數組時，問題消失！由于局部數組變量是保存在棧當中，所以懷疑是對這個局部數組變量使用不當導致了棧被覆蓋或者改寫！追查這個局部變量數組：

經檢查發現，這個原先是8bit的局部變量的數組，在最后被強制轉換成了uint32_t *類型的指針，由于是指針， 在對其進行++或--操作時，都是按照4字節寬帶操作的，這就相當于擴大了4倍，覆蓋了后面的棧的內容， 導致了程序跑飛！
小結
當芯片異常復位或者進入異常處理(如Hard fault, Mem Manage, Bus fault等)時，首先考慮的是，如何快速的復現這個問題，當問題被穩定復現的時候，可以通過調試工具在異常處理的地方打上斷點停留，這樣就可以獲取到棧指針SP，通過SP去看棧里面的內容去回溯棧。當然，如果棧的內容被無端改寫時，棧里面的內容，如保存的LR就沒有太大的參考意義。不過，可以通過觀察棧里面的內容，去估測是哪個模塊或者函數異常修改了棧的內容，進而定位最終的問題源！

總結

以上是生活随笔為你收集整理的复位 stm32_分析一个关于STM32 芯片异常复位的经典案例！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。