RTThread中HardFault_Handler分析

最新推荐文章于 2024-10-09 17:29:05 发布
最新推荐文章于 2024-10-09 17:29:05 发布
阅读量1w 收藏 51
点赞数 7
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/suny1234/article/details/89418980
版权

以Cortex-M3为例，RTThread在运行过程如果产生fault，会进人HardFault_Handler中断，RTThread对HardFault_Handler进行了重定义，HardFault_Handler函数在context_rvds.S文件中。函数内部做了一些工作对进入异常之前的处理器内部寄存器状态、工作模式、线程信息(如果异常是线程模式下产生)以及错误类型进行了输出。

HardFault_Handler大致工作流程入下：在这里插入图片描述

HardFault_Handler    PROC

    ; get current context
    TST     lr, #0x04               ；(1-1) 
    MRSNE   r0, msp                 ；(1-2)
    MRSEQ   r0, psp                 ；(1-3)

    STMFD   r0!, {r4 - r11}         ；(2)
    STMFD   r0!, {lr}               ；(3)

    MSRNE   msp, r0                 ；(1-4)
    MSREQ   psp, r0                 ；(1-5)

    PUSH    {lr}                    ；(4)
    BL      rt_hw_hard_fault_exception；(5)
    POP     {lr}                    ；(6)
	

    ORR     lr, lr, #0x04           ；(7)
    BX      lr                      ；(8)
    ENDP

    ALIGN   4                       ；(9)

    END                             ；(10)

  • (1)(1-1)到(1-3)实现的操作可以概括为：当EXC_RETURN[2]是否为0判断进入异常之前使用的是msp还是psp，

    然后将此sp的值保持到r0中。（怀疑RTT此处有bug ，正好与分析的逻辑是相反的，个人觉得MRSN应该对应psp, r0 ），下面分析下具体实现过程。

    关于TST指令 : 执行按位与操作，直接结果更新到状态寄存标志位Z

    这个指令通常与EQ、EN这些条件码来组合使用，必须注意测试后的结果全部位为0时候，标志位Z=1，此时EQ成立，反之Z= 0，NE成立。

    关于EXC_RETURN：Cortex-M3权威指南中对EXC_RETURN[2]的描述如下

    在进入异常服务程序后， LR的值被自动更新为特殊的EXC_RETURN， 当 EXC_RETURN[2]为0时候异常返回后从主堆栈做出栈操作（因为进入异常之前使用的是MSP），返回后使用MSP，当EXC_RETURN[2]为1时候异常返回后从进程堆栈做出栈操作（因为进入异常之前使用的是PSP），返回后使用PSP。

    （1-1）是判断EXC_RETURN[2]是否为0 ，为EXC_RETURN[2]为0时候与操作以后的结果为0则标志位Z=1，此时EQ成立执行(1-3)和(1-5)指令；EXC_RETURN[2]为1时与操作以后的结果为1则标志位Z=0，此时EN执行(1-2)和(1-4)指令。

    （1-2）更新msp到r0；

    （1-3）更新psp到r0；

    （1-4）更新r0到msp；

    （1-5）更新r0到psp；

  • (2)把r4 - r11压入堆栈

    关于STDF指令

    格式： STDF Rn{！}，{reglist}{^}

    其中Rn为基础寄存器，装有传递数据的初始地址，Rn不可以为R15；后缀！表示最后 的地址写回到Rn中；寄存器列表reglist包含一个或多个寄存器范围，使用“，”分开，如{R1，R2，R6-R9},寄存器排列由小到大；“^”后缀不允许在用户模式呈系统模式下使用。操作后会将Rn地址开始的数据依次更新到R1，R2，R6-R9中，同时将Rn里面装的地址更新为Rn-4*7 。

    如果Rn寄存器为SP 上面过程等价于push {reglist}

    第(1)步的操作已经把SP加载到r0中了，此时R0中存放的就是当前堆栈顶地址。假设此时的SP地址为0x20005818，即r0 = 0x20005818；执行第(2)步操作后r0=r0-4*8 （r4 - r11一共8个寄存器）r0 = 0x200057F8；整个过程其实就是完成r4 - r11的压栈操作。

    上面用先用r0进行压栈操作，然后在在把r0值传给sp，绕了一圈看似跟直接push操作效果无异。这样做其实有两个目的：

    • 第一因为在异常状态下处理工作在handler模式，此时的SP=MSP，而上面操作的目的是将r4-r11压入进入异常之前系统所使用的堆栈里，如果进入异常前使用的也是MSP那么上诉操作可以用push指令完成，将r4-r11压入主堆栈里。但是如果进入异常之前系统使用的是进程栈即SP = PSP，此时我们需要对PSP进行操作因此这里就不能使用push了。
    • 将r0指向了栈底，在下面rt_hw_hard_fault_exception函数调用中要作为函数的形参进行传递。

  • (3)此时的程序运行在异常模式下， lr的值被自动更新为特殊的EXC_RETURN，此处实际上是将EXC_RETURN的值压入了进入异常之前的堆栈

  • (4)在调用分支程序之前先lr压入当前堆栈，

  • (5)调用rt_hw_hard_fault_exception函数

    经过第（1）到（3）步的操作之后，此时进入异常之前的堆栈已经被更新为如下内容

在这里插入图片描述

由于R0的值为更新之后的堆栈栈底地址，此时我们调用rt_hw_hard_fault_exception函数就可通过R0把栈底地址传入函数内部进行进行数据分析，来判断进入导致硬件flault的原因以程序及故障点的定位。

下面我们对rt_hw_hard_fault_exception函数进行分析函数原型如下：

void rt_hw_hard_fault_exception(struct exception_info * exception_info);

函数参数是exception_info结构体类型指针,

struct exception_info
{
    rt_uint32_t exc_return;
    struct stack_frame stack_frame;
};

我们对exception_info结构体进行展开，展开后数据分布如下所示

{ 
    rt_uint32_t exc_return;//小端模式低地址在前
    {
        rt_uint32_t r4; 
        rt_uint32_t r5;
        rt_uint32_t r6;
        rt_uint32_t r7;
        rt_uint32_t r8;
        rt_uint32_t r9;
        rt_uint32_t r10;
        rt_uint32_t r11;
        {
            rt_uint32_t r0;
            rt_uint32_t r1;
            rt_uint32_t r2;
            rt_uint32_t r3;
            rt_uint32_t r12;
            rt_uint32_t lr;
            rt_uint32_t pc;
            rt_uint32_t psr;//高地址在后  
        }
    }   
}

由于处理器工作在小端模式下，RTThread对exception_info结构体的定义各个寄存器变量的内存分布与堆栈中寄存器的内存分布是一一对应的，这样很方便后续的指针操作。

/*
 * fault exception handler
 */
void rt_hw_hard_fault_exception(struct exception_info * exception_info)
{
    extern long list_thread(void);
    /*定义context指针指向寄存器堆栈空间*/
    struct stack_frame* context = &exception_info->stack_frame;

    /*如果定义了外部异常处理钩子函数则执行定义的函数，否则进行后续处理*/
    if (rt_exception_hook != RT_NULL)
    {
        rt_err_t result;

        result = rt_exception_hook(exception_info);
        if (result == RT_EOK)
            return;
    }

    /*打印状态寄存器信息*/
    rt_kprintf("psr: 0x%08x\n", context->exception_stack_frame.psr);

    /*打印通用寄存器组信息*/
    rt_kprintf("r00: 0x%08x\n", context->exception_stack_frame.r0);
    rt_kprintf("r01: 0x%08x\n", context->exception_stack_frame.r1);
    rt_kprintf("r02: 0x%08x\n", context->exception_stack_frame.r2);
    rt_kprintf("r03: 0x%08x\n", context->exception_stack_frame.r3);
    rt_kprintf("r04: 0x%08x\n", context->r4);
    rt_kprintf("r05: 0x%08x\n", context->r5);
    rt_kprintf("r06: 0x%08x\n", context->r6);
    rt_kprintf("r07: 0x%08x\n", context->r7);
    rt_kprintf("r08: 0x%08x\n", context->r8);
    rt_kprintf("r09: 0x%08x\n", context->r9);
    rt_kprintf("r10: 0x%08x\n", context->r10);
    rt_kprintf("r11: 0x%08x\n", context->r11);
    rt_kprintf("r12: 0x%08x\n", context->exception_stack_frame.r12);
    rt_kprintf(" lr: 0x%08x\n", context->exception_stack_frame.lr);
    rt_kprintf(" pc: 0x%08x\n", context->exception_stack_frame.pc);

    /*如果EXC_RETURN[2] 为1则进入异常之前为线程模式*/
    if(exception_info->exc_return & (1 << 2) )
    {
        rt_kprintf("hard fault on thread: %s\r\n\r\n", rt_thread_self()->name);

#ifdef RT_USING_FINSH
        list_thread();/*打印线程信息*/
#endif /* RT_USING_FINSH */
    }
    else/*否则为handler模式*/
    {
        rt_kprintf("hard fault on handler\r\n\r\n");
    }

#ifdef RT_USING_FINSH
    hard_fault_track();/*错误跟踪*/
#endif /* RT_USING_FINSH */

    while (1);
}

hard_fault_track();函数内部根据当前错误各个错误寄存器的状态对错误详细信息进行了进一步的解析，如感兴趣可自行研究。

  • (6)在调用分支程序之后先lr弹出当前堆栈。如果第5步调用的是c函数，可以省略(4),(6)操作，因为在进入函数之前和退出函数之后编译器会自动完成对lr的入栈和出栈操作。

  • (7)置位EXC_RETURN[2]使异常结束后进入线程模式，且使用PSP。

  • (8)异常返回。

半栈子君
关注
专栏目录
RT-Theard 配置报错No space in execution regions 和hard fault on handler，问题解决
abstract_think的博客
10-14 3731
1.No space in execution regions with .ANY selector matching can.o(.conststring). 使用rt-thread-v4.0.1版STM32f10x系列bsp出现错误 .\build\rtthread-stm32.axf: Error: L6406E: No space in execution regions with .AN...
STM32F407进入HardFault解决办法小结一点点
nicies的博客
11-05 2890
UCOSII 调试掉进HardFault_Handler,解决与定位方法 故障可能会有以下几种： 1、ucos分配的堆栈太小了 2、数组溢出 3、非法的指针 ，比如空指针 ，编译对的 4、OS_ENTER_CRITICAL()没有配套使用 5.在UCOSII系统中必须中断中配套使用OSINTENTER(),与OSINTExit(); 定位办法为： 1、首先在HardFault_Handler的while（1）处打上断点。 2、等待代码运行到此，这时查看寄存器LR，在左边一个是工程，一个是寄
【好记性不如烂笔头】（三）RT-Thread硬件错误的处理办法1
Porter_007的博客
07-10 1358
人麻了，什么鬼，因为以前有在裸机上运行，所以心中第一反应是线程给的堆栈大小小了？然后，直接从1024加到2048，心想，这样总应该好了吧，谁知道，熟悉的一幕出现了，又是刚才那个问题，天道好循环，苍天饶过谁。发现有两个error,我一看，-2，难道是时间片超时错误？但是，这两个线程是是从软件包里获取到的呀，应该不会错，但是还是尝试这改了一下，然而，并没有什么暖用。依旧是这个错误实在是不想去啃底层。先看下网上有没有人遇到吧，一搜索，好家伙，遇到这个问题的真不少。
STM32单片机编程调试常见问题(一) HardFault_Handler故障分析与解决
光子物联
09-28 2367
本文就介绍了在单片机开发中出现HardFault_Handler的原因，以及发现异常之后，问题的排查分析与解决方法,举例在STM32F103C8T6单片机中出现了空指针，数组越界等如何找出有问题的代码语句
stm32 HardFault_Handler调试及问题查找方法
热门推荐
xqhrs232的专栏
12-03 1万+
原文地址::http://www.51hei.com/bbs/dpj-39846-1.html 相关文章 1、STM32 出现 hardfault_handler 处理方法----http://blog.csdn.net/sunjiajiang/article/details/7582752 2、深入Cortex-M3内核的问题，程序跑飞了HardFault_Handler----h
RT-Thread使用CmBacktrace进行HardFault_Handler 追踪
挨踢农民的博客
10-24 4431
大家在用STM32的时候有没有遇到过HardFault的问题呢： 下面针对这个问题做个小总结。 现象还原：在debug模式下进行仿真调试，全速运行再停止运行，程序会跑到 HardFault_Handler函数中，产生 HardFault，即硬错。其产生的原因大概有如下几类： ​ (1)数组越界操作； ​ (2)内存溢出，访问越界； ​ (3)堆栈溢出，程序跑飞； ​ (4)中断处理错误； 针对HardFault问题的定位，网上有几种方法，大概都是围绕着：在debug模式下，查看一些地址，分
rt-thread 中对 hardfault 的处理
Tang的博客
07-03 1708
​ 当系统进入异常时，通常会进入异常对应的处理函数，当系统中存在非法操作时，比如除0、非对齐访问、爆栈，此时便会触发 hardfault 异常
Cortex-M3 / M4 Hard Fault Handler
weixin_34352005的博客
04-30 229
http://blog.frankvh.com/2011/12/07/cortex-m3-m4-hard-fault-handler/ If you’re seeing a Hard Fault exception on your Cortex M3 or Cortex M4 processor, this handler and information may help. I can’t ta...
HardFault_Handler问题查找方法
08-04
HardFault_Handler问题查找方法还有另一种方法，即将默认的HardFault_Handler处理方法改成BX LR直接返回的形式，然后在这条语句打个断点，一旦在断点中停下来，说明出错了，然后再返回，就可以返回到出错的位置的下...
rtthread hardfault_handler
09-19
rtthread中的hardfault_handler是一个处理硬错误的函数。在使用了本库提供的cmb_fault.s汇编文件时，如果项目中还有其他地方定义了该函数，则会出现HardFault_Handler被重复定义的错误。解决这个问题的两种方法是...
CJSON解析函数进入了HardFault_Handler(void)
08-23
- *1* *2* *3* [RTThread中HardFault_Handler分析](https://blog.csdn.net/suny1234/article/details/89418980)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_...
Cortex-M4 HardFault原因查找方法
Moon~
06-11 2607
Cortex-M4 HardFault原因查找方法 文章目录Cortex-M4 HardFault原因查找方法写此博客背景思想简说我的做法Step 1：Step 2:Step 3:Step 4:Step 5：Step 5:结果分析 写此博客背景 最近几日在Github上看到一个叫Armink的大神做了一个追踪Cortex-M系列的HardFault项目，具体连接：请点击这里 看完之后感觉很是方便，大大的简化了我们查找出现HardFault的原因，由于我手边有的是一个STM32F407IG的开发板，便想尝试一
已解决！【RT-Thread】hard fault on handler usage fault: SCB_CFSR_UFSR:0x02 INVSTATE
最新发布
weixin_64284370的博客
10-09 414
已解决！【RT-Thread】hard fault on handler usage fault: SCB_CFSR_UFSR:0x02 INVSTATE
RTThread中hardfault定位
qq_20999867的博客
07-28 4223
RTThread中fault定位方法 在《RTThread中HardFault_Handler分析》一文中已经分析了RTThread中对于fault中断的处理方法。接下来讲解如何根据错误输出信息对程序出现fault的位置进行定位。 rtthrea...
HardFault_Handler分析
d89538239的博客
07-11 964
今天用合泰的M0进入了HardFault_Handler查了下资料，总结下。 以下是我从高手那抄的： 在用Keil对STM32的程序进行仿真时程序有时会跑飞，停止仿真程序会停在HardFault_Handler函数里的死循环while(1)中。这说明STM32出现了硬件错误。 STM32出现硬件错误可能有以下原因： (1)数组越界操作...
分析出现HardFault_Handler\提示的其中本人遇到比较多的一个情况
OMGMac的博客
06-05 1159
不知道大家在编写单片机时候有没有遇到一个硬件错误，也就是HardFault_Handler\，这个错误我遇到过好几次，一般来说这种错误有几种情况会出现，比如。像一般遇到这种的，往往你去Debug调试时候往往程序会停在B.这里，你停止之后像keil会跳到相应位置提示你，你的程序在哪里卡住。所以解决方法就是：如果出现这种提示硬件中断错误，可以去查看一下自己的程序有没有哪里可能造成数据溢出等情况，有可能是因为这种情况，一般比较常见。本人水平有限，上述信息仅供学习参考，如有错误和不妥之处，请多多指教。
一个STM32 HardFault_Handler 的实例分析
qq_17459305的博客
04-04 586
未经许可，不得转载！(:з)∠) 参考： STM32 大小端序 与 堆栈及其增长方向分析 函数调用的压栈出栈过程 一个子程序返回时出现了HardFault_Handler， 我在子函数的最后的子函数返回后都增加了调试语句， 我能收到子函数的调试信息， 但是无法收到子函数返回后的调试信息， 苦思冥想，被群中一大佬一语惊醒： “进这个中断的，基本90%都是指针问题” ...... .......
HardFault_Handler故障原因排查
qq1226046245的博客
04-18 8820
出现HardFault_Handler故障的原因有两个方面： 内存溢出或者堆栈溢出 首先需要找到出现故障的地方 1.在main.c下自定义hard_fault_handler_c函数 void hard_fault_handler_c(uint32_t* hardfault_args) { static unsigned int stacked_lr; static unsigned int stacked_pc; stacked_lr = ((unsigned long) har
STM32 ~ MDK环境下调试程序 HardFault_Handler 相关
weixin_33928137的博客
02-01 157
STM32出现HardFault_Handler故障的原因主要有两个方面： 1、内存溢出或者访问越界。这个需要自己写程序的时候规范代码，遇到了需要慢慢排查。 2、堆栈溢出。增加堆栈的大小。 出现问题时排查的方法： 1、添加软件断点，一旦在调试过程中出现Hard Fault 则会停在__breakpoint(0)处。 void HardFault_Handler(void) { ...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值