欢迎来到尧图网

客户服务 关于我们

您的位置:首页 > 文旅 > 游戏 > STM32卡死、跑飞如何调试确定问题

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

2024/11/30 4:24:24 来源:https://blog.csdn.net/qq_38072731/article/details/140865883  浏览:    关键词:STM32卡死、跑飞如何调试确定问题

目录

前言

一、程序跑飞原因

二、调试工具

2.1Registers工具

2.2 Memory工具

2.3 Disassembly工具

2.4 Call Stack工具

三、找到程序跑飞位置

方式一、

方式二、


前言

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

一、程序跑飞原因

软件导致STM32跑飞(程序失控或死机)的原因有多种,主要包括以下几个方面:

  1. 中断处理不当

    • 未响应或清除中断标志:如果打开了某个中断但没有及时响应和清除中断标志,程序可能会持续进入中断,造成死机假象。
    • 中断变量处理不妥:如果定义了某些会在中断中修改的全局变量,但没有正确管理这些变量(如使用volatile关键字声明,或在读取前关闭全局中断),可能会导致数据不一致或程序异常。
  2. 堆栈溢出

    • 当项目代码量较大时,如果默认的堆栈设置过小,或者程序中存在大量的函数调用和局部变量,可能导致堆栈溢出,使程序跑飞。
  3. 不合理的内存操作

    • 内部Flash存储操作不当:不合理的Flash内存操作也可能导致程序死机。
    • 数组越界:如果在使用数组时没有控制好下标,导致数组越界,可能会意外修改系统的寄存器或数据,造成程序失控。
  4. 死循环

    • 程序中存在的无条件的死循环(如while(1)循环中缺少跳出条件)也可能导致程序无法继续执行后续操作。
  5. 看门狗未喂或未关闭

    • 如果使用了看门狗功能但没有在适当的时候喂狗,或者看门狗被意外开启但没有关闭,都可能导致程序被频繁复位。

二、调试工具

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

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函数开始,逐步调用其他函数,直到达到当前执行点的。

三、找到程序跑飞位置

介绍完了程序跑飞的原因以及调试工具以后,接下来我为大家说一下如何找到程序跑飞的位置,有两种方式。

方式一、

(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)如果是堆栈溢出方式一二均无效,因为这两个方式都是通过堆栈进行寻址的。

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com