1. Cortex-M4异常处理机制的核心价值与设计哲学

在嵌入式系统开发，尤其是基于ARM Cortex-M4这类高性能微控制器的项目中，异常处理机制的设计与调试能力，往往是区分资深工程师与初学者的关键分水岭。很多开发者对异常的理解停留在“中断”层面，认为配置好NVIC（嵌套向量中断控制器）就万事大吉，但实际上，Cortex-M架构将“异常”作为一个更广义的概念，它涵盖了从硬件错误到软件系统调用的所有非顺序执行流。而系统处理程序（System Handlers）的管理，则是这套机制中最精细、也最容易出问题的部分。

为什么需要SYSPRI和SYSHNDCTRL这样的专用系统寄存器？想象一下，你的系统正在执行一个关键的电机控制算法，此时突然发生了内存访问越界（总线故障），同时一个后台的SysTick定时器也触发了。处理器该先处理哪个？如果内存故障处理不及时，可能导致数据污染，进而引发更严重的系统崩溃；但如果SysTick被无限期延迟，你的实时任务调度就会出问题。这就是优先级仲裁要解决的问题。而SYSHNDCTRL寄存器，则像是一个异常系统的“总开关”和“状态监视器”，它决定了哪些异常可以被响应，以及当前异常处于何种状态（挂起、激活中）。

这套机制的技术价值，直接体现在系统的“韧性”上。一个配置得当的异常处理系统，能够将潜在的致命错误（如非法指令、除零操作）转化为可诊断、可恢复的故障事件，并通过预设的优先级，确保最关键的处理程序优先获得CPU资源。这对于工业自动化、汽车电子、医疗设备等不允许“死机”的领域至关重要。本文将深入拆解SYSPRI1/2/3和SYSHNDCTRL这两个关键寄存器组，不仅告诉你每个比特位是什么，更会结合我多年调试经验，解释在什么场景下配置、如何配置，以及配置不当会引发哪些“诡异”的、数据手册上不会写的坑。

2. 系统处理程序优先级寄存器（SYSPRI）深度解析与配置策略

SYSPRI寄存器组是Cortex-M4异常优先级体系的“调度中心”。与NVIC管理的外设中断不同，SYSPRI专门管理内核级别的系统异常。理解它的工作方式，是构建可靠异常处理框架的第一步。

2.1 SYSPRI寄存器组概览与访问特性

Cortex-M4将系统异常优先级配置分散在三个寄存器中：SYSPRI1, SYSPRI2, SYSPRI3。它们都位于系统控制块（SCB）的地址空间，基址为0xE000E000。一个至关重要的前提是：这些寄存器只能在处理器处于特权模式下访问。在用户模式（非特权模式）下尝试写入，将触发一个用法故障（UsageFault）。这是硬件层面的一个安全设计，防止用户应用程序随意篡改系统异常的行为，从而破坏整个系统的稳定性。

这三个寄存器都是32位宽，但实际用于配置优先级的位域只有3位（bit[2:0]或类似），对应优先级0-7。这里有一个关键概念：数值越小，优先级越高。优先级0是最高优先级（但通常保留，不用于可配置异常），优先级7是最低优先级。这种设计意味着，当你将某个异常的优先级设置为0时，它将能抢占几乎所有其他异常（除了不可屏蔽的HardFault等）。

寄存器支持按字节访问，这为编程提供了灵活性。例如，你可以只修改用法故障的优先级，而不影响同在一个寄存器中的总线故障优先级。在C代码中，我们通常通过CMSIS-Core提供的标准宏来访问，例如SCB->SHP[0]对应SYSPRI1，SCB->SHP[1]对应SYSPRI2，SCB->SHP[2]对应SYSPRI3。但理解其底层内存映射，对于调试和阅读底层启动代码至关重要。

2.2 SYSPRI1：内存、总线与用法故障的优先级仲裁

SYSPRI1（偏移量0xD18）管理着三个最关键的硬件故障异常：

• MEM (位[7:5])：存储器管理故障（MemManage Fault）优先级。当MPU（内存保护单元）启用后，访问违反MPU区域规则（如向只读区域写入、从不可执行区域取指）会触发此异常。在无MPU的芯片上，访问XN（永不执行）标记的内存区域也会触发。
• BUS (位[15:13])：总线故障（BusFault）优先级。通常由总线上的错误响应引起，例如访问一个不存在的物理地址、访问未初始化的外部存储器、或违反某些总线的访问规则（如向只读外设寄存器写入）。
• USAGE (位[23:21])：用法故障（UsageFault）优先级。这是一个“兜底”的软件相关故障，原因多样，包括执行未定义指令、非法的异常返回、除零操作（需额外使能）、未对齐的内存访问（需额外使能）等。

配置策略与实战经验：这三个故障的默认优先级都是0（最高）。但在实际系统中，我们往往需要调整它们的相对优先级。一个常见的策略是：将总线故障设为最高，存储器管理故障次之，用法故障最低。为什么？

总线故障通常意味着严重的硬件访问错误，可能立即导致数据总线挂死或外设响应异常，需要最快响应。存储器管理故障虽然也严重，但有时可能是软件误操作触发了MPU保护，其紧急性略低于总线物理错误。用法故障多由软件bug引起，其紧急性相对最低。例如，你可以这样配置：

// 设置总线故障优先级为1（很高，但为HardFault留出空间） SCB->SHP[0] = (SCB->SHP[0] & ~(0xFFUL << 13)) | (1UL << 13); // 设置存储器管理故障优先级为2 SCB->SHP[0] = (SCB->SHP[0] & ~(0xFFUL << 5)) | (2UL << 5); // 设置用法故障优先级为3 SCB->SHP[0] = (SCB->SHP[0] & ~(0xFFUL << 21)) | (3UL << 21);

注意：对SYSPRI寄存器的写操作必须是原子的“读-修改-写”过程。上面的代码片段中，& ~和|操作确保了只修改目标位域，不影响其他位。直接赋值（如SCB->SHP[0] = 0x00200000;）是危险操作，会清零其他所有配置。

2.3 SYSPRI2与SYSPRI3：系统服务与定时异常的优先级管理

SYSPRI2（偏移量0xD1C）目前只管理一个异常：SVC（位[31:29]），即超级调用（Supervisor Call）。这是RTOS（实时操作系统）或任何分特权级软件实现系统调用的核心机制。应用程序在用户模式下通过执行SVC指令，可以触发一个异常，从而陷入到特权模式下的操作系统内核中执行特定服务。SVC的优先级需要仔细考量：它必须高于普通任务（线程），但又不能太高，以免影响对硬件故障的响应。通常，我会将其设置为一个中等偏上的优先级，比如4或5。

SYSPRI3（偏移量0xD20）管理三个与系统调度和调试相关的异常：

• DEBUG (位[7:5])：调试监视器（Debug Monitor）优先级。当使用基于软件的调试（如半主机、数据观察点）时，该异常会被触发。其优先级通常设置为最低（如7），因为调试行为不应干扰正常的程序执行和更高优先级的故障处理。
• PENDSV (位[23:21])：可挂起的系统调用（PendSV）优先级。这是RTOS上下文切换的“主力军”。RTOS的调度器（如SysTick）会触发一个PendSV异常，但该异常被设计为“可挂起的”，意味着它会在所有更高优先级中断处理完成后才执行。因此，PENDSV的优先级必须设置为整个系统中最低的（通常是7），以确保任何实时中断都能抢占上下文切换过程，保证系统的实时性。
• TICK (位[31:29])：SysTick异常优先级。这是系统节拍定时器的中断。在RTOS中，它负责提供时间片，驱动任务调度。它的优先级需要高于PendSV，但低于或等于SVC和其他关��硬件中断。一个典型的设置是将其优先级设为中等级别（如4），高于PendSV但低于关键外设中断。

一个典型的RTOS优先级配置示例：

// SYSPRI2: 设置SVC调用优先级为4 SCB->SHP[1] = (SCB->SHP[1] & ~(0xFFUL << 29)) | (4UL << 29); // SYSPRI3: 设置SysTick优先级为4， PendSV优先级为7， Debug优先级为7 uint32_t syspri3_val = 0; syspri3_val |= (4UL << 29); // TICK = 4 syspri3_val |= (7UL << 21); // PENDSV = 7 (最低) syspri3_val |= (7UL << 5); // DEBUG = 7 (最低) SCB->SHP[2] = syspri3_val;

这个配置确保了：硬件故障 > SVC系统调用 ≈ SysTick > 普通外设中断 > PendSV上下文切换。这样的层次关系是保证一个RTOS既能及时响应外部事件，又能进行平滑任务切换的基础。

3. 系统处理程序控制及状态寄存器（SYSHNDCTRL）精讲与实战应用

如果说SYSPRI是“调度规则”，那么SYSHNDCTRL（偏移量0xD24）就是异常系统的“运行控制面板”和“状态显示屏”。这个寄存器功能复杂，位域众多，但可以清晰地分为两大类功能：使能控制和状态标志。

3.1 系统处理程序的使能与禁用：一把双刃剑

SYSHNDCTRL的高三位（位18, 17, 16）分别控制着用法故障（USAGE）、总线故障（BUS）和存储器管理故障（MEM）的使能。复位后，这些位默认为0，即这些可配置的故障处理程序是被禁用的！这是一个非常重要的细节。

如果禁用了某个故障处理程序（如USAGE），当对应的故障（如除零）发生时，处理器会怎么做？答案在数据手册的警告中：它会自动升级为硬故障（HardFault）。HardFault是不可屏蔽、优先级最高的异常。这意味着，一个本可以被精细捕获和处理的软件小错误（如除零），会直接导致系统陷入最严重的错误处理流程。在某些对可靠性要求极高的场景，开发者可能会故意禁用某些故障，让所有问题都汇聚到HardFault中统一进行最保守的处理（如系统复位）。但在大多数调试和开发阶段，我们必须使能这些故障，以便获得更精确的错误定位信息。

使能操作很简单：

// 使能用法故障、总线故障、存储器管理故障 SCB->SHCSR |= SCB_SHCSR_USGFAULTENA_Msk | SCB_SHCSR_BUSFAULTENA_Msk | SCB_SHCSR_MEMFAULTENA_Msk;

重要提示：使能这些故障后，你必须提供相应的异常处理函数（例如void MemManage_Handler(void)），并在其中实现有效的处理逻辑（至少是错误信息捕获）。否则，一旦触发故障而你的处理函数是空的，程序将陷入无限循环或产生不可预知的行为。

3.2 挂起与激活状态：深入异常处理的内核

这是SYSHNDCTRL寄存器最精妙也最危险的部分。它包含了多组“挂起（Pend）”和“激活（Active）”状态位。

• 挂起状态位（如SVC, BUSP, MEMP, USAGEP）：表示该异常已被触发，正在等待处理器响应。当异常事件发生（如执行SVC指令、总线出错），硬件会自动置位对应的挂起位。软件也可以写这些位来手动挂起一个异常。例如，在RTOS中，调度器可以通过写PendSV的挂起位（在NVIC中，而非SYSHNDCTRL）来请求一次上下文切换。SYSHNDCTRL中的SVC挂起位（位15）则允许软件模拟一个SVC调用。
• 激活状态位（如SVCA, MEMA, BUSA, USGA, TICK, PNDSV）：表示处理器正在执行该异常的处理程序。当处理器响应该异常，开始执行其处理函数的第一条指令时，硬件会置位对应的激活位。当异常处理函数返回（执行BX LR或POP {PC}）时，硬件会清除该激活位。

软件可以修改激活位，但这极其危险！数据手册用“小心（Caution）”来警告。为什么？因为异常激活位与处理器的硬件状态机紧密耦合。例如，如果你在SVC处理函数中清除了自己的SVCA位，处理器可能会认为SVC处理已经结束，从而错误地执行异常返回，导致栈和程序计数器（PC）状态混乱，几乎必然引发新的故障。

那么，什么情况下会需要修改激活位呢？一个高级用法是在操作系统的上下文切换中。例如，从一个异常处理程序中（此时该异常的激活位为1）手动触发一个PendSV（通过置位其挂起位），并在PendSV处理函数中，通过修改前一个异常的激活位和PendSV自身的激活位，来实现复杂的嵌套异常状态管理。但这需要开发者对Cortex-M的异常压栈、出栈机制有极其深刻的理解，并且要极其小心地保存和恢复上下文。对于绝大多数应用，我的建议是：不要手动读写任何激活状态位。把它们当作只读的状态标志来查询即可。

3.3 安全操作指南与常见陷阱

操作SYSHNDCTRL寄存器必须遵循“读-修改-写”原则，以确保不意外修改其他位。CMSIS库函数通常已经封装好了安全的位操作。

一个常见的陷阱是使能了故障，但未提供完整信息。例如，你使能了总线故障，并在处理函数中读取总线故障地址寄存器（FAULTADDR）。但是，你必须先检查BFAULTSTAT子寄存器中的BFARV位，确认FAULTADDR中的地址是有效的。因为并非所有总线故障都能提供准确的故障地址（例如，在异常入栈/出栈过程中发生的故障）。

另一个陷阱是优先级配置与使能顺序。理论上，配置优先级和使能处理程序的顺序没有严格规定。但一个良好的实践是：先配置优先级，再使能处理程序。这样可以避免在配置过程中，万一有故障发生，系统会按照你预设的优先级去处理，而不是默认值。

4. 可配置故障状态寄存器（FAULTSTAT）的故障诊断实战

当系统异常处理函数被调用时，第一要务不是立刻尝试恢复，而是诊断。FAULTSTAT寄存器（偏移量0xD28）就是你的“故障诊断仪”。它将用法、总线、内存管理故障的具体原因细分成了数十个状态位。

4.1 寄存器结构与访问方式

FAULTSTAT是一个32位寄存器，但逻辑上分为三个8位或16位的子寄存器：

• MFAULTSTAT (位[7:0])：存储器管理故障状态。包含指令/数据访问违规、入栈/出栈违规等标志。
• BFAULTSTAT (位[15:8])：总线故障状态。包含指令/数据总线错误、精确/不精确错误、入栈/出栈错误等标志。
• UFAULTSTAT (位[31:16])：用法故障状态。包含未定义指令、非法状态、无效PC、无协处理器、未对齐访问、除零等标志。

这些位都是“写1清零”（W1C）。这意味着在故障处理函数中，为了确认故障原因并清除标志位，你应该先读取寄存器的值保存到变量中，然后再将读到的值写回寄存器，从而清除那些置位的标志。切忌直接写0或写全1来清除，那样可能会意外设置其他位或无效操作。

4.2 故障诊断流程与代码实现

一个健壮的故障处理函数应该遵循以下诊断流程，这里以总线故障处理函数为例：

void BusFault_Handler(void) { // 1. 立即保存关键的故障上下文（可选，用于高级调试） // __asm volatile("MRS r0, MSP\n\t" "STM r0!, {r4-r11}\n\t" ... ); // 2. 读取并保存故障状态和地址（顺序很重要！） uint32_t fault_status = SCB->CFSR; // CFSR包含了FAULTSTAT等信息 uint32_t bus_fault_addr = SCB->BFAR; // 总线故障地址 // 3. 解析BFAULTSTAT子寄存器（位于CFSR的位[15:8]） uint8_t bfsr = (fault_status >> 8) & 0xFF; // 4. 判断故障地址是否有效 if (bfsr & (1 << 7)) { // 检查BFARVALID位（BFSR bit7） // BFAR中地址有效，打印或记录这个地址 // 例如：printf("BusFault at address: 0x%08lX\n", bus_fault_addr); } else { // BFAR中地址无效，故障可能发生在栈操作或是不精确错误 // 例如：printf("BusFault, no valid address.\n"); } // 5. 分析具体故障原因 if (bfsr & (1 << 0)) { // IBUSERR: 指令总线错误 // 可能是从非代码区（如XRAM）取指 } if (bfsr & (1 << 1)) { // PRECISERR: 精确数据总线错误 // 精确的读写错误，BFAR通常有效，PC指向导致错误的指令 } if (bfsr & (1 << 2)) { // IMPRECISERR: 不精确数据总线错误 // 异步错误，常见于带写缓冲的存储器访问，PC可能不指向源头 // 这是最难调试的错误之一 } if (bfsr & (1 << 3)) { // UNSTKERR: 异常出栈时的总线错误 // 从异常返回时，出栈过程中发生错误 } if (bfsr & (1 << 4)) { // STKERR: 异常入栈时的总线错误 // 进入异常时，入栈过程中发生错误，可能栈指针(SP)非法或栈内存不可写 } if (bfsr & (1 << 5)) { // LSPERR: 浮点惰性栈保存时的总线错误 // 与浮点单元(FPU)相关，发生在惰性栈保存机制中 } // 6. 清除故障标志位（写1清零） // 注意：只清除BFSR部分，避免影响UFSR和MMFSR SCB->CFSR = (bfsr << 8); // 将读取的BFSR值写回对应位域 // 7. 错误恢复或系统复位 // 对于不可恢复错误，最好进行系统复位 // NVIC_SystemReset(); while (1) { // 或者死循环，等待看门狗复位 // 在实际产品中，应有更安全的恢复策略 } }

关键点解析：

1. 读取顺序：必须先读取BFAR，再检查BFARVALID位。因为一个更高优先级的异常（如NMI）可能会抢占当前的故障处理，并覆盖BFAR寄存器。
2. 不精确错误（IMPRECISERR）：这是调试的噩梦。因为它可能发生在写缓冲（Write Buffer）中，当CPU继续执行后续指令时，这个错误才被报告，导致程序计数器（PC）早已离开了出错点。排查这类错误，需要检查最近进行的所有存储器写操作，尤其是对外部存储器的操作。
3. 栈错误（UNSTKERR/STKERR）：这是系统崩溃的常见原因。通常意味着栈指针（SP）跑飞到了非法内存区域（例如，栈溢出破坏了堆区，或者野指针修改了SP）。处理函数中应避免使用大量局部变量或调用其他函数，以免加重栈负担。

4.3 用法故障与存储器管理故障的特定标志

• 用法故障（UFAULTSTAT）：

  • UNDEFINSTR：执行了CPU无法解码的指令。可能是数据被错误地当作指令执行（PC跑飞），或链接了错误的库。
  • INVSTATE：企图非法使用EPSR寄存器。例如，尝试用BX或POP指令跳转到Thumb指令集的代码，但目标地址的LSB（最低有效位）不是1（Thumb状态要求LSB=1）。
  • INVPC：非法的异常返回。从异常返回时，加载到PC的值不是合法的EXC_RETURN值。
  • NOCP：尝试访问不存在的协处理器（如FPU未使能时使用浮点指令）。
  • UNALIGNED：未对齐的内存访问（需在CCR寄存器中使能）。
  • DIVBYZERO：整数除零（需在CCR寄存器中使能）。

• 存储器管理故障（MFAULTSTAT）：

  • IACCVIOL：指令访问违规。从标记为“永不执行（XN）”的内存区域取指。
  • DACCVIOL：数据访问违规。违反MPU规则进行数据读写（如向只读区域写）。
  • MUNSTKERR/MSTKERR：类似总线故障，是在异常出栈/入栈时发生的MPU违规。

理解这些标志位，能让你在调试时快速定位问题根源。例如，如果看到INVSTATE，首先检查异常返回地址或函数指针；如果看到DACCVIOL，则检查MPU配置或数组越界。

5. 综合配置示例与高级调试技巧

将SYSPRI、SYSHNDCTRL和FAULTSTAT的知识结合起来，我们可以构建一个完整的系统异常初始化函数。

5.1 完整的系统异常初始化代码

void SystemException_Init(void) { // 1. 配置系统异常优先级 // 注意：使用CMSIS宏确保原子性和可移植性 // 设置总线故障优先级为1（最高之一） NVIC_SetPriority(BusFault_IRQn, 1); // 设置存储器管理故障优先级为2 NVIC_SetPriority(MemoryManagement_IRQn, 2); // 设置用法故障优先级为3 NVIC_SetPriority(UsageFault_IRQn, 3); // 设置SVC调用优先级为4 NVIC_SetPriority(SVCall_IRQn, 4); // 设置SysTick优先级为4（与SVC同级或根据需求调整） NVIC_SetPriority(SysTick_IRQn, 4); // 设置PendSV优先级为7（最低） NVIC_SetPriority(PendSV_IRQn, 7); // 设置调试监视器优先级为7（最低） NVIC_SetPriority(DebugMonitor_IRQn, 7); // 2. 使能可配置的故障异常 // 使能后，对应的故障将触发自己的处理程序，而不是直接升级为HardFault SCB->SHCSR |= SCB_SHCSR_MEMFAULTENA_Msk // 使能存储器管理故障 | SCB_SHCSR_BUSFAULTENA_Msk // 使能总线故障 | SCB_SHCSR_USGFAULTENA_Msk; // 使能用法故障 // 3. （可选）使能用法故障的更多检测功能 // 在CCR（配置与控制寄存器）中使能除零和未对齐访问陷阱 SCB->CCR |= SCB_CCR_DIV_0_TRP_Msk // 使能除零陷阱 | SCB_CCR_UNALIGN_TRP_Msk; // 使能未对齐访问陷阱 // 注意：使能UNALIGN_TRP可能会影响性能，因为所有未对齐访问都会触发异常， // 而默认情况下，Cortex-M4硬件支持非原子性的未对齐访问（但较慢）。 // 4. 清除所有可能遗留的故障状态标志位 SCB->CFSR = SCB->CFSR; // 写1清零所有CFSR中的位 // 清除硬故障状态寄存器（HFSR）中的可写位 SCB->HFSR = SCB_HFSR_DEBUGEVT_Msk | SCB_HFSR_FORCED_Msk | SCB_HFSR_VECTTBL_Msk; // 5. 初始化故障处理函数（确保它们被正确链接） // 通常是在启动文件或向量表中定义弱符号，此处确保有强符号覆盖 }

5.2 高级调试技巧与问题排查实录

问题一：系统偶尔死机，最终陷入HardFault，但CFSR中信息混乱或全零。

• 排查思路：
  1. 检查栈溢出：这是最常见的原因。栈指针（MSP或PSP）损坏会导致异常入栈失败，从而在故障处理函数本身都无法正确执行。使用调试器查看MSP/PSP的值是否在预期的栈内存范围内。可以给栈区域填充特定的模式（如0xDEADBEEF），运行一段时间后检查是否被修改。
  2. 检查优先级配置：确认是否错误地将某个关键故障（如总线故障）的优先级设得过低，导致它被其他中断长时间阻塞，最终可能以某种形式升级。确保HardFault、NMI的优先级不可配置且为最高。
  3. 检查使能顺序：确保在使能故障处理程序之前，其处理函数已经就绪（函数指针有效）。如果在使能之后才设置向量表，可能会触发故障并跳转到错误地址。

问题二：精确总线故障（PRECISERR）地址有效，但代码看起来完全正常。

• 排查思路：
  1. 检查内存映射：确认你访问的地址在芯片的内存映射中是有效的。例如，试图写入芯片保留的地址空间或未初始化的外部SDRAM控制器。
  2. 检查外设时钟：访问一个外设寄存器前，必须确保该外设的时钟已经使能。访问一个时钟被禁用的外设模块，通常会引发总线错误。
  3. 检查对齐：虽然Cortex-M4支持非对齐访问，但某些特定外设寄存器（如某些DMA描述符）可能要求严格对齐。使用指针强制类型转换时要特别小心。
  4. 使用数据观察点：如果故障地址是变量地址，在调试器中对该地址设置数据写观察点（Data Watchpoint），可以捕捉到是哪里修改了它。

问题三：不精确总线故障（IMPRECISERR）随机发生，难以复现。

• 排查思路：
  1. 排查DMA或其它总线主设备：不精确错误常由DMA、以太网、USB等总线主设备引发，因为它们异步于CPU核心。检查这些外设的配置，特别是源/目标地址和传输长度。
  2. 检查存储器时序：如果故障地址指向外部存储器（如SDRAM、QSPI Flash），可能是存储器接口的时序配置（如等待状态、建立保持时间）过于紧张，在高温或低压下出现偶发错误。
  3. 关闭写缓冲：作为调试手段，可以尝试关闭CPU的写缓冲（在ACTLR寄存器中）。这会使所有写操作变为同步，不精确错误会转化为精确错误，但会极大降低性能。仅用于定位问题。
  4. 审查中断与主程序的共享数据：不精确错误也可能是内存访问冲突的间接表现。确保对共享变量的访问有适当的保护（关中断、信号量等）。

问题四：用法故障（INVPC或INVSTATE）在上下文切换或函数指针调用时发生。

• 排查思路：
  1. 检查EXC_RETURN值：INVPC通常意味着从异常返回时加载了错误的EXC_RETURN值。确保你的上下文保存/恢复代码（通常是汇编）正确无误，没有破坏LR寄存器中的EXC_RETURN值。
  2. 检查Thumb状态：Cortex-M只支持Thumb指令集。所有函数地址和跳转目标的LSB必须为1。如果你通过函数指针调用，或者从数组（如跳转表）中加载地址，务必确保地址的LSB是1。一个常见错误是将一个纯数据地址（LSB为0）赋给函数指针并调用。
  3. 检查栈帧：在上下文切换或中断嵌套时，栈帧被意外破坏可能导致异常返回时加载了错误的数据到PC。使用调试器检查异常发生前的栈内存内容。

掌握这些寄存器的细节，并配合系统的调试方法，你就能从被动的“救火队员”转变为主动的“系统医生”，不仅能快速定位问题，更能通过合理的配置预防许多潜在的系统崩溃风险。嵌入式系统的可靠性，正是建立在这样一层层精细而坚实的异常处理机制之上。