【STM32】MCU HardFault异常处理分析流程及总结(一)

一、 背景引入

在开发过程中,经常会遇到进入HardFault死循环的问题,主要原因如下:

  • 数组越界操作
  • 内存溢出,访问越界
  • 堆栈溢出,程序跑飞
  • 中断处理错误
    针对出现HardFault问题,我们需根据内核对异常的响应处理流程分析,同时结合通过keil生成的map文件来查看程序互相依赖,内存大小,程序大小等信息来判断。

二、基础知识

1. CortexM3内核

在这里插入图片描述

2. 寄存器组

Cortex‐M3 处理器拥有 R0‐R15 的寄存器组。其中 R13 作为堆栈指针 SP。 SP有两个,但在同一时刻只能有一个可以看到,这也就是所谓的“banked”寄存器。
在这里插入图片描述
●R0-R12:通用寄存器
R0‐R12 都是 32 位通用寄存器,用于数据操作。但是注意:绝大多数 16 位 Thumb指令只能访问 R0‐R7,而 32 位 Thumb‐2 指令可以访问所有寄存器。
●Banked R13: 两个堆栈指针
Cortex‐M3 拥有两个堆栈指针,然而它们是 banked,因此任一时刻只能使用其中的一个。
主堆栈指针(MSP),或写作 SP_main。这是缺省的堆栈指针,它由 OS 内核、异常服务例程以及所有需要特权访问的应用程序代码来使用。
进程堆栈指针(PSP),或写作 SP_process。用于常规的应用程序代码(不处于异常服务例程中时)。
为了在进行模式转换的时候,减少堆栈的保存工作。同时也可以为不同权限的工作模式设置不同的堆栈。
●R14寄存器是链接寄存器(LR),当呼叫一个子程序时,由R14存储返回地址。
●R15寄存器是程序寄存器(PC),指向程序当前的地址。如果修改它的值,就能改变程序的执行流。

3. 三级流水线

CortexM3架构采用三级流水线的方式实现指令的操作。流水线操作的本质是利用指令运行的不同阶段使用的CPU 硬件互不相同,并发的运行多条指令,从而提高时间效率。
三级流水线操作并行运行指令的方式: 在对第1条指令进行译码的时候,可以同时对第2条指令进行取指操作;在对第1条指令进行执行的时候,可以同时对第2条指令进行译码操作,对第3条指令进行取指操作。显然,这样就可以将该程序的运行总时间从30秒缩减为12秒,提速近3倍。
在这里插入图片描述

4. 异常

Cortex‐M3 在内核水平上搭载了一个异常响应系统, 支持为数众多的系统异常和外部中
断。其中,编号为 1-15 的对应系统异常,大于等于 16 的则全是外部中断。除了个别异常的优先级被定死外, 其它异常的优先级都是可编程的(所有能打断正常执行流的事件都称为异常)。
在这里插入图片描述
在这里插入图片描述
在 CM3 中,优先级的数值越小,则优先级越高。CM3 支持中断嵌套,使得高优先级异常会抢占(preempt)低优先级异常。有 3 个系统异常:复位, NMI 以及硬 fault,它们有固定的优先级,并且它们的优先级号是负数,从而高于所有其它异常。所有其它异常的优先级则都是可编程的(但不能编程为负数)。

中断的输入及悬起行为
当某中断的服务例程开始执行时,就称此中断进入了“活跃”状态,并且其悬起位会被硬件自动清除,在一个中断活跃后,直到其服务例程执行完毕,并且返回了,才能对该中断的新请求予以响应。
在这里插入图片描述

咬尾中断
当前正在执行中断,又有一个中断到来且这个中断优先级比正在执行的中断优先级低,这个中断暂时被挂起,等到当前中断执行完后不再执行堆栈操作,而直接进入挂起的中断,不需要再进行出栈入栈操作。

在这里插入图片描述
在这里插入图片描述

  • 1
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
### 回答1: STM32 死机(也称为硬件故障)是指STM32单片机在运行过程中出现了无法恢复的错误,并导致程序停止响应或崩溃的情况。硬件故障是由于程序运行时发生了非法指令、存储器读写错误、中断异常等原因引起的。 对于STM32硬件故障的分析,可以通过以下步骤来进行: 1. 异常向量表(NVIC)定位:硬件故障会导致程序跳转到异常处理器,通过查看异常向量表可以确定具体是哪个异常处理器被触发。 2. 寄存器值分析:查看产生硬件故障时相关寄存器的值,如程序计数器(PC)、堆栈指针(SP)等。这些值可以提供更多关于故障发生时的程序状态的信息。 3. 中断日志分析:如果硬件故障是由于中断异常引起的,可以通过打印中断日志来获取更多信息。中断日志包括中断号、中断源、中断服务例程等。 4. 调试工具使用:使用STM32开发板上的调试工具(如J-Link、ST-Link等)进行调试,可以通过断点、查看寄存器、查看存储器等功能,进一步分析硬件故障。 5. 代码回溯:通过查看产生硬件故障之前执行的代码,可以确定是否存在编程错误或者不合法操作,如访问空指针、溢出问题等。 在分析完硬件故障后,可以根据具体情况采取相应措施来修复问题。常见的修复措施包括修改代码错误、检查硬件连接、更新驱动程序等。同时,也推荐在开发过程中使用断言(assert)功能,及时捕获并处理潜在的硬件故障。 ### 回答2: STM32死机HardFault通常是由于程序错误或硬件故障引起的。下面是对STM32死机HardFault进行分析的常见步骤: 1. 排查硬件问题:确保硬件电源和时钟正常工作,并检查是否存在短路或其他硬件故障,例如引脚连接错误等。 2. 检查编程错误:查看代码中是否有潜在的错误,例如没有初始化变量、数组越界、栈溢出等。使用调试工具(例如GDB)可以更方便地检测程序中的错误。 3. 检查中断问题:HardFault中断可能是由于异常中断导致的。检查中断的优先级设置和中断服务程序是否正确。 4. 查看硬件异常:使用STM32芯片自带的硬件调试模块(例如Cortex-M3的Fault Status Register)可以查看硬件异常的状态。这些状态信息可以提供有关错误原因的线索。 5. 查看堆栈信息:查看堆栈的状态可以帮助我们了解在死机时程序执行的位置。这些信息可以通过调试工具或在程序中添加日志输出来获得。 6. 运行时错误检测:在程序中使用合适的错误检测方法,例如检测指针是否为空、检测函数返回值等,可以帮助我们在错误发生时及时发现问题。 7. 固件更新:如果已确定硬件问题和代码错误都不存在,则可能是芯片固件本身的问题。在这种情况下,更新芯片固件可能是解决问题的方法。 以上是对STM32死机HardFault进行分析的常见步骤,可以根据具体情况进行适当的调整。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值