赞
踩
目录
我们初学STM32的时候代码难免会出现疏忽,导致程序跑飞,不再正常运行,那么都是什么情况会导致STM32程序跑飞呢?
软件导致STM32跑飞(程序失控或死机)的原因有多种,主要包括以下几个方面:
中断处理不当:
volatile
关键字声明,或在读取前关闭全局中断),可能会导致数据不一致或程序异常。堆栈溢出:
不合理的内存操作:
死循环:
while(1)
循环中缺少跳出条件)也可能导致程序无法继续执行后续操作。看门狗未喂或未关闭:
我们要发现程序在哪跑飞了,肯定是要借助调试工具了,以下几个工具是我们需要用到的。
(1)通用寄存器(R0~R12)
(2)特殊功能寄存器
(3)程序状态寄存器(xPSR)
xPSR是程序状态寄存器,它又被分为三个子状态寄存器:
(4)控制寄存器(Control)
控制寄存器用于控制FPU(浮点单元)的激活、堆栈指针的选择以及线程模式的特权级等。
Memory Window是Keil调试环境中的一个窗口,它提供了对程序内存的直接访问。通过这个窗口,你可以查看内存中的字节、字、双字等数据,并可以实时修改这些数据以测试程序的行为。这对于调试和验证程序中的内存访问、堆栈使用、变量存储等问题非常有帮助。
在Disassembly窗口中,你可以看到程序的反汇编代码。这些代码是程序在CPU上实际执行的指令的文本表示。你可以滚动窗口来查看不同的部分,或者使用窗口中的搜索功能来定位特定的代码或地址。
Call Stack(调用堆栈)界面是一个关键的调试工具,它允许开发者查看程序执行过程中函数调用的顺序和当前的位置。Call Stack窗口将显示当前函数调用的堆栈。这包括每个函数的调用顺序、每个函数的名称(如果可用)以及调用该函数的地址。你可以看到程序是如何从main
函数开始,逐步调用其他函数,直到达到当前执行点的。
介绍完了程序跑飞的原因以及调试工具以后,接下来我为大家说一下如何找到程序跑飞的位置,有两种方式。
(1)在HardFault_Handler这个函数里面打上断点,程序跑飞都会进入这个中断。
(2)在Registers工具中找到R13的值。
(3)在Memory工具中搜索刚才R13的值,然后找到0800开头的值。
(4)在Disassembly工具中右键选择Show Disassembly at Address,然后将0x08001548复制进去,点GO TO,就找到程序在哪跑飞了。
(1)和上面第一步一样,在HardFault_Handler这个函数里面打上断点。
(2)程序进入断点以后,先点继续运行,然后停止运行程序
,打开Call Stack工具,找到HardFault_Handler,然后右键选择 show Caller Code就可以找到跑飞之前运行的代码了。
注意:
(1)方式一和方式二都需要先在HardFault_Handler打断点才能进行
(2)方式二不停止程序不会出现show Caller Code
(3)如果是堆栈溢出方式一二均无效,因为这两个方式都是通过堆栈进行寻址的。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。