1. Cortex-M3系统控制块（SCB）核心架构解析

在嵌入式实时系统开发中，尤其是基于ARM Cortex-M3内核的项目，中断和异常处理机制是决定系统实时性、可靠性的基石。很多开发者熟悉在RTOS或HAL库层面调用API来配置中断，但一旦遇到棘手的系统级问题，比如中断不响应、优先级混乱、或是难以追踪的硬件故障，往往就束手无策了。这时，深入理解并直接操作处理器内核的“神经中枢”——系统控制块（System Control Block, SCB）寄存器，就成了解决问题的关键。SCB并非外设，它是Cortex-M3内核的一部分，负责管理整个处理器的异常模型、优先级系统、电源控制以及故障诊断。掌握它，意味着你能从“驾驶员”升级为“机械师”，不仅能开车，更能透彻理解引擎的每一个气缸如何工作，并在出现异响时精准定位问题。

Cortex-M3的异常系统非常规整，它将所有可能打断当前执行流的事件，无论是来自外设的中断（IRQ）、不可屏蔽中断（NMI），还是内核自身产生的故障（Fault），都统一为“异常”，并赋予一个唯一的“异常编号”。这个编号体系是理解后续所有寄存器的基础。例如，复位是1号，NMI是2号，硬故障是3号，而外部中断0则是16号。SCB寄存器组就围绕着这套编号体系，提供了全方位的控制与状态查询能力。它位于固定的内存映射地址0xE000E000开始的位置，通过一组32位的寄存器，让我们能够以编程方式干预内核最核心的行为。

对于从事电机控制、无人机飞控、工业通信网关等高实时性、高可靠性嵌入式开发的工程师来说，透彻理解SCB是必备技能。它让你能实现更精细的中断调度策略，比如动态调整SysTick或PendSV的优先级以优化上下文切换；能构建健壮的故障处理框架，精准区分是内存访问越界还是总线错误；甚至能利用软件触发中断（SGI）在多核（Cortex-M3多核变体）或复杂任务间进行高效的处理器间通信。本文将从实际应用出发，结合官方手册的寄存器描述，为你拆解SCB中关键寄存器的每一个比特，并分享我在调试复杂系统时积累的实战经验和避坑指南。

2. 中断生成与触发机制深度剖析

中断的触发通常源于外部引脚电平变化或外设内部事件，但Cortex-M3内核也提供了从软件内部直接生成中断的能力，这主要通过软件触发中断寄存器（SWTRIG）和中断控制与状态寄存器（INTCTRL）来实现。这种能力为软件设计带来了极大的灵活性。

2.1 软件触发中断（SWTRIG）的实战应用

SWTRIG寄存器是一个只写（WO）寄存器，位于SCB基地址偏移0xF00处。它的核心功能非常直接：向它的低6位（INTID[5:0]）写入一个目标中断的编号（0-15，对应SGI 0-15；或更宽的范围，具体取决于实现），内核便会立即将该中断置为挂起状态，如果该中断已使能且优先级足够高，处理器就会响应该中断，跳转到对应的服务例程。

为什么需要软件触发中断？其应用场景远超简单的“模拟中断”。在多任务RTOS中，一个核心机制是“上下文切换”，通常由PendSV异常（异常号14）来完成。任务调度器（例如在SysTick中断中）决定切换任务后，并不直接进行复杂的现场保存与恢复，而是简单地置位PendSV的挂起位。由于PendSV被设置为最低优先级，处理器会在退出所有更高优先级的中断服务程序后，才平稳地执行PendSV，完成上下文切换。这个过程就是通过设置INTCTRL寄存器的PENDSVSET位（而非SWTRIG）来实现的，它是系统级软件触发异常的一个典型例子。

对于SWTRIG触发的SGI，其经典应用在于多处理器环境（如Cortex-M3的双核变体Cortex-M3 MPCore）。一个处理器可以通过写自身SCB的SWTRIG寄存器，触发另一个处理器上的中断，实现核间通信（IPC）。即使在单核系统中，SGI也可用于实现“软件信号”或“任务间中断”，让一个任务或模块能异步地通知另一个。

关键配置与安全考量：SWTRIG寄存器默认只能由运行在特权模式下的代码访问。这是为了防止用户态（非特权）应用程序随意触发中断，扰乱系统。然而，手册中提到，当配置与控制寄存器（CFGCTRL）中的MAINPEND位被置1时，非特权软件也能访问SWTRIG。除非你有非常明确的、受控的需求（例如，在特定的安全沙箱中运行用户代码并允许其触发有限的内部事件），否则强烈建议永远不要开启此功能。保持SWTRIG的特权访问是系统稳定性的重要防线。

注意：在写入SWTRIG时，必须确保写入的值是有效的、已分配的中断ID。写入一个未使用或保留的ID可能导致不可预知的行为。通常，芯片厂商的数据手册或编程手册会明确列出可用的SGI编号。

2.2 中断控制与状态（INTCTRL）的精细控制

INTCTRL寄存器（偏移0xD04）是一个功能密集的状态与控制枢纽。它不仅是只读的状态窗口，也是控制特定系统异常的关键开关。

状态查询部分：

• VECACT[5:0]：这是最重要的只读字段之一，它告诉你处理器当前正在服务哪个异常。如果值为0，表示处理器处于线程模式（Thread Mode）；如果非零，则对应正在执行的异常处理程序（Handler Mode）的编号。在调试复杂的中断嵌套问题时，读取此字段能立刻确认CPU正在处理哪个中断。
• VECPEND[17:12]：指示当前挂起的、优先级最高的、已使能的异常编号。它考虑了BASEPRI和FAULTMASK寄存器的屏蔽效果，但不考虑PRIMASK。当你在中断服务程序中，想知道是否有更高优先级的中断在排队等待，可以查看此字段。
• ISRPEND：这是一个快速检查位。如果为1，表示至少有一个中断（不包括NMI和故障）处于挂起状态。它比查询VECPEND更快捷。
• RETBASE：此位为1时，表示当前没有异常被抢占，或者当前执行的异常是唯一活跃的异常。这在判断中断嵌套深度时有用。

控制部分：

• PENDSVSET / UNPENDSV：这是RTOS的“命脉”。设置PENDSVSET位（写1）将使PendSV异常挂起。清除它则需要向UNPENDSV位写1。一个重要的硬件约束是：绝对不能同时向PENDSVSET和UNPENDSV写1，其结果不可预测。标准的RTOS上下文切换流程是：在SysTick（或其它定时器）中断中，进行任务调度决策，然后置位PENDSVSET，最后退出中断。由于PendSV优先级最低，它会等到所有中断处理完毕才执行。
• PENDSTSET / PENDSTCLR：类似地，用于设置和清除SysTick异常的挂起状态。通常，SysTick由硬件定时器自动置位，但软件也可以手动控制它。
• NMISET：用于设置NMI挂起状态。由于NMI是不可屏蔽的最高优先级异常，一旦置位，处理器会几乎立即响应（除非正在处理另一个NMI）。务必谨慎使用，通常用于指示最严重的系统错误。

实操心得：在调试时，我经常在调试器中监视INTCTRL寄存器的值。例如，当你发现系统似乎“卡住”了，可以检查VECACT。如果它一直显示某个中断的编号，很可能该中断服务程序陷入了死循环或者没有正确清除中断源。另外，在编写低功耗代码时，需要理解SEVONPEND位（在SYSCTRL寄存器）与中断挂起的关系，它决定了处于睡眠状态的CPU是否会被一个已禁用但已挂起的中断唤醒。

3. 中断优先级与向量表动态配置实战

Cortex-M3的强大之处在于其可配置的、基于优先级的抢占式中断系统。优先级不仅决定了中断之间的响应顺序，还与向量表的定位息息相关，这两者共同构成了异常响应的基础设施。

3.1 优先级分组（PRIGROUP）与嵌套规则

优先级的概念并非一个简单的数字比较。在Cortex-M3中，一个8位的优先级字段（见于NVIC的IP寄存器或SCB的系统优先级寄存器）被一个“二进制点”分割为两部分：组优先级（Group Priority）和子优先级（Subpriority）。这个分割点由应用中断与复位控制寄存器（APINT）中的PRIGROUP[10:8]字段控制。

为什么需要分组？分组机制提供了灵活的抢占与控制策略。只有组优先级更高的异常才能抢占当前正在执行的异常。如果两个异常的组优先级相同，则比较子优先级，子优先级高的先执行；如果连子优先级也相同，则比较它们的硬件中断编号，编号小的优先。子优先级不能引发抢占，它只决定在多个挂起的、同组优先级异常中的执行顺序。

APINT寄存器中的PRIGROUP字段定义了从优先级字节的哪一位开始是子优先级。例如：

• PRIGROUP = 0b000：所有位都是组优先级（抢占域），没有子优先级。这意味着任何优先级不同的中断都可以相互抢占，适合对响应时间要求极其苛刻，且中断服务程序都很简短的场景。
• PRIGROUP = 0b100（常见配置）：高4位[7:4]为组优先级，低4位[3:0]为子优先级。这提供了16个组优先级（但实际可编程的通常只有高几位有效，如16级中的8级）和16个子优先级。这是许多RTOS的默认选择，它为任务中断（高组优先级）和系统异常（如PendSV、SysTick，设置为低组优先级）提供了清晰的层次。

配置方法：修改PRIGROUP需要向APINT寄存器写入一个“钥匙”。你必须将0x05FA写入VECTKEY[31:16]字段，同时设置PRIGROUP值，这是一个原子操作。例如，在C语言中，通常通过宏或函数实现：

#define SCB_AIRCR (*(volatile uint32_t*)0xE000ED0C) // APINT寄存器地址 void SetPriorityGroup(uint32_t priGroup) { SCB_AIRCR = (0x05FA << 16) | (priGroup << 8); }

警告：优先级分组通常在系统初始化时，在使能任何中断之前设置一次，之后不应再更改。动态更改分组会导致系统中所有中断的抢占关系瞬间改变，可能引发难以调试的时序问题和竞态条件。

3.2 系统异常优先级配置（SYSPRI1-3）

除了外部中断，内核自身的系统异常（如内存管理故障、总线故障、SVCall、PendSV、SysTick等）也具有可配置的优先级。这些优先级通过SYSPRI1、SYSPRI2、SYSPRI3寄存器设置。

• SYSPRI1：配置内存管理故障（MEM）、总线故障（BUS）、用法故障（USAGE）的优先级。这些故障处理程序的优先级需要仔细考量。通常，它们会被设置为相对较高的优先级，以便及时捕获严重错误，但又不能高于NMI。
• SYSPRI2：配置SVCall（SVC）异常的优先级。SVC用于实现系统调用，从非特权模式进入特权模式。其优先级通常设置为中等。
• SYSPRI3：配置SysTick（TICK）、PendSV（PENDSV）和调试监视器（DEBUG）的优先级。这是RTOS配置的关键：SysTick作为系统心跳，通常设置为较高的组优先级（但低于关键硬件中断），以确保定时准确；而PendSV则被设置为最低的组优先级（例如0xFF），确保所有中断服务程序都执行完毕后，才进行耗时的上下文切换，从而最小化中断延迟。

配置示例：将PendSV和SysTick设置为最低和次低优先级。

// 假设优先级分组为4（0b100），即[7:4]为组优先级，[3:0]为子优先级 // 设置PendSV优先级为255 (0xFF， 最低) *((volatile uint8_t*)0xE000ED22) = 0xFF; // SYSPRI3的PENDSV字段（字节地址） // 设置SysTick优先级为224 (0xE0， 次低) *((volatile uint8_t*)0xE000ED23) = 0xE0; // SYSPRI3的TICK字段（字节地址）

注意这些寄存器是字节可访问的，你可以直接通过字节地址操作特定的优先级字段，避免读-修改-写整个寄存器带来的并发问题。

3.3 向量表重定位（VTABLE）与高级应用

默认情况下，Cortex-M3从地址0x00000000开始读取向量表。向量表的第一项是初始栈指针（MSP），第二项是复位向量。然而，在复杂的系统中，尤其是使用了Bootloader或动态加载功能的系统，我们可能需要将向量表重定位到其他内存区域（如SRAM或外部Flash）。

VTABLE寄存器（偏移0xD08）就是用于此目的。它包含两个关键字段：

• BASE：决定向量表位于代码区（0）还是SRAM区（1）。这影响了处理器对向量表地址的解读方式。
• OFFSET[28:8]：向量表的字节偏移地址。注意，偏移地址必须与向量表大小对齐。对于具有43个中断的LM3S1608，向量表有（16个系统异常 + 43个中断）= 59个条目，每个条目4字节，共236字节。手册要求对齐到256字节边界。因此，你设置的偏移值必须是0x100（256）的整数倍。

重定位场景与步骤：

1. Bootloader场景：Bootloader存放在Flash起始位置。它完成硬件初始化后，将用户应用程序的二进制代码（包含其向量表）拷贝到Flash的另一位置（如0x00002000），然后通过修改VTABLE寄存器将向量表偏移设置为0x2000，并跳转到用户程序的复位向量。
2. 动态更新中断服务程序：如果将向量表重定位到SRAM（设置BASE=1），则可以在运行时动态修改SRAM中的向量表条目，指向新的函数地址。这在实现动态插件或高级调试功能时非常有用。
3. 操作步骤：

   // 将向量表重定位到SRAM中的0x20000000地址 // 1. 计算偏移：目标地址 - 基地址。如果BASE=1（SRAM区），基地址是0x20000000吗？不，VTABLE的OFFSET是相对于0x00000000的偏移。 // 实际上，更常见的做法是直接设置VTABLE寄存器的值为目标地址，但需要确保对齐。 // 对于LM3S，通常直接写入目标地址的高24位（因为低8位必须为0）。 #define VTABLE_REG (*(volatile uint32_t*)0xE000ED08) uint32_t new_vector_table_addr = 0x20000000; // 假设SRAM起始地址 // 确保地址256字节对齐 if ((new_vector_table_addr & 0xFF) != 0) { // 处理错误 } VTABLE_REG = new_vector_table_addr; // 直接写入地址值 // 注意：在重定位向量表之前，必须确保目标地址处的向量表数据已经准备就绪。

避坑指南：

• 对齐是硬性要求：未对齐的向量表地址会导致硬件故障（Usage Fault或Hard Fault）。
• 时机至关重要：必须在中断使能之前完成向量表重定位。如果在中断活跃时修改VTABLE，下一个中断到来时可能会跳转到错误的地址，导致系统崩溃。
• 理解内存映射：清楚你的芯片的SRAM和Flash地址范围。将向量表重定位到不存在的或只读的地址会导致立即故障。

4. 系统控制与配置寄存器详解

这一组寄存器控制着处理器的基础行为模式、低功耗特性以及一些关键的调试和容错功能。它们虽然不直接参与频繁的中断调度，却是系统稳定运行的底层保障。

4.1 系统控制（SYSCTRL）与低功耗管理

SYSCTRL寄存器（偏移0xD10）主要管理处理器进入和退出低功耗模式的行为。

• SLEEPDEEP：此位决定处理器执行WFI（等待中断）或WFE（等待事件）指令时，是进入普通的睡眠模式（Sleep）还是深度睡眠模式（Deep Sleep）。普通睡眠仅停止处理器时钟，部分外设可能仍在运行；深度睡眠则会关闭更多时钟域和电源域，功耗更低，但唤醒时间更长。具体行为取决于芯片的具体实现。
• SLEEPEXIT：这是一个非常实用的位。当设置为1时，如果处理器因为中断而从处理器模式（Handler Mode）退出，返回到线程模式（Thread Mode）后，它会自动再次执行一条WFI指令，立即重新进入睡眠。这对于中断驱动的、没有主循环的应用程序非常有用。应用程序的主体就是一系列中断服务程序，当没有中断需要处理时，CPU会自动休眠，最大化节能。
• SEVONPEND：此位改变WFE指令的唤醒条件。当设置为1时，任何中断进入挂起状态（即使该中断被禁用）都会产生一个事件，唤醒因WFE而睡眠的CPU。这允许你使用中断的挂起机制作为一种“软件事件”来唤醒CPU，而不必实际使能并处理该中断。

低功耗设计模式：一个典型的高能效设计是：主循环中调用WFI，所有工作由中断处理。设置SLEEPEXIT=1可以确保中断处理完毕后立即返回睡眠。如果需要更复杂的多事件同步，可以使用WFE配合SEVONPEND或软件生成的SEV指令。

4.2 配置与控制（CFGCTRL）的高级功能

CFGCTRL寄存器（偏移0xD14）包含了一系列影响处理器核心行为的“开关”。

• STKALIGN：栈对齐控制。Cortex-M3的AAPCS（ARM架构过程调用标准）要求栈指针在函数调用时必须8字节对齐。异常入口时，处理器会自动检查并强制对齐栈指针。此位控制是否在异常入口时进行8字节对齐（1）还是保持4字节对齐（0）。通常必须设置为1，以符合标准并确保浮点单元（如果存在）或某些编译器优化代码的正确运行。
• BFHFNMIGN：忽略NMI和硬故障中的总线错误。这是一个高级调试功能，默认必须为0。当设置为1时，运行在优先级-1（硬故障）或-2（NMI）的处理程序中的加载/存储指令如果产生总线错误，将被忽略，而不会导致锁定（Lockup）。仅在一种情况下使用：当你需要在故障处理程序中主动探测有问题的内存或外设地址，以诊断系统故障原因时。使用后必须立即清除。
• DIV0和UNALIGNED：除零和未对齐访问陷阱。默认情况下，Cortex-M3进行除以零操作会返回0，未对齐的访问会被处理器硬件拆分（可能带来性能损失）。将这两个位置1，会使这些操作触发用法故障（Usage Fault）。在开发阶段强烈建议使能它们，这有助于快速捕获潜在的软件bug。在最终产品中，如果确认代码是安全的，为了性能可以考虑关闭未对齐访问陷阱，但除零陷阱通常建议保持开启。
• MAINPEND：如前所述，控制非特权代码对SWTRIG寄存器的访问。生产代码中保持为0。
• BASETHR：线程模式基础控制。控制处理器是否能从任何异常级别（通过特定的EXC_RETURN值）返回到线程模式。这涉及更高级的操作系统上下文管理，通常由RTOS内核在严格控制的条件下使用，裸机程序一般保持为0。

配置示例与顺序：

// 系统初始化早期配置CFGCTRL #define SCB_CCR (*(volatile uint32_t*)0xE000ED14) // CFGCTRL寄存器地址 // 使能除零和未对齐访问陷阱，强制8字节栈对齐 SCB_CCR |= (1 << 9) | (1 << 4) | (1 << 3); // 设置STKALIGN, DIV0, UNALIGNED位 // 注意：BFHFNMIGN, MAINPEND, BASETHR 通常保持为0 (复位值)

5. 系统故障诊断与状态寄存器实战指南

当系统发生异常行为，如跑飞、重启或进入硬故障时，SCB提供了一组强大的状态寄存器来帮助诊断根本原因。这是调试中最关键、最硬核的部分。

5.1 系统处理程序控制与状态（SYSHNDCTRL）

SYSHNDCTRL寄存器（偏移0xD24）有两个主要功能：启用/禁用可配置的故障处理程序，以及查询和手动设置系统异常的挂起/活跃状态。

启用故障处理程序：内存管理故障（MEM）、总线故障（BUS）、用法故障（USAGE）默认是禁用的！这意味着，如果这些故障发生，它们会自动升级为硬故障。硬故障是一个“最终捕获”机制，它告诉你出错了，但丢失了具体的错误类型信息。因此，在开发初期，我们应该使能这些可配置的故障处理程序，以获得更精确的错误报告。

#define SCB_SHCSR (*(volatile uint32_t*)0xE000ED24) // 使能所有可配置故障处理程序 SCB_SHCSR |= (1 << 16) | (1 << 17) | (1 << 18); // 使能 MEM, BUS, USAGE

状态位：该寄存器的低16位包含了各种系统异常的挂起（Pend）和活跃（Active）状态位。例如，BUSP位指示总线故障是否挂起，BUSA位指示总线故障处理程序是否正在执行。这些位可由软件读写。RTOS在进行复杂上下文切换或调试时，可能会用到这些位。但手册给出了严厉警告：在不正确调整栈内容的情况下修改活跃状态位，会导致处理器产生故障。除非你完全理解异常进入/退出时处理器对栈帧的操作，否则不要轻易写这些位。

5.2 可配置故障状态（FAULTSTAT）寄存器深度解读

FAULTSTAT寄存器（偏移0xD28）是故障诊断的“核心证据”。它是一个“写1清除”的寄存器，当发生内存管理、总线或用法故障时，相应的状态位会被硬件置1。在对应的故障处理程序中，读取此寄存器就能知道“到底发生了什么”。

寄存器结构：它分为三个子状态寄存器：

• 内存管理故障状态（MFAULTSTAT, bits [7:0]）：如指令访问违规（IERR）、数据访问违规（DERR）、栈访问违规（MSTKE,MUSTKE）。MMARV位指示内存管理故障地址寄存器（MMADDR）中的地址是否有效。
• 总线故障状态（BFAULTSTAT, bits [15:8]）：如指令总线错误（IBUS）、精确数据总线错误（PRECISE）、不精确数据总线错误（IMPRE）、栈总线错误（BSTKE,BUSTKE）。BFARV位指示总线故障地址寄存器（FAULTADDR）中的地址是否有效。“不精确”错误意味着错误地址可能与当前程序计数器（PC）无关，这通常与写缓冲或存储器系统有关，更难调试。
• 用法故障状态（UFAULTSTAT, bits [31:16]）：如未定义指令（UNDEF）、非法状态（INVSTAT，例如尝试修改EPSR的非法位）、无效的PC加载（INVPC）、尝试访问协处理器（NOCP）、未对齐访问（UNALIGNED，需CFGCTRL.UNALIGNED=1）和除零（DIV0，需CFGCTRL.DIV0=1）。

标准的故障处理程序流程：

1. 保存关键上下文：第一时间将关键寄存器（如R0-R3, LR, PC, PSR）保存到全局变量或特定内存区域，因为后续操作可能会覆盖它们。
2. 读取FAULTSTAT：获取故障类型。
3. 读取故障地址寄存器：但顺序很重要！必须先读取MMADDR或FAULTADDR的值，然后再检查MMARV或BFARV位。因为更高优先级的故障可能会抢占当前的故障处理程序，并覆盖这些地址寄存器。只有遵循“先读地址，后读有效位”的顺序，才能确保你保存的地址是本次故障的真实地址。
4. 分析信息：结合故障类型、故障地址、以及保存的PC和LR（链接寄存器，通常包含返回地址），可以精确定位出错的代码位置。例如，PRECISE错误且BFARV=1，那么FAULTADDR中的地址就是导致故障的读写操作地址，而栈帧中保存的PC就是那条故障指令的地址。
5. 清除状态位：向FAULTSTAT中对应的位写1以清除它们。这对于防止同一故障位被重复报告很重要。
6. 错误恢复或系统复位：根据错误的严重性，决定是尝试恢复（例如，修正一个可恢复的错误并返回），还是记录错误信息后执行系统软复位。

示例：一个简单的硬故障处理程序框架

__attribute__((naked)) void HardFault_Handler(void) { __asm volatile( "tst lr, #4\n\t" // 检查EXC_RETURN的位2，判断使用的是MSP还是PSP "ite eq\n\t" "mrseq r0, msp\n\t" // 如果使用MSP，将其存入R0 "mrsne r0, psp\n\t" // 如果使用PSP，将其存入R0 "b HardFault_Handler_C\n" // 跳转到C函数，R0作为参数（栈帧指针） ); } void HardFault_Handler_C(uint32_t* stack_frame) { uint32_t fault_status = SCB->CFSR; // CFSR是FAULTSTAT的别名（在CMSIS中） uint32_t fault_address; uint32_t pc = stack_frame[6]; // 从栈帧中提取PC uint32_t lr = stack_frame[5]; // 提取LR // 检查并处理内存管理故障 if (fault_status & (1 << 0)) { // IERR fault_address = SCB->MMFAR; // 读取MMADDR if (SCB->CFSR & (1 << 7)) { // MMARV有效 // 记录: 指令访问违规在地址 fault_address, PC=pc } SCB->CFSR |= (1 << 0); // 清除IERR位 (写1清除) } // 检查总线故障、用法故障... (类似处理) // 检查是否为不可恢复的错误，例如非法的PC值 if ((fault_status & (1 << 7)) && (fault_status & (1 << 16))) { // INVPC & UNDEF? 示例组合 // 严重错误，记录后系统复位 NVIC_SystemReset(); } // 对于某些可恢复错误，可以尝试修复并返回，但需极其小心 while(1); // 通常，硬故障是致命的，在此循环或复位 }

避坑与调试技巧：

• 优先使能详细故障：确保在开发阶段使能MEM、BUS、USAGE故障，并开启DIV0和UNALIGNED陷阱，让问题尽早暴露。
• 理解“锁定”状态：如果处理器在处理NMI或硬故障时再次发生故障，它会进入“锁定”状态，停止执行指令。此时只能通过外部复位恢复。BFHFNMIGN位可以临时用于在故障处理程序中避免因访问故障地址而导致的锁定。
• 栈溢出是常见故障源：MSTKE或BSTKE错误通常意味着栈溢出。检查你的栈大小分配，并考虑使用MPU（内存保护单元）来设置栈区域的写保护，在栈溢出时立即触发内存管理故障，而不是破坏其他数据。
• 利用调试器：现代IDE（如Keil MDK, IAR EWARM, STM32CubeIDE）都能在发生故障时自动暂停，并展示CFSR（FAULTSTAT）、HFSR（硬故障状态）、MMFAR、BFAR等寄存器的值，极大简化了初步诊断。但理解这些寄存器背后的含义，能让你在调试器无法直接连接时（如现场问题），通过日志系统记录的信息进行有效分析。