ARM Cortex-R异常向量表SRAM重定位：多应用场景下的动态异常处理方案-开发者社区

1. 项目概述

在嵌入式系统开发，尤其是基于ARM Cortex-R这类高性能、高可靠性内核的微控制器项目中，异常向量表的设计往往是系统架构的基石。它决定了当CPU遇到复位、未定义指令、数据中止等关键事件时，第一条指令该跳向何方。对于像TI Hercules系列这样面向功能安全应用的MCU，传统的做法是将这张表固化在Flash的起始地址（0x00000000）。这在单一应用固件中运行良好，但当我们面对更复杂的场景，比如一个系统需要同时容纳Bootloader、主应用程序（App）甚至一个安全备份固件（Fallback App）时，固化的向量表就成了绊脚石——每个应用都希望用自己的异常处理程序来接管系统。

这就引出了我们今天要深入探讨的核心技术：将异常向量表从Flash动态重定位到SRAM中。这不仅仅是把数据从一个地方搬到另一个地方那么简单，它涉及到CPU异常处理机制的底层原理、内存映射的巧妙利用、链接器脚本的精细控制，以及如何在系统启动的混沌初期确保一切稳定。我曾在多个涉及安全启动和双固件冗余的Hercules项目中实践过这项技术，它成功解决了多应用间异常处理程序“争抢”向量表入口的问题，让系统架构变得更加清晰和灵活。接下来，我将结合TI官方应用报告SPNA236的核心思想，并融入大量一线开发中的实操细节、避坑经验和原理剖析，为你完整呈现这项技术的实现全景。

2. 核心需求与方案选型背后的逻辑

为什么非要把向量表挪到SRAM里？这得从实际工程需求说起。假设你正在设计一个汽车电控单元（ECU），它可能包含以下部分：

Bootloader：负责程序更新、完整性校验和应用程序跳转。
主应用程序：实现ECU的核心控制功能。
安全备份/最小功能固件：当主应用程序失效时，提供一个基本的“跛行回家”功能。

这三个部分在物理上是独立的镜像，但运行在同一颗MCU上。它们都可能产生异常（例如，主App运行时的数据访问错误，或Bootloader在编程Flash时触发的预取指中止）。如果向量表固定在Flash，那么只能有一个镜像的异常处理程序能被“注册”到向量表入口。其他镜像运行时，如果发生异常，CPU还是会跳转到Flash中那个固定的处理程序，这很可能不属于当前正在运行的镜像，导致系统行为错乱甚至崩溃。

因此，核心需求是：让当前正在运行的应用程序能够动态地将自己的异常处理程序注册到CPU的异常向量入口。

2.1 方案对比与选型理由

面对这个需求，我们有几个潜在的方案，每个都有其优缺点：

方案一：使用CPU的HIVECS（高向量）特性一些ARM处理器支持将异常向量表重映射到地址0xFFFF0000。这听起来很理想，但根据TI文档明确指出，Hercules系列的Cortex-R内核没有在HIVECS地址实现物理内存。这意味着这个硬件特性对我们不可用，是首先需要排除的选项。

方案二：内存交换（Memory Swap）Hercules的存储控制器支持将Flash和SRAM的地址空间进行交换，即让SRAM出现在地址0x0。这确实能瞬间让向量表“位于”SRAM。但这个方案会彻底改变系统的内存映射，所有对Flash的访问地址都会发生变化，这通常需要极其谨慎地调整链接器脚本和启动代码，并且可能引入其他意想不到的兼容性问题（例如，某些硬件模块固定访问特定地址）。因此，除非有非常强烈的理由（如特定安全认证要求），否则不推荐作为首选。

方案三：软件重定向（本文详述的方案）这是最灵活、侵入性最小的方案。其核心思想是：在Flash的原始向量表位置（0x0）放置一个“跳转表”，这个跳转表里的指令不是直接跳转到最终的处理函数，而是跳转到SRAM中的一个“二级向量表”。二级向量表的内容则可以在运行时由应用程序动态修改。这样，Flash中的代码是静态且通用的，而SRAM中的向量表是动态且专属于当前应用的。

为什么选择方案三？

灵活性最高：每个应用程序（Bootloader, App）只需在初始化时，将自己的异常处理函数地址写入SRAM中的二级向量表即可。
对内存映射影响最小：Flash和SRAM的原始地址关系保持不变，系统其他部分无需做大的调整。
实现可控：整个过程由软件完全控制，便于调试和验证。
资源消耗明确：仅需在SRAM中开辟一小块固定区域（例如32字节）存放二级向量表，开销极小。

在方案三内部，还有两种具体的指令实现方式，这直接关系到代码的效率和可靠性。

2.2 指令级实现：LDR PC vs. B指令

在ARM指令集中，跳转主要有两种方式：B（分支）指令和LDR PC, ...（加载程序计数器）指令。

B指令的局限性：B指令是PC相对跳转，其偏移量字段只有24位，意味着跳转范围约为±32MB。在Hercules典型的存储器映射中，Flash起始于0x0，而SRAM起始于0x08000000，两者相距超过128MB，远超B指令的跳转范围。链接器在发现这种“长跳转”时，会自动插入一段“蹦床”代码来实现跳转。这会带来两个问题：一是增加了额外的指令周期，影响异常响应速度；二是每个向量入口都需要一个蹦床，增加了Flash占用和复杂度。
LDR PC指令的优势：LDR PC, [PC, #offset]这条指令可以从一个相对于PC的地址加载一个32位的绝对地址到PC寄存器。这个32位地址可以指向内存空间的任何位置，完美解决了远距离跳转的问题。更重要的是，它不需要链接器生成额外的蹦床代码，执行路径更直接，效率更高。因此，使用LDR PC指令是实现从Flash向量表跳转到SRAM二级向量表的最优选择。

所以，我们最终的方案架构确定为：在Flash的0x0地址处，使用LDR PC指令指向一个紧跟在向量表后面的地址表，该地址表存放着SRAM中二级向量表的入口地址。而SRAM中的二级向量表，同样使用LDR PC指令，指向最终由应用程序定义的异常处理函数。这样就形成了一个两级跳转机制，第一级在Flash中固定不变，第二级在SRAM中动态可调。

3. 技术实现细节与汇编代码解析

理解了整体架构，我们深入到代码层面。这里以处理“未定义指令异常”（Undefined Instruction）和“软件中断指令异常”（SVC/SWI）为例，详细拆解每一行汇编代码的作用和原理。

3.1 Flash中的一级向量表（.intvecs段）

这个段必须通过链接器脚本固定链接到地址0x0。它的内容不再是直接跳转到_c_int00或Abort_Handler，而是变成了跳转指令。

.sect ".intvecs" .retain ".intvecs" .arm resetEntry: b _c_int00 ; 1. 复位向量，必须直接跳转到启动代码 undefEntry: ldr pc, tab_undef ; 2. 未定义指令异常：加载PC，跳转到tab_undef存储的地址 svcEntry: ldr pc, tab_swi ; 3. 软件中断异常：加载PC，跳转到tab_swi存储的地址 prefetchEntry: ldr pc, tab_pref ; 4. 预取指中止异常 dabtEntry: ldr pc, tab_dabt ; 5. 数据中止异常 phantomEntry: b phantomEntry ; 6. 保留向量（Cortex-R4/R5），原地循环 irqEntry: ldr pc,[pc,#-0x1b0] ; 7. IRQ中断，从VIM模块加载向量地址（硬件固定） fiqEntry: ldr pc,[pc,#-0x1b0] ; 8. FIQ中断，从VIM模块加载向量地址（硬件固定） ; --- 紧随向量表之后的地址表 --- tab_undef: .word ram_undef ; 存放SRAM中‘ram_undef’标签的地址 tab_swi: .word ram_swi ; 存放SRAM中‘ram_swi’标签的地址 tab_pref: .word ram_pref ; 存放SRAM中‘ram_pref’标签的地址 tab_dabt: .word ram_dabt ; 存放SRAM中‘ram_dabt’标签的地址

代码解读与注意事项：

复位向量（resetEntry）：必须保持为直接的b _c_int00分支。因为上电或复位后，SRAM内容未初始化，CPU必须立即执行一段已知的、在Flash中的启动代码来初始化系统。_c_int00是C编译器提供的运行时库入口，负责初始化数据段、BSS段等。
异常向量（undefEntry, svcEntry...）：均使用ldr pc, label指令。当发生对应异常时，CPU会执行这条指令，将label处存储的32位值（即ram_undef等符号的地址）加载到PC寄存器，从而实现跳转。注意，这里的label（如tab_undef）是紧跟在向量表后面的一个内存字（word）。
IRQ/FIQ向量：这两者通常由芯片的Vectored Interrupt Manager模块管理，其向量地址由硬件自动计算（[pc,#-0x1b0]这个偏移量是访问VIM RAM的固定方式），因此我们不需要也不应该去重定向它们。保持原样即可。
地址对齐：ARM要求异常向量表必须32字节对齐（每个向量入口占4字节，共8个入口）。我们的.intvecs段包含了8个向量指令+4个地址字，共48字节。但为了兼容ECC计算和某些工具链的要求，强烈建议将该段的大小扩充并对齐到64字节。这可以通过在链接器脚本中设置length=0x40并确保palign=16（16*4=64字节）来实现。

3.2 SRAM中的二级向量表（ramIntvecs段）

这个段在链接时被指定加载到Flash中，但在系统启动初期，会通过复制表（Copy Table）机制被拷贝到SRAM的指定区域（通常是SRAM的末端，高地址部分）。

.sect "ramIntvecs" .retain "ramIntvecs" .arm ram_undef: ldr pc, ram_tab_undef ; 跳转到 ram_tab_undef 存储的地址 ram_swi: ldr pc, ram_tab_swi ; 跳转到 ram_tab_swi 存储的地址 ram_pref: ldr pc, ram_tab_pref ; 跳转到 ram_tab_pref 存储的地址 ram_dabt: ldr pc, ram_tab_dabt ; 跳转到 ram_tab_dabt 存储的地址 ; --- SRAM中的最终函数地址表 --- ram_tab_undef: .word Undef_Handler ; 指向最终的未定义指令处理函数 ram_tab_swi: .word SVC_Handler ; 指向最终的软件中断处理函数 ram_tab_pref: .word Prefetch_Handler; 指向最终的预取指中止处理函数 ram_tab_dabt: .word DataAbort_Handler; 指向最终的数据中止处理函数

二级跳转的必要性：你可能会问，为什么需要两级跳转？为什么不直接在Flash的tab_undef里存放最终处理函数Undef_Handler的地址？这是因为，Undef_Handler这类函数的地址是在链接时确定的。如果Bootloader和主App的Undef_Handler函数链接地址不同（它们通常不同），那么Flash中那个固定的tab_undef里的值就无法同时满足两者。而两级跳转的妙处在于：第一级跳转目标（ram_undef）的地址是固定的（由链接器脚本指定在SRAM高端），第二级地址表（ram_tab_undef）的内容是可以在运行时修改的。这样，Bootloader启动后，可以将ram_tab_undef的值设为自己的Undef_Handler；跳转到主App后，主App可以将其修改为自己的Undef_Handler，实现了动态切换。

3.3 链接器脚本（.cmd文件）的关键修改

链接器脚本是让这一切在内存中正确落地的蓝图。修改主要集中在两个部分：内存布局（MEMORY）和段分配（SECTIONS）。

内存布局修改示例：

MEMORY { /* Flash */ VECTORS (X) : origin=0x00000000 length=0x00000040 /* 64字节，给.intvecs段 */ FLASH0 (RX) : origin=0x00000040 length=0x017FFFC0 /* Flash剩余部分 */ /* SRAM */ STACKS (RW) : origin=0x08000000 length=0x1500 /* 栈空间 */ RAM (RWX): origin=0x08001500 length=(256K-0x1500-0x20) /* 主RAM */ RAMVECTORS(RWX): origin=0x0803FFE0 length=0x20 /* 32字节，SRAM末尾给向量表 */ }

VECTORS：为Flash中的.intvecs段预留64字节空间，起始于0x0。
RAMVECTORS：在SRAM的末尾（例如0x0803FFE0）开辟一个32字节的区域，用于存放ramIntvecs段（包含二级跳转指令和地址表）。放在末尾是为了防止栈溢出破坏向量表（栈通常从低地址向高地址增长）。

段分配修改示例：

SECTIONS { /* Flash中的段 */ .intvecs : {} palign=16, fill=0xffffffff > VECTORS .text : {} palign=8 > FLASH0 ... /* 其他标准段 */ /* 需要从Flash拷贝到RAM的段 */ .TI.ramfunc : {} palign=8, load=FLASH0, run=RAM, table(BINIT) /* 使用ramfunc属性的函数 */ ramIntvecs : {} load=FLASH0, run=RAMVECTORS, palign=8, table(ramIntvecsCpyTbl) }

.intvecs：链接到VECTORS区域（0x0）。
ramIntvecs：这是关键。load=FLASH0表示它的原始数据存储在Flash中；run=RAMVECTORS表示它运行时应该位于SRAM的高端地址；table(ramIntvecsCpyTbl)指示链接器生成一个名为ramIntvecsCpyTbl的复制表。系统启动时，启动代码会查找这个表，并将ramIntvecs段的内容从Flash拷贝到RAMVECTORS指定的SRAM地址。

4. 系统启动流程与关键初始化步骤

将向量表重定位到SRAM，必须在系统启动的特定时机完成初始化，顺序错了就可能引发不可预知的行为。下面是一个基于Hercules HALCoGen生成代码的标准启动流程，并标明了我们插入初始化代码的最佳位置。

4.1 启动顺序与代码插入点

CPU复位，从0x0执行：CPU从Flash的0x0地址开始执行，即我们的.intvecs段。首先执行b _c_int00，跳转到C运行时环境初始化代码。
初始化栈指针和关键寄存器：由汇编启动文件完成。
调用main()之前的系统初始化：在HALCoGen生成的sys_startup.c中，main()函数之前会调用一系列初始化函数。我们需要关注的是内存初始化和ECC使能之后。
关键位置：User Code Section 39：在HALCoGen的启动代码模板中，main()函数之前有一个清晰的代码块划分。“User Code Begin (39)”和“User Code End (39)”之间是初始化我们重定位向量表的黄金位置。为什么？
- 此时，SRAM已经通过memoryInit()函数进行了硬件自动初始化（通常填充为0）。
- CPU对TCRAM（紧耦合RAM）的ECC检查已经通过_coreEnableRamEcc_()函数使能。
- 系统的关键内存子系统处于一个稳定、可用的状态。
- 此时尚未执行任何可能触发异常的用户代码。

初始化代码示例：

/* ... HALCoGen自动生成的启动代码 ... */ memoryInit(0x1U); /* 初始化SRAM，填充0或特定值 */ /* USER CODE BEGIN (38) */ /* USER CODE END */ _coreEnableRamEcc_(); /* 使能RAM ECC */ /* USER CODE BEGIN (39) */ copy_in(&ramIntvecsCpyTbl); /* 将ramIntvecs段从Flash拷贝到SRAM */ /* 可选：进一步初始化SRAM中的向量表地址 */ ram_tab_undef = (uint32)&My_Undef_Handler; ram_tab_swi = (uint32)&My_SWI_Handler; ram_tab_pref = (uint32)&My_Prefetch_Handler; ram_tab_dabt = (uint32)&My_DataAbort_Handler; /* USER CODE END */ /* ... 其他初始化 ... */ main(); /* 进入用户主程序 */

copy_in(&ramIntvecsCpyTbl)这个函数（或其等价实现）负责执行实际的拷贝操作。它解析链接器生成的ramIntvecsCpyTbl结构，将数据从Flash搬运到SRAM。

4.2 多应用场景下的切换策略

在Bootloader和主App之间切换时，向量表的切换是平滑的：

Bootloader运行时：Bootloader在初始化阶段（自己的User Code Section 39）将ram_tab_*指向自己的异常处理函数。
Bootloader跳转到主App前：Bootloader通常不需要做特殊处理。因为跳转是通过直接设置PC寄存器到App的入口点实现的，CPU的异常处理机制会继续沿用当前已加载的向量表（仍在SRAM中），但其中的函数指针指向的是Bootloader的处理函数。
主App初始化时：主App在自己的启动代码中（同样是User Code Section 39），必须重新初始化SRAM中的向量表地址，将其指向自己的异常处理函数。这样，主App运行期间发生的异常，就会由主App自己的处理函数来接管。

重要心得：务必在每个独立应用程序镜像的启动代码中都包含对SRAM向量表的初始化步骤。不要假设SRAM中的内容在跳转后会被保留或自动设置。这是一个常见的疏忽点，会导致App运行时异常被错误地导向Bootloader的处理函数，引发难以调试的问题。

5. 安全性、可靠性考量与进阶技巧

将关键的系统控制结构（异常向量表）放在可写的SRAM中，带来了灵活性的同时，也引入了新的风险。在功能安全（Functional Safety）或高可靠性应用中，我们必须严肃对待这些风险。

5.1 SRAM初始状态的不确定性

系统上电复位（POR）后，SRAM的内容是随机的、未定义的。在我们将正确的向量表内容拷贝到SRAM之前，如果CPU发生异常（尽管概率很低），它会执行SRAM中的随机指令，后果不可预测。

应对策略：

尽早初始化：如前所述，在SRAM初始化（memoryInit）和ECC使能后，立即拷贝向量表。这是缩短“危险窗口期”的最有效方法。
将向量表置于SRAM高端：将RAMVECTORS放在SRAM的末尾（高地址）。这样，如果CPU执行了随机指令，它很快会跑到超出物理SRAM的地址，触发预取指中止异常。而我们的Flash向量表对预取指中止的处理，最终也会指向SRAM（尽管内容随机），但至少能将系统锁定在一种可知的异常状态（通常是死循环），而不是执行任意恶意代码。
利用自动初始化：Hercules的memoryInit函数通常会将SRAM初始化为全0。指令0x00000000在ARM中对应ANDEQ R0, R0, R0，这是一条无操作（NOP）指令。如果向量表条目是全0，CPU会连续执行NOP，直到程序计数器溢出或遇到非法地址，同样能导向一种相对可控的失效状态。

5.2 防止意外篡改与内存保护

SRAM中的向量表可能被跑飞的指针或缓冲区溢出意外修改。

应对策略：

使用MPU（内存保护单元）：Cortex-R内核集成了MPU。我们可以配置一个MPU区域，覆盖RAMVECTORS所在的地址范围，将其属性设置为只读（Read-Only）或特权模式只读。这样，在用户模式下或任何情况下，都无法通过软件写操作修改这块内存。修改向量表的操作必须在特权模式下，通过特定的函数（如ramTabChangeEntry）临时调整MPU设置或通过其他安全机制来完成。
定期校验：在后台任务或看门狗中断服务程序中，定期计算SRAM中向量表区域的CRC32校验和，与存储在Flash中的预期值进行比较。如果发现不匹配，说明向量表被破坏，应立即触发系统安全状态恢复（如复位或切换到备份固件）。
ECC的作用：Hercules的SRAM支持ECC（错误纠正码），可以检测和纠正单比特错误，检测双比特错误。这能防止因宇宙射线等因素导致的软错误（Soft Error）破坏向量表。但请注意，ECC主要防硬件随机故障，不防软件逻辑错误导致的覆盖。

5.3 调试技巧与常见问题排查

在实际项目中实现此功能时，你可能会遇到以下问题：

问题1：异常发生后，程序没有跳转到我的处理函数，而是进入了HardFault或死循环。

排查步骤：
1. 检查拷贝是否成功：在初始化后，立即通过调试器查看RAMVECTORS地址的内存内容。对比Flash中ramIntvecs段的原始数据，看是否一致。确保copy_in函数被正确调用且复制表ramIntvecsCpyTbl链接正确。
2. 检查地址值：查看SRAM中ram_tab_undef等地址处的值，是否确实是你处理函数的入口地址。你可以通过&My_Handler在调试器中获取该地址进行比对。
3. 检查链接器脚本：确认.intvecs段确实在0x0，且ramIntvecs段的run地址与你在SRAM中查看的地址一致。确认没有其他段（如.stack）覆盖了RAMVECTORS区域。
4. 单步调试异常入口：在调试器中，手动触发一个未定义指令（例如执行一个.word 0xE7F0DEF0），然后单步执行。观察PC是否先跳转到Flash的undefEntry，再执行ldr pc, [pc, #offset]，然后跳转到SRAM的ram_undef，最后执行ldr pc, [ram_tab_undef]。在哪一步偏离预期，问题就在哪一步。

问题2：在应用程序切换后，新App的异常处理函数不生效。

原因：新App的启动代码没有重新初始化SRAM中的ram_tab_*指针。每个App都认为向量表已经在SRAM中，但忘记更新里面的函数指针。
解决：确保每个应用程序（包括Bootloader）的初始化序列中都包含对ram_tab_*的赋值操作。

问题3：代码体积或RAM占用略微增加。

原因：这是正常的。我们增加了Flash中的跳转表（约16字节）和SRAM中的二级向量表（约32字节），以及拷贝这些数据的启动代码。
权衡：用极小的存储空间开销（通常不到100字节），换取系统架构上巨大的灵活性，在多数多应用系统中是值得的。

6. 实战示例：在Bootloader与App间切换SWI处理函数

让我们通过一个具体的软件中断（SVC/SWI）例子，把整个流程串起来。假设Bootloader和主App各有自己的SWI处理函数。

Bootloader侧代码：

// bootloader_main.c #include "hal_stdtypes.h" // 声明外部定义的SRAM向量表地址变量（由汇编文件定义） extern volatile uint32 ram_tab_swi; // Bootloader的SWI处理函数 __attribute__((interrupt("SWI"))) void Bootloader_SWI_Handler(void) { // Bootloader特定的SWI处理逻辑 LOG("SWI handled by Bootloader\n"); // ... 处理 ... } void bootloader_init(void) { // ... 其他初始化 ... // 1. 拷贝向量表到SRAM (在User Code Section 39中调用) copy_in(&ramIntvecsCpyTbl); // 2. 将SRAM中的SWI向量指向Bootloader自己的处理函数 ram_tab_swi = (uint32)&Bootloader_SWI_Handler; // ... 其他初始化 ... } void bootloader_main(void) { // 假设此时需要调用一个SWI服务 asm(" svc #0"); // 触发SWI异常 // CPU将执行 Bootloader_SWI_Handler }

主应用程序（App）侧代码：

// app_main.c #include "hal_stdtypes.h" extern volatile uint32 ram_tab_swi; // App的SWI处理函数 __attribute__((interrupt("SWI"))) void App_SWI_Handler(void) { // 应用程序特定的SWI处理逻辑 LOG("SWI handled by Application\n"); // ... 处理 ... } void app_init(void) { // 注意：app_init在Bootloader跳转过来后执行 // 此时SRAM中已有向量表，但内容指向Bootloader的函数 // 关键步骤：重定向向量到App自己的处理函数 ram_tab_swi = (uint32)&App_SWI_Handler; // ... 其他App初始化 ... } int main(void) { app_init(); // 现在触发SWI，将由App_SWI_Handler处理 asm(" svc #0"); return 0; }

操作流程：

系统上电，运行Bootloader。
Bootloader初始化，将ram_tab_swi设为Bootloader_SWI_Handler。
Bootloader运行时，任何SWI指令都由Bootloader_SWI_Handler处理。
Bootloader完成工作，验证主App有效，然后跳转到App的入口地址。
主App开始执行，在app_init()中，将ram_tab_swi重新赋值为App_SWI_Handler。
此后，主App中触发的任何SWI指令，都由App_SWI_Handler处理。

这个例子清晰地展示了运行时动态切换异常处理程序的能力。对于数据中止、预取指中止等异常，可以采用完全相同的模式，使得每个应用程序都能拥有自己独立的、完整的异常管理策略。

7. 总结与扩展思考

通过将Hercules MCU的异常向量表重定位到SRAM，我们成功构建了一个支持多应用共享CPU异常处理机制的灵活框架。其核心价值在于解耦：将固定的硬件异常入口与可变的软件处理程序解耦，将不同应用程序的异常处理逻辑解耦。

回顾一下关键点：使用LDR PC指令实现两级跳转是效率最高的方法；链接器脚本的精确配置是基础；在系统启动后、应用初始化前完成SRAM向量表的拷贝和设置是正确性的保证；而利用MPU、CRC校验等手段则是高可靠性系统的必备加固措施。

这项技术不仅适用于Bootloader/App场景，还可以扩展到更复杂的运行时环境，例如：

带有实时操作系统（RTOS）的系统：在RTOS内核启动前，使用一套基本的异常处理程序；在内核完全初始化后，将向量表切换到RTOS提供的更高级别的异常管理框架。
安全与非安全世界隔离（如ARM TrustZone）：虽然Hercules Cortex-R4/R5不支持TrustZone，但在类似架构中，此思想可用于管理不同安全状态下的异常向量。
动态加载模块：在支持动态链接或模块加载的系统中，新加载的模块可以注册自己的特定异常处理例程。

实现过程中，最需要警惕的是状态管理。必须清晰地知道在系统的每一个时间点，SRAM向量表中的指针指向的是谁的处理函数。良好的文档、清晰的初始化代码流程和充分的测试（包括故意触发异常进行测试）是保证系统稳健运行的关键。