前言
3 w% f+ V! l0 w1 C5 V本篇主要是介绍一种处理问题的思路，即当我们在做STM32应用开发过程中，遇到芯片异常复位，或者进入了异常处理时，如何通过集成开发环境，如IAR，KEIL等查看相应的ARM内核寄存器，定位出应用软件产生异常的地方！
! j9 I- w- g; I- z1 U+ w8 V' y
, B% K& T3 F3 v3 K# a
3 o. [& L3 g+ I' J/ O# J问题描述
6 Z- T$ [) v  v, g& k4 H4 J某STM32用户反馈，当使用STM32L4芯片的时候，程序运行一段时间后，会忽然复位。复位后程序继续运行，但是还会继续复位，原因不详！
% h; D9 g# ^1 w% U( a

问题分析
针对于此类问题，我们可以按照一个统一的思路去处理。分析本案例的大致步骤如下：
1、初步确定复位的原因，是硬件复位，如外部NRST被拉低，还是软件复位，包括软件直接调用复位，或者看门狗复位，还是低功耗模式如standby模式被唤醒时产生中断；
0 e0 F+ X6 G" Y; O2 Z9 Z2、查看复位状态寄存器了解复位大方向，然后做进一步得拆解分析。
* w( P8 w8 X, ^- j8 m# ~1 o3、目前客户项目的复位原因是因为看门狗复位，即客户使用了IWDG，但由于某种原因没有及时喂狗，导致IWDG超时复位。初步怀疑由于客户软件的问题，程序跑飞，进入异常处理。
' H8 `2 A# L; u4 q4 h因为客户的异常处理函数中并没有做任何动作，导致独立看门狗IWDG复位。基于此，我们先关闭IWDG，然后在所有的异常处理中，先加入死循环并打上断点，对异常原因进行捕捉。


$ q1 X7 n/ E8 h

/ {1 g3 s8 ^3 U+ K/ `
" F. V. }. E: n! A; o0 {% S& N9 ?4、正如我们所猜测，的确是由于程序跑飞导致。程序停在了void HardFault_Handler(void) 。
$ L& T( c9 u* A" r* D0 @; b通过查看 SP 以及回溯栈里面的内容，找到了对应的LR，具体方法如下：

4 ^' q7 }0 Z4 C; E/ ~


4 W: @) g5 Y$ ^% m( z1 Z当中断产生时，按照上图所示的顺序进行压栈，同时栈指针SP--，即： R0, R1, R2, R3, R12, LR, PC,xPSR。
6 }# ]1 V, H: k1 `* K5 W
& Y# k( [/ D$ r- f7 C/ I" Z/ L


& |- F/ N+ O( `8 l- z1 m如上图所示，当产生异常时，如果call stack窗口显示不出来的话，只能根据core的寄存器手动回溯栈，以找到出错时的指针。根据ARM core的说明，SP+6，即红框的部分，为中断处理后LR和PC，据此可以追溯函数异常时的位置！

# E% s8 j/ n) [' p7 _完整版请查看：附件

  }% n5 ?* u7 }