ARM Cortex-M3/M4/M7 Hardfault异常分析

最新推荐文章于 2024-09-25 16:21:40 发布
最新推荐文章于 2024-09-25 16:21:40 发布
阅读量9.5k 收藏 93
点赞数 14
分类专栏： 软件相关 文章标签： Cortex-M HardFault Debug MCU
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_42992084/article/details/118883572
版权

写在前面：

本文章旨在总结备份、方便以后查询，由于是个人总结，如有不对，欢迎指正；另外，内容大部分来自网络、书籍、和各类手册，如若侵权请告知，马上删帖致歉。

在程序开发阶段，少不了 Debug调试，除去编程架构搭建不稳定所造成的错误外，大部分会出现或多或少的故障异常，而这些异常有可能是粗心或者对编程了解不到位所导致的 ‘ 堆栈溢出 ’ 、‘ 数组下标越界 ’ 、‘ 数学运算异常 ’ 等等；而本篇则主要以常见的进入 Hardfault中断来进行分析错误来源。


目录



一、ARM Cortex-M核心

ARM 架构，过去称作高级精简指令集机器（英语：Advanced RISC Machine，更早称作艾康精简指令集机器，Acorn RISC Machine），是一个精简指令集（RISC）处理器架构家族，其广泛地使用在许多嵌入式系统设计。

而对于 ARM Cortex-M 是 ARM架构处理器核心中，低阶系列的统称，由安谋控股所授权。这组核心的特点为低成本以及高能源效率的微处理器而优化设计，已有上千万个消费性设备中有此系列的微处理器。此系列核心包括 Cortex-M0、Cortex-M0+、Cortex-M1、Cortex-M3、Cortex-M4、Cortex-M7、Cortex-M23、Cortex-M33、Cortex-M35P和 Cortex-M55。其中 Cortex-M4 / M7 / M33 / M35P / M55 核心有浮点运算器的选项，若有浮点运算器的选项，会在型号后面说明，例如 Cortex-Mx with FPU或 Cortex-MxF，其中 x是核心编号。

如标题所述，其中 Cortex-M3/M4/M7同属 ARMv7-M架构，再细分一点，Cortex-M3实现的是 ARMv7-M架构，Cortex-M4 /Cortex-M7实现的是 ARMv7E-M架构。


二、ARMv7-M和 ARMv7E-M架构区别

如果有玩过过 Cortex-M3系列的芯片跟 Cortex-M4/M7的芯片，或多或少都知道 Cortex-M4/M7比 Cortex-M3多了 DSP跟硬件浮点运算，以下是 ARMv7E-M架构的拓展功能介绍：

在这里插入图片描述

由于 ARMv7E-M是 ARMv7-M的一个拓展子集，所以以下统称 ARMv7-M为 “ ARMv7-M ” 和 “ ARMv7E-M ” 的集合。


三、ARM 寄存器

在这里插入图片描述

1、通用寄存器（R0 - R12）

R0-R7被称为低组寄存器。所有指令都能访问它们。它们的字长全是 32位，复位后的初始值是不可预料的。

R8-R12被称为高组寄存器。这是因为只有很少的 16位 Thumb指令能访问它们，32位的 thumb-2指令则不受限制。它们也是 32位字长，且复位后的初始值是不可预料的。

2、堆栈指针寄存器（SP）

在 ARMv7-M架构中，共有两个堆栈指针 SP_main 和 SP_process，有时候也会把这个堆栈指针寄存器称为 R13。

  • 主堆栈指针（MSP），或写作 SP_main。这是缺省的堆栈指针，它由 OS内核、异常服务例程以及所有需要特权访问的应用程序代码来使用。
  • 进程堆栈指针（PSP），或写作 SP_process。用于常规的应用程序代码（不处于异常服用例程中时）。

3、链接寄存器（LR）

链接寄存器（LR） 主要用于在调用子程序时存储返回地址；有时候也会把这个链接寄存器称为 R14。

4、程序计数器（PC）

程序计数器作为 PC（或称为 R15）访问，它根据所执行指令的大小（在 ARM 状态下始终为 4 个字节）递增；并通过分支指令将目标地址加载到 PC 中。 您还可以使用数据处理指令直接加载 PC。

Note：寄存器 R0-R12、SP、LR和 PC被称为 Arm核心寄存器。这些寄存器可以描述为 R0-R15。更详细的说明可以看《ARMv7-M Architecture Reference Manual》B1.4章 Registers部分


四、异常定义

1、异常类型

在这里插入图片描述

2、异常更新

在入栈和取向量操作完成之后，执行服务例程之前，需要更新一系列的寄存器：

  • SP：在入栈后会把堆栈指针（PSP或 MSP）更新到新的位置。在执行服务例程时，将由 MSP负责对堆栈的访问。
  • PSR：更新 IPSR位段（地处PSR的最低部分）的值为新响应的异常编号。
  • PC：在取向量完成后，PC将指向服务例程的入口地址，
  • LR：在出入 ISR的时候，LR的值将得到重新的诠释，这种特殊的值称为 “EXC_RETURN”，在异常进入时由系统计算并赋给 LR，并在异常返回时使用它。EXC_RETURN的二进制值除了最低 4位外全为 1，而其最低4位则有另外的含义。

以上是在响应异常时核心寄存器的变化。另一方面，在 NVIC中，也会更新若干个相关有寄存器。例如，新响应异常的悬起位将被清除，同时其活动位将被置位。

3、异常返回值

在进入异常服务程序后，将自动更新 LR的值为特殊的 EXC_RETURN。这是一个高 28位全为 1的值，只有[3:0]的值有特殊含义，如下图所示。当异常服务例程把这个值送往 PC时，就会启动处理器的中断返回序列。因为 LR的值是由内核自动设置的，所以只要没有特殊需求，就不要改动它。

在这里插入图片描述

在这里插入图片描述


五、异常入口的堆栈对齐

Armv7-M 架构保证堆栈指针值至少是 4 字节对齐的。 但是，某些软件标准要求堆栈指针按 8 字节对齐，并且体系结构可以强制执行这种对齐。 在配置和控制寄存器的 CCR. STKALIGN 位指示中作为异常入口的一部分，决定着处理器是将 SP 对齐到 4 个字节还是 8 个字节。 该位是由编译器决定是否为：
• RW，在这种情况下，它的复位值是由编译器决定的。
• RO，在这种情况下它是 RAO，表示 8 字节 SP 对齐。
Arm 不赞成实现或使用 4 字节 SP 对齐。

Register — CCR. STKALIGN bit：

在这里插入图片描述

下图显示了在异常发生时进入堆栈的信息框架，以及处理器如何在堆栈上保留一个额外的字（如果需要的话），以获得 8字节堆栈对齐。（这里就是我们要分析地方）

在这里插入图片描述


六、HardFault异常分析处理

HardFault是一种通用故障，它适用于所有不能被任何其他异常机制处理的故障类。通常，HardFault用于不可恢复的系统故障，尽管这不是必需的，而且 HardFault的某些用途可能是可恢复的。HardFault永久启用，优先级固定为 -1。

方法一：先来个简单的，使用第三方组件 “cm_backtrace”

项目地址：https://github.com/armink/CmBacktrace

怎么用这里就不说了，毕竟官方已经写得很清楚了，而且还有相应的 Demo例程。

使用该方法的特点是不需要过多的关注更底层的东西，只需移植好后配置相应的功能就好了，而且它可以离线（脱离仿真器）来寻找错误点；但是前提是你的串口正常，而且还需要预留部分内存供其执行。

方法二：仿真情况下的 bug寻找

如果是平常的 while循环执行，导致挂掉了无法切换任务，那么我们可以轻松通过上下文切换寻找问题；但是在 HardFault异常中它并不给你显示执行错误的所在地方，而是直接跳到 HardFault中断中，这往往让我们头大。

Keil平台的可以看：

https://www.keil.com/appnotes/files/apnt209.pdf

IAR平台的可以看：

https://www.iar.com/knowledge/support/technical-notes/debugger/debugging-a-hardfault-on-cortex-m/

GCC平台的可以看：

方法三。。。

方法三：通过 ARM 寄存器逆向推导

使用该方法的前提是获取到第五个大点最后一张图展示的核心寄存器（R0-R3、R12、LR、PC、xPSR以及原 SP）的数值。

1、常见的核心寄存器数据获取

一般地，我们会使用以下代码嵌入到 HardFault中断中，使其在入口处打印服务异常时各核心寄存器的值：

/* Exception frame without floating-point storage
* hard fault handler in C,
* with stack frame location as input parameter
*/
void
hard_fault_handler_c(unsigned int * hardfault_args)
{
    unsigned int stacked_r0;
    unsigned int stacked_r1;
    unsigned int stacked_r2;
    unsigned int stacked_r3;
    unsigned int stacked_r12;
    unsigned int stacked_lr;
    unsigned int stacked_pc;
    unsigned int stacked_psr;
   
    //Exception stack frame
    stacked_r0 = ((unsigned long) hardfault_args[0]);
    stacked_r1 = ((unsigned long) hardfault_args[1]);
    stacked_r2 = ((unsigned long) hardfault_args[2]);
    stacked_r3 = ((unsigned long) hardfault_args[3]);
   
    stacked_r12 = ((unsigned long) hardfault_args[4]);
    stacked_lr = ((unsigned long) hardfault_args[5]);
    stacked_pc = ((unsigned long) hardfault_args[6]);
    stacked_psr = ((unsigned long) hardfault_args[7]);
   
    printf ("[Hard fault handler]\n");
    printf ("R0 = %x\n", stacked_r0);
    printf ("R1 = %x\n", stacked_r1);
    printf ("R2 = %x\n", stacked_r2);
    printf ("R3 = %x\n", stacked_r3);
    printf ("R12 = %x\n", stacked_r12);
    printf ("LR = %x\n", stacked_lr);
    printf ("PC = %x\n", stacked_pc);
    printf ("PSR = %x\n", stacked_psr);
#ifndef CW
    printf ("BFAR = %x\n", (*((volatile unsigned long *)(0xE000ED38))));
    printf ("CFSR = %x\n", (*((volatile unsigned long *)(0xE000ED28))));
    printf ("HFSR = %x\n", (*((volatile unsigned long *)(0xE000ED2C))));
    printf ("DFSR = %x\n", (*((volatile unsigned long *)(0xE000ED30))));
    printf ("AFSR = %x\n", (*((volatile unsigned long *)(0xE000ED3C))));
#else
    printf ("BFAR = %x\n", (*((volatile unsigned int *)(0xE000ED38))));
    printf ("CFSR = %x\n", (*((volatile unsigned int *)(0xE000ED28))));
    printf ("HFSR = %x\n", (*((volatile unsigned int *)(0xE000ED2C))));
    printf ("DFSR = %x\n", (*((volatile unsigned int *)(0xE000ED30))));
    printf ("AFSR = %x\n", (*((volatile unsigned int *)(0xE000ED3C))));
#endif
    for(;;)
    {}
}

/* The prototype shows it is a naked function - in effect this is just an
assembly function. */
void HardFault_Handler( void ) __attribute__( ( naked ) );

/* The fault handler implementation calls a function called
prvGetRegistersFromStack(). */
void HardFault_Handler(void)
{
  #ifdef CORTEX_M3_M4_M7
    asm volatile(
        " tst lr, #4                        \n" /* Check EXC_RETURN[2] */
        " ite eq                            \n"
        " mrseq r0, msp                     \n"
        " mrsne r0, psp                     \n"
        "b hard_fault_handler_c             \n"
        : /* no output */
        : /* no input */
        : "r0" /* clobber */
    );
  #else
    asm volatile(
        "movs r0, #4                        \n"
        "mov  r1, lr                        \n"
        "tst  r0, r1                        \n" /* Check EXC_RETURN[2] */
        "beq 1f                             \n"
        "mrs r0, psp                        \n"
        "ldr r1,=hard_fault_handler_c       \n"
        "bx r1                              \n"
        "1:mrs r0,msp                       \n"
        "ldr r1,=hard_fault_handler_c       \n"
        : /* no output */
        : /* no input */
        : "r0" /* clobber */
    );
  #endif
}

Note：

  1. 值得注意的是 void HardFault_Handler(void);函数是相应的 HardFault中断函数，不同的厂家会定义不同的名称。

  2. 对于不同的编译器，如：armcc、iar、gcc for arm等，需要把相应的关键字替换掉（eg：asm、naked）。

    naked 关键字拓展： https://www.keil.com/support/man/docs/armclang_ref/armclang_ref_jhg1476893564298.htm
    https://zhuanlan.zhihu.com/p/33933891

2、逆向定位入口

如果有看过方法二的两个链接，那么就很容易理解以下的分析了：

  1. 确保你能正常获取输出数据（包括但不限于仿真查看、串口打印、SWO输出、SEGGER_RTT输出等等）。
  2. 由于我们在第一点修改过代码，所以可以直接查看 LR和 PC两个的值；因为这两个的值是关键。
  3. 使用 addr2line软件定位故障代码位置（使用方法：https://sourceware.org/binutils/docs-2.27/binutils/addr2line.html#addr2line），addr2line属于 GNU Binutils组件之一，获取可以从方法一里面的 tools文件夹里获取，也可以从 安装路径\GNU Tools ARM Embedded\5.4 2016q3\bin\arm-none-eabi-addr2line.exe 提取出来。

3、使用演示

先制造一个 HardFault：

void fault_test_by_div0(void) {
    volatile int * SCB_CCR = (volatile int *) 0xE000ED14; // SCB->CCR
    int x, y, z;

    *SCB_CCR |= (1 << 4); /* bit4: DIV_0_TRP. */

    x = 10;
    y = 0;
    z = x / y;
    printf("z:%d\n", z);
}

/************************************************
函数名称 ： main
功    能 ： 主函数入口
参    数 ： 无
返 回 值 ： 无
*************************************************/
int main( void )
{
#ifdef DEBUG
    debug();
#endif

    BaseType_t xReturn = pdPASS; /* 定义一个创建信息返回值，默认为 pdPASS */

    prvSetupHardware();

    fault_test_by_div0();

    /* Start the tasks defined within this file/specific to this demo. */
    xReturn = xTaskCreate( (TaskFunction_t)prvUser_Task,			/* 任务入口函数 */
                           (const char *)"prvUser_Task",			/* 任务名字 */
                           (uint16_t)configMINIMAL_STACK_SIZE,		/* 任务栈大小 */
                           (void *)NULL,							/* 任务入口函数参数 */
                           (UBaseType_t)mainCREATOR_TASK_PRIORITY,	/* 任务的优先级 */
                           (TaskHandle_t *)UserTaskCreate_Handle );	/* 任务控制块指针 */

    if(pdPASS == xReturn) {
        /* Start the scheduler. */
        vTaskStartScheduler();
    }

    /* Will only get here if there was not enough heap space to create the
    idle task. */
    return 0;
}

/*----------------------------- End -----------------------------*/

接着可以观察到程序已经跑到 HardFault_Handler里并输出相应信息了：

在这里插入图片描述

然后利用 addr2line，执行命令 arm-none-eabi-addr2line.exe -e "可执行映像" -a -f "相应的值" （注：实际命令并不需要双引号 “ ”，应用可看下图）：

  • -e ：指定可执行映像名称
  • -a ：显示函数地址
  • -f ：显示函数名称

在这里插入图片描述

然后，对于不同的编译器，可执行映像并不一样（像 Keil是 .axf、IAR是 .out）；最后，如果细心的可以看到命令后面的两个值只有 PC的值是对应上，第二个值并不是 LR的值，而是其减去 4的结果；若果你直接使用 LR值，你会发现定位出来的下一条指令要执行的地方，至于为什么要减掉 4，是因为在 ARM下执行指令的大小始终为 4 个字节递增，所以可以通过减掉 4，使其指向上一条内容。

在这里插入图片描述

在这里插入图片描述

方法四：透过最底层进行分析

这种方法不需要修改什么，在进入 HardFault_Handler后直接分析核心寄存器。

同样的，还是先制造一个 HardFault，沿用方法三的 fault_test_by_div0();函数代码，然后直到进入 HardFault_Handler后，（注意，这里的 HardFault_Handler中断函数并没有像方法三那样区嵌入代码，而是保持其原始的样子）：

在这里插入图片描述

接着跟上面的一样，获取各核心寄存器的值（ps：这里用的仿真查看）：

在这里插入图片描述

在这里就不是像方法三那样直接拿 LR和 PC这两个值来用了，必须进行层层分析：

  1. 查看 LR值是对应下图的哪个：

    在这里插入图片描述

    通过转换，-7为 0xFFFFFFF9，然后在第四大点的第三小点有讲过 LR=0xFFFF_FFF9时是使用 MSP，而 LR=0xFFFF_FFFD时则使用 PSP；所以我们可以确定该返回值是被压入到主堆栈指针（MSP）中。

  2. 找到 MSP指示的值：

    在这里插入图片描述

    得到该值为 0x2002ffc8。

  3. 查看该值所对应的内存块：

    在这里插入图片描述

    得到紫色框里的两个数据（嘿嘿，是不是很神奇，居然跟方法三的 LR、PC值一样），可能你会疑惑，为什么是提取该地址往后第六、七个数（4 字节递增），而不是其他呢？这就看第五个大点了，它的入栈顺序以及地址位置都是有规律的，可以归纳为下图：

    在这里插入图片描述

    按箭头方向，顺数第六、七是不是就是 LR、PC值啊，而这里就是旧的内容信息；所以跟方法三比较一下，其实方法三的那段嵌入代码，就是让其改变各个核心寄存器的信息内容，使其不要存储跳转到 HardFault_Handler，而是存储跳转前的数据信息。

  4. 到了这步，就是使用 addr2line来定位，这里就不说了，方法三里面有写。


参考：

ARM架构

ARM Cortex-M

Arm® Cortex®-M4 in a nutshell

<<ARM Cortex-M3 权威指南>>

ARMv7-M Architecture Reference Manual

Overview of the ARM Architecture

error: Hard Fault Handler

How to debug a HardFault on an ARM Cortex-M MCU

Debugging a ARM Cortex-M Hard Fault

Analyzing HardFaults on Cortex-M CPU

ARM Cortex M3: Recovering from a Hard Fault

Debug a HardFault

夏沫の浅雨
关注
专栏目录
定位ARM Hard Fault 的方法
流风回雪的博客
09-15 1061
1，用Keil的话，可以做如下操作： 先将fault中断函数的内容改为: HardFault_Handler\ PROC ;EXPORTHardFault_Handler[WEAK] ;B. IMPORT hard_fault_handler_c ...
国民技术N32_CortexM4系统异常分析方法
leo_zwliao的博客
04-08 1339
Cortex-M处理器中，所有的错误异常默认都会触发HardFault异常（异常类型编号为3，在xFSP中体现）， 这篇应用笔记主要介绍了HardFault错误引起的原因、如何定位错误代码已经一些案例分析，以便用户能够在 开发过程中避免出现该问题、解决问题，编写出更加健壮的代码。
Cortex-M系列hardfault产生后防止宕机的方法
最新发布
gch293的专栏
09-25 1036
hardfault产生后防止宕机并对栈信息做记录的方法
【ARM Cortex-M 系列 2.1 -- RT-Thread Cortex-M7 异常处理及 hardfault 处理分析】
CodingCos的博客
11-10 3620
RT-Thread 系统异常及入门及渐进3 -- Cortex-M7 异常处理及hardfault 处理流程
ARM hardfault分析
09-04 5894
ARM hardfault handler出现有以下几种情况： 1. 内存访问没有对齐，
MCU HardFault学习小记（一）——基于Arm Cortex-M系列
青渡QAQ的博客
07-01 3039
HardFault（硬件错误）是一类在嵌入式系统开发中较为常见的系统异常，优先级仅低于复位和NMI（不可屏蔽中断）。当系统运行过程中遇到了某些错误时程序就会跳转至HardFault_Handler函数中，引发程序故障进而影响程序的正常运行。本文介绍了HardFault问题的背景和解决HardFault问题所需的理论知识，并在此基础上介绍了两种HardFault问题的查找和分析法。
应对STM32 Cortex-M3 Hard Fault异常
weixin_30478923的博客
03-20 1119
STM32 Cortex-M3 Hard Fault Hard fault (硬错误,也有译为硬件错误的)是在STM32（如无特别说明，这里的STM32指的是Cortex-M3的核）上编写程序中所产生的错误，造成Hard Fault错误的原因也是最为纷繁复杂的。由于能导致该错误的原因很多，所以一但出现，比较难找到其原因。网上有很多类似的这种方法，现在我将其稍加整理，并结合我曾经遇到过的问题，详细...
ARM 出现 hardfault 如何利用栈回溯代码
qq_36525177的博客
08-08 395
基本原理是每次调用函数时，ARM cpu 都会将函数返回地址放入 LR 寄存器中，多层调用时，C 编译器会自动将 LR寄存器内容push到栈空间。这样一来，随着函数调用的不断深入，栈中保存着整个调用链的返回地址。我们假设数据是真的返回地址，那么其前面一条代码必然是 BL 或 BLX 指令，通过检查该地址出的前一条代码，我们就可筛选出真的返回地址，从而得到整个函数的调用链。我们通过获取出错时的栈地址，遍历栈空间，由于这些数据除了返回地址，还可能是局部变量，也可能是寄存器值。因此需要进一步筛选。
Using Cortex-M3/M4/M7 Fault Exceptions
11-11
本文主要围绕“Using Cortex-M3/M4/M7 Fault Exceptions”这一主题，深入探讨了Cortex-M处理器在遇到非法内存访问和错误程序条件时的异常处理流程，这对于理解和优化软件开发过程至关重要。 首先，Cortex-M处理器...
【cortex-m3/m4/m7常见死机、跑飞、异常、hardfault等查找方法】
热门推荐
zhangqi3229266的博客
12-05 1万+
死机是所有软件从业者无法回避的坑，而死机问题导致的原因千奇百怪，对于可以稳定复现现场的问题，还是比较好处理的，最可怕的情形是你怎么也复现不了，但是在客户那偶发。在此对笔者解决过的死机问题做个分享，若有谬误，请指正。 总的思路为根据堆栈和寄存器，定位到出现异常的语句，然后从逻辑上分析导致其异常可能的原因。 基础简介 在查找此类问题时，通用寄存器，堆栈，简单的汇编指令是需要必备的基础知识，以我们最常用的M3/M4内核做个简单介绍。具体知识可以自行学习cortex-M3权威手册等资料。 寄存器简介 ...
Cortex-M3/M4/M7处理器故障异常处理详解
"这篇文档是Keil公司关于Cortex-M3/M4/M7处理器HardFault异常的官方教程，适用于MDK开发环境。该文档详细解释了Cortex-M系列处理器中的故障异常模型，从程序员的角度出发，阐述了这些异常在软件开发周期中的应用，并...
ARM内核单片机进入 hardfault的问题查找
03-06
在单片机进入hardfault是非常常见的一个问题，对于新手来说这是最令人头疼的，对于ARM内核的不熟悉，但是查找问题变得很困难，希望这篇文章能解决你的问题
Arm Cortex-M Comparison Table_v3.pdf
04-27
### ARM Cortex-M处理器系列对比分析 #### 概述 ARM Cortex-M处理器家族是为成本与能源效率极高的微控制器优化设计的。这些处理器被广泛应用于各类设备中，包括物联网（IoT）、工业以及日常消费电子产品等。Cortex...
ARM 之十二 Cortex-M 内核异常处理、异常定位方法、在线调试、Keil MDK-ARM 的使用
技术干货
02-25 3747
  在 ARM 平台上开发，开发工具的选择其实并不是很多，基本可以分为三大类：Keil MDK-ARM、IAR for ARM、GCC for ARM 系，其中用的比较多的基本就是 Keil MDK-ARM、IAR for ARM 这俩。而 GCC for ARM 系的 IDE 有很多，但是他们统一都是使用 GCC for ARM 作为编译器构建套件，IDE 都是各家自定义的。例如，ST 有、SEGGER 有 Embedded Studio。 构建（Build）   从源文件到可执行文件，需要经过预处理、编
ARM_CortexM3内核HardFault问题记录
默默奔跑
05-30 1670
目的：        提供一种能够解决Fault问题的方法硬件环境：            STM32F103软件环境：            无操作系统问题复现：        在代码处执行*((u32*)0x3)  = 9;问题现象：        代码挂死在下面的位置处。解决方法：        1：查看当前通用寄存器的值见下图                                ...
Cortex-M4处理器 系统异常
Caramel_biscuit的博客
01-26 1293
如果发生的异常与被处理的异常具有相同的优先级，则处理程序不会被抢占，而与异常编号无关。处理器可以接受延迟到达的异常，直到原始异常的异常处理程序的第一条指令进入处理器的执行阶段。如果在异常进入期间发生另一个更高优先级的异常，则处理器开始执行该异常的异常处理程序，并且不更改先前异常的挂起状态。如果在异常进入期间没有更高优先级的异常发生，处理器开始执行异常处理程序，并自动将相应的挂起中断的状态改为活动。当处理器执行异常处理程序时，如果异常处理程序的优先级高于正在处理的异常的优先级，则异常可以抢占异常处理程序。
【嵌入式操作系统-3】Cortex-M7异常模型
qq_36115224的博客
04-28 1956
文章目录异常状态异常类型异常处理程序中断向量表异常和返回抢占异常返回Tail-chainingLate-arriving 异常状态 在Cortex-M7处理器中有四种异常状态 不活跃 异常没有被处理和挂起 挂起 异常发生，等待被CPU处理 活跃 异常正在被CPU处理 活跃和挂起 CPU正在处理一个异常，但是还有一个与他相同中断源的异常处于挂起状态 异常类型 异常类型 描述 复位异常（Reset） 复位异常始终有效，他有一个固定的优先级-3 不可屏蔽中断（NMI
Cortex-M4处理器 故障处理
Caramel_biscuit的博客
01-26 585
通常，异常优先级与异常掩码寄存器的值一起决定处理器是否进入故障处理程序，以及一个故障处理程序是否可以抢占另一个故障处理程序。在某些情况下，具有可配置优先级的故障被视为HardFault。这被称为优先级升级，故障被描述为升级到HardFault。
Cortex-M7 异常（中断）基础总结
m0_47462420的博客
03-26 1749
Cortex-M7集成了嵌套向量中断控制器（Nested Vectored Interrupt Controller），最大支持256个中断优先级，其 “向量” 指示着中断服务函数（interrupt service routines, ISRs)响应的方式不再通过软件编程来实现，即由硬件堆叠的寄存器组和相应可挂起的多指令加载和存储指令（可被中断打断，给中断让路），来实现从中断响应到ISR入口的快速选择这一过程。
评论 4
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值