STM32卡死、跑飞如何调试确定问题

前言

一、程序跑飞原因

二、调试工具

2.1Registers工具

[2.2 Memory工具](#2.2 Memory工具)

[2.3 Disassembly工具](#2.3 Disassembly工具)

[2.4 Call Stack工具](#2.4 Call Stack工具)

三、找到程序跑飞位置

方式一、

方式二、

前言

我们初学STM32的时候代码难免会出现疏忽，导致程序跑飞，不再正常运行，那么都是什么情况会导致STM32程序跑飞呢？

一、程序跑飞原因

软件导致STM32跑飞（程序失控或死机）的原因有多种，主要包括以下几个方面：

中断处理不当：
- 未响应或清除中断标志：如果打开了某个中断但没有及时响应和清除中断标志，程序可能会持续进入中断，造成死机假象。
- 中断变量处理不妥 ：如果定义了某些会在中断中修改的全局变量，但没有正确管理这些变量（如使用volatile关键字声明，或在读取前关闭全局中断），可能会导致数据不一致或程序异常。
堆栈溢出：
- 当项目代码量较大时，如果默认的堆栈设置过小，或者程序中存在大量的函数调用和局部变量，可能导致堆栈溢出，使程序跑飞。
不合理的内存操作：
- 内部Flash存储操作不当：不合理的Flash内存操作也可能导致程序死机。
- 数组越界：如果在使用数组时没有控制好下标，导致数组越界，可能会意外修改系统的寄存器或数据，造成程序失控。
死循环：
- 程序中存在的无条件的死循环（如while(1)循环中缺少跳出条件）也可能导致程序无法继续执行后续操作。
看门狗未喂或未关闭：
- 如果使用了看门狗功能但没有在适当的时候喂狗，或者看门狗被意外开启但没有关闭，都可能导致程序被频繁复位。

二、调试工具

我们要发现程序在哪跑飞了，肯定是要借助调试工具了，以下几个工具是我们需要用到的。

2.1Registers工具

(1)通用寄存器（R0~R12）

R0~R7：这些是低组寄存器，所有指令都可以访问。它们的大小为32位，复位后的初始值不定。
R8~R12：这些是高组寄存器，只有部分的16位Thumb指令可以访问，而32位Thumb-2指令则不受限制。它们的大小同样为32位，复位后的初始值也不定。

(2)特殊功能寄存器

堆栈指针（SP）：也称为R13，在Cortex-M4内核中，有两个堆栈指针------主堆栈指针（MSP）和进程堆栈指针（PSP）。MSP用于异常服务例程和需要特权访问的应用程序代码，而PSP则用于常规的应用代码。
连接寄存器（LR）：即R14，主要作用是保存子程序的返回地址，以便在执行完子程序时恢复现场。
程序计数器（PC）：即R15，用于指示当前执行的指令地址。在Cortex-M系列中，由于采用指令流水线技术，读取PC会返回当前指令地址+4（以兼容Thumb代码）。

(3)程序状态寄存器（xPSR）

xPSR是程序状态寄存器，它又被分为三个子状态寄存器：

应用程序状态寄存器（APSR）
中断状态寄存器（IPSR）
PRIMASK：只有1个位，置1时关闭所有可屏蔽的异常。
FAULTMASK：只有1个位，置1时只有NMI（非屏蔽中断）可以响应。
BASEPRI：8位寄存器，定义了被屏蔽优先级的阈值。

(4)控制寄存器（Control）

控制寄存器用于控制FPU（浮点单元）的激活、堆栈指针的选择以及线程模式的特权级等。

2.2 Memory工具

Memory Window是Keil调试环境中的一个窗口，它提供了对程序内存的直接访问。通过这个窗口，你可以查看内存中的字节、字、双字等数据，并可以实时修改这些数据以测试程序的行为。这对于调试和验证程序中的内存访问、堆栈使用、变量存储等问题非常有帮助。

2.3 Disassembly工具

在Disassembly窗口中，你可以看到程序的反汇编代码。这些代码是程序在CPU上实际执行的指令的文本表示。你可以滚动窗口来查看不同的部分，或者使用窗口中的搜索功能来定位特定的代码或地址。

2.4 Call Stack工具

Call Stack（调用堆栈）界面是一个关键的调试工具，它允许开发者查看程序执行过程中函数调用的顺序和当前的位置。Call Stack窗口将显示当前函数调用的堆栈。这包括每个函数的调用顺序、每个函数的名称（如果可用）以及调用该函数的地址。你可以看到程序是如何从main函数开始，逐步调用其他函数，直到达到当前执行点的。