|
某STM32用户反馈，当使用STM32L4芯片的时候，程序运行一段时间后，会忽然复位。复位后程序继续运行，但是还会继续复位，原因不详。
初步确定复位的原因，是硬件复位，如外部NRST被拉低，还是软件复位，包括软件直接调用复位，或者看门狗复位，还是低功耗模式如standby模式被唤醒时产生中断。
目前客户项目的复位原因是因为看门狗复位，即客户使用了IWDG，但由于某种原因没有及时喂狗，导致IWDG超时复位。初步怀疑由于客户软件的问题，程序跑飞，进入异常处理。
通过查看SP以及回溯栈里面的内容，找到了对应的LR，具体方法如下： 当中断产生时，按照上图所示的顺序进行压栈，同时栈指针SP--，即： R0, R1, R2, R3, R12, LR, PC, xPSR。 如上图所示，当产生异常时，如果call stack窗口显示不出来的话，只能根据core的寄存器手动回溯栈，以找到出错时的指针。根据ARM core的说明，SP+6，即红框的部分，为中断处理后LR和PC，据此可以追溯函数异常时的位置。 问题一时陷入了僵局。但有一点是确定的，是因为栈的区域被异常覆盖或者改写导致产生hardfault。 当把一个局部数组变量改为全局数组时，问题消失！ 追查这个局部变量数组： 经检查发现，这个原先是8bit的局部变量的数组，在最后被强制转换成了uint32_t*类型的指针，由于是指针，在对其进行++或--操作时，都是按照4字节宽带操作的，这就相当于扩大了4倍，覆盖了后面的栈的内容，导致了程序跑飞。
当芯片异常复位或者进入异常处理 (如Hard fault, Mem Manage, Bus fault等)时，首先考虑的是，如何快速的复现这个问题，当问题被稳定复现的时候，可以通过调试工具在异常处理的地方打上断点停留，这样就可以获取到栈指针SP，通过SP去看栈里面的内容去回溯栈。当然，如果栈的内容被无端改写时，栈里面的内容，如保存的LR就没有太大的参考意义。不过，可以通过观察栈里面的内容，去估测是哪个模块或者函数异常修改了栈的内容，进而定位最终的问题源。
| 
楼主
标题置顶
标题高亮
