企业官网建设流程全解析

1. 先画一张地图：23个寄存器都在哪

搞嵌入式开发的人，没有谁绕得开“寄存器”三个字。新手最容易做的事，是翻开芯片参考手册，从 GPIO 的第一组寄存器开始背地址，背到 UART 就放弃，因为外设寄存器实在太多了。我做了十几年 MCU 相关开发，越来越觉得，真正决定技术高度的不是背下了多少外设寄存器，而是对内核寄存器有没有形成肌肉记忆。今天这篇内容，就是把 ARM Cortex-M 内核里最常见的 23 个寄存器一次性讲透：R0 到 R12、SP、LR、PC、xPSR、PRIMASK、FAULTMASK、BASEPRI、CONTROL、VTOR、SCR。这 23 个寄存器是所有 Cortex-M 芯片的地基，不管你写裸机、跑 RTOS，还是做 BootLoader、低功耗，都会和它们打交道。适合刚入门但被参考手册劝退的 MCU 开发者，也适合那些遇到 HardFault 只会按复位键、却不知道怎么从寄存器现场定位问题的工程师。

1.1 这 23 个寄存器到底指哪 23 个

很多教程写“23 个寄存器”时喜欢把外设寄存器也算进去，但外设寄存器不同芯片差异太大，比如 STM32 的 USART 寄存器和 GD32 的不完全一样，NXP 的 LPUART 又不一样。真正能让你“一套知识走天下”的，是 ARM 内核统一设计的这批寄存器。我列的 23 个，恰好覆盖 Cortex-M 的编程模型：

这张表里 R0-R12 一共 13 个，加上 SP、LR、PC 三个，正好 16 个核心寄存器；再加上 xPSR、PRIMASK、FAULTMASK、BASEPRI、CONTROL 五个特殊寄存器，以及 VTOR、SCR 两个系统控制块寄存器，合计 23 个。记的时候不要孤零零地背编号，而是要按“通用计算、程序状态、中断控制、系统配置”四个维度去理解，后面每一组我都会展开说。

1.2 为什么我先啃内核寄存器，而不是背外设寄存器

经常有人问我：点个灯不是只需要设置 GPIO 寄存器吗？为什么还要花时间去搞懂内核寄存器？我的回答是：GPIO 寄存器只能让你在这个型号上点灯，而内核寄存器能让你在任何一个 Cortex-M 芯片上排错。外设寄存器的本质，其实就是通过总线地址映射出来的一块内存，读写它的底层动作是 CPU 在执行 LDR/STR 指令，CPU 的状态、堆栈、返回地址全由内核寄存器决定。你如果不懂 R0-R12、SP、LR，那么即使把 GPIO 寄存器地址背得滚瓜烂熟，遇到程序跑飞、中断不响应、任务切换崩溃，依然一脸懵。

更关键的是，外设寄存器种类太多，没有一个人能背完。今天你会用 STM32 的串口，明天换成瑞萨、英飞凌、NXP，外设寄存器名字又变了。但是内核算得上的 23 个寄存器基本不变，变了也只是保留位和优先级位数不同。所以现在的建议是：拿到一块新 MCU，先花半天时间把内核寄存器对应的调试操作全部过一遍，再碰外设。这个投入，比盲目点灯划算得多。

2. 通用寄存器不是“变量容器”，而是调用约定的一部分

很多人看汇编时，把 R0-R12 理解成“给编译器用的临时变量”，这个方向没错，但嵌入式开发里你要清楚一件事：这些寄存器不只属于你，也属于编译器、RTOS 调度器和中断硬件。函数调用时谁负责保存这些寄存器，中断来临时哪些寄存器被自动压栈，稍有不慎就会造成数据错乱。理解通用寄存器，实际上是在理解 ARM 的 AAPCS 过程调用标准和 Thumb 指令集。

2.1 R0-R7 与 R8-R12：Thumb 指令集留下的分工

Cortex-M 处理器主要执行 Thumb/Thumb-2 指令。最初的 16 位 Thumb 指令受编码长度限制，只能访问 R0-R7 这 8 个低寄存器，所以低寄存器在指令里更“好使”，可以直接参与大多数运算。R8-R12 是高寄存器，想要操作它们，往往需要 32 位的 Thumb-2 指令，或者通过某些特殊指令来搬移。这在实际项目里的影响是：底层汇编库里负责高频运算的代码，通常优先用 R0-R7；而 R8-R12 更多用来保存那些“不能被子函数随便改掉”的长期变量。

按照 AAPCS 调用约定，R0-R3 是参数寄存器和返回值寄存器，调用子函数时前 4 个参数分别放进 R0、R1、R2、R3，第 5 个参数开始压栈；R4-R11 由被调用者保存，也就是说被调函数如果用到了这些寄存器，返回之前必须恢复原样；R12 是函数内部临时寄存器，调用者不需要保存。我自己调试裸机代码时，经常在 HardFault 后直接看栈帧里的 R0 判断函数参数是不是被写坏了，或者看 R4 的值是否和预期不符。如果你写过汇编，一定体会过“R0 传参、R0 返回、R4-R11 保护现场”这套规则的强大。

2.2 SP：一块栈，两个指针，用错就复位

SP 在 Cortex-M 里不止一个物理寄存器，而是分成 MSP（主栈指针）和 PSP（进程栈指针）。复位后默认使用 MSP，裸机程序中一般全程用 MSP；RTOS 中，每个任务拥有自己的栈，线程模式通常切到 PSP，而中断和内核代码继续用 MSP。硬件压栈、出栈时使用的是当前 SP，所以任务切换时把 PSP 指向任务自己的栈顶，每次调度器切换任务只需要保存/恢复 PSP，任务的栈就能自动隔离。

用 SP 最容易踩的坑是 8 字节对齐。AAPCS 要求 SP 在任何时候都要保持 8 字节对齐，否则某些使用 LDRD/STRD 指令或浮点寄存器的 C 代码会触发 HardFault。自己做任务栈分配时，如果只按 4 字节对齐定义数组，调度器一切换就可能随机死机。稳妥办法是把任务栈定义成uint64_t task_stack[STACK_SIZE]，或者显式用__attribute__((aligned(8)))对齐。另外，启动文件里给 MSP 赋初值的那个地址，必须是栈顶地址且对齐，不是随便一个内存地址就可以。

2.3 LR：既是返回地址，也是异常返回的“暗号”

LR 在普通函数调用里保存的是返回地址，执行 BL 指令时，硬件自动把下一条指令地址写进 R14。正常函数返回时，执行BX LR就能回到调用处。但如果现场发生了中断或异常，LR 里面存的不再是普通返回地址，而是一个特殊的 EXC_RETURN 值。比如 0xFFFFFFF1 表示从 Handler 模式返回，使用 MSP；0xFFFFFFF9 表示返回线程模式，使用 MSP；0xFFFFFFED 表示返回线程模式，使用 PSP。判断当前代码是否处于异常上下文，最直接的办法就是看 LR 是不是以 0xFFFFFFFx 开头。

这个“暗号”在 RTOS 里特别有用。PendSV 异常处理函数想发起任务切换，最后往往不是直接跳转，而是修改好 PSP 后执行BX LR，让 CPU 按 EXC_RETURN 触发异常返回，硬件自动把新任务的寄存器全部弹出。你要是把 LR 当成普通返回地址使用，比如用POP {PC}覆盖 PC，异常返回机制就会被打乱。所以做 RTOS 移植的人常挂在嘴边一句话：不要随便修改 LR，除非你清楚知道 EXC_RETURN 的来龙去脉。

2.4 PC：调试时看到 PC 值，先别急着套老经验

PC 是程序计数器，在大多数场景下不需要直接读写，因为分支指令、函数调用、异常返回都会自动修改它。裸机调试时，PC 指向正在执行的指令地址，反汇编窗口里高亮的那一行一般就和 PC 对应。很多从 ARM7/ARM9 转过来的老工程师，习惯性认为“PC = 当前指令地址 + 8”，这是经典 ARM 流水线的经验，但在 Cortex-M 里并不完全适用，所以调试时不要用这个公式去猜 PC 值。

PC 还有一个特殊之处：在 Thumb 模式下，地址最低位必须为 1，代表“ Thumb 状态”。如果你在调试器里手动修改 PC，把一个偶数地址写进去，CPU 会认为要切到 ARM 状态，而 Cortex-M 不支持 ARM 状态，立刻进入错误异常。这也是很多人用调试器“强行改 PC 跳过某个函数”发现死机的原因。正确做法是只修改 PC 的低位地址保持 Thumb 状态，或者干脆用BX/branch指令来跳转，让编译器处理状态位。

3. xPSR、PRIMASK、BASEPRI、FAULTMASK、CONTROL：状态与控制寄存器

通用寄存器管“算”，状态与控制寄存器管“怎么算”和“安不安全”。这一组寄存器虽然不常直接出现在业务代码里，但在中断开关、任务切换、异常排查时是核心。很多开发者只见过__disable_irq()和__enable_irq()，却不知道这两个函数底层操作的是 PRIMASK。把这些寄存器弄明白，你才能真正理解为什么有的临界区保护方法会误伤高优先级中断，为什么 RTOS 的调度器要费尽心思改 BASEPRI。

3.1 xPSR 拆开看：APSR、IPSR、EPSR

xPSR 是一个组合寄存器，相当于把三个功能打包在一起。APSR 是条件标志位，包含 N、Z、C、V、Q，CMP 指令和大多数运算指令都会更新它们，条件分支和 if 语句最终靠这些标志位判断结果。IPSR 是当前异常编号，比如读到 3 表示正在执行 HardFault，读到 11 表示 SVCall，读到 14 表示 PendSV。调试时如果你发现程序停在某个异常处理函数里，直接看 IPSR 就能知道是哪一路异常触发的，省得猜。

EPSR 里最重要的是 T 位，它标明当前指令是 Thumb 状态，必须一直为 1。如果某些非法分支把 T 位清了，CPU 会立刻进入错误状态。EPSR 还有一个 IF-THEN 状态位，跟条件执行短指令有关，普通 C 开发基本不用关心。我的经验是：xPSR 是 HardFault 排查的第一道入口。程序进 HardFault 后，先看 xPSR 的 IPSR 部分确认异常号，再看栈帧里的 PC 定位出错指令，比到处打日志高效得多。

3.2 三面“屏蔽墙”怎么选：PRIMASK、FAULTMASK、BASEPRI

这三兄弟都是用来屏蔽中断的，但适用场景完全不同。PRIMASK 置 1 时，除了 NMI 和 HardFault，其他所有可配置优先级的中断都会被屏蔽。这是最简单粗暴的临界区保护方式，很多 HAL 库里的关中断函数就是操作它。__disable_irq()对应CPSID i，__enable_irq()对应CPSIE i。缺点是攻击范围太大，哪怕你有一个优先级极高的紧急中断，也会被 PRIMASK 拦下来。

FAULTMASK 更狠，它连 HardFault 都敢屏蔽（当然 NMI 依然例外），所以极少使用，除非你在做那种“任何中断都不能打扰”的时序敏感操作。需要特别注意的是，FAULTMASK 会在异常返回时自动清 0，不能拿来当作全局开关一直用。BASEPRI 则是更优雅的方案，它设定一个优先级阈值，只有优先级编号大于等于 BASEPRI 的中断才会被屏蔽，优先级数值小于 BASEPRI 的更高优先级中断可以照常响应。这里有个反直觉点：Cortex-M 中断优先级数值越小，逻辑优先级越高。所以想“屏蔽中低优先级中断，放行最高优先级中断”，可以设置 BASEPRI = 1。Cortex-M0/M0+ 通常不支持 BASEPRI，只能在 M3/M4/M7/M33 等内核上使用。

3.3 CONTROL：线程模式下的栈和特权级

CONTROL 寄存器是切换“运行模式”的开关。它里面有两个关键位：nPRIV 和 SPSEL。nPRIV 置 1 后，当前线程运行在非特权模式，不能访问某些系统控制寄存器，也不能执行 MRS/MSR 中的特定操作，这通常用于 RTOS 把用户任务限制在非特权模式，防止应用代码把内核搞崩；SPSEL 则决定线程模式使用 MSP 还是 PSP，RTOS 希望每个任务有自己的栈，于是把 SPSEL 置 1，让任务跑在 PSP 上。中断发生时会自动使用 MSP，所以中断处理函数里的局部变量不会污染任务的 PSP。

改 CONTROL 之后，建议马上执行__ISB()指令，确保后续指令能看到最新设置。我曾经在任务切换里只改了 PSP，没更新 CONTROL 的 SPSEL，结果任务第一次跑没问题，第二次进中断后返回到错误栈，整个系统随机复位。这种问题很难查，因为寄存器窗口里 CONTROL 看起来没什么异常，只有盯着切换点看才能发现。你写 RTOS 调度器时，一定要把“更新 PSP + 更新 CONTROL + 执行 ISB”这三步当成一组原子动作来看待。

4. VTOR 与 SCR：被低估的两个系统控制寄存器

如果说前面几组寄存器是“天天见面”，那 VTOR 和 SCR 属于“关键时刻救命”的类型。VTOR 负责中断向量表的位置，BootLoader 要跳转 APP，APP 要使用自己的中断，基本都绕不开它；SCR 控制低功耗行为，和 WFI/WFE 指令配合后，你才能真正设计出一个既能睡觉又能被中断唤醒的嵌入式系统。这两个寄存器不常写，但一旦写错，问题往往非常隐蔽。

4.1 VTOR：中断向量表“搬家”，第一位必须是栈顶

VTOR 的完整名字是向量表偏移寄存器，它告诉 CPU“从哪个地址去找中断向量表”。复位后，VTOR 默认指向 Flash 起始地址，也就是向量表放在 0x00000000 附近。在做 IAP 升级或者 BootLoader 跳转 APP 时，APP 的向量表并不会自动从 BootLoader 区域搬到 APP 区域，如果你不修改 VTOR，APP 里一旦发生串口中断、定时器中断，CPU 仍然会去 BootLoader 向量表里取中断入口，大概率直接跑飞。

修改 VTOR 时有几个坑。第一个是地址对齐，Cortex-M 一般要求偏移量按向量表大小对齐，常见做法是 128 字节对齐，具体的对齐要求要看芯片参考手册。第二个是向量表第一个字必须是初始栈指针，第二个字才是 Reset_Handler 地址，这两个字必须真实有效，否则一上电就 HardFault。第三个坑是修改完 VTOR 后，要执行__DSB()和__ISB()，确保流水线里已经预取的旧向量和旧地址无效。我自己遇到过跳转 APP 后第一次中断正常、第二次中断死机的情况，最后发现就是漏了 DSB，指令预取导致取向量时读到旧地址。

4.2 SCR 的 SLEEPONEXIT：低功耗系统的双刃剑

SCR 是系统控制寄存器，里面最常用的是 SLEEPDEEP 和 SLEEPONEXIT。SLEEPDEEP 用于选择是进入普通睡眠还是深度睡眠，通常还要配合电源控制寄存器一起设置；SLEEPONEXIT 则是一个很有意思的位：当它置 1 时，CPU 从异常处理函数返回后直接进入睡眠，而不是回到线程模式继续执行主循环。这意味着你可以把整个系统设计成“只在中断里响应事件，处理完立刻睡”的驱动模式。

这种模式特别适合电池供电的传感节点：主循环里没有事做，一直执行 WFI，外设中断来了就处理，处理完返回时 SLEEPONEXIT 自动触发再次睡眠，功耗能压得很低。但要注意，如果中断处理函数只是置了一个标志位，期望主循环去执行具体逻辑，SLEEPONEXIT 会直接断送你这条路。因为它让 CPU 根本回不到主循环。我见过一个产品功能正常，但主循环里的看门狗喂狗代码永远没机会执行，最后系统反复超时复位的例子。如果你想用 SLEEPONEXIT，就一定要保证所有该做的事都在中断处理里完成，或者另配一个定时器中断来喂狗。

5. 用一个 HardFault 实例，把 23 个寄存器串起来

前面讲了单个寄存器，接下来用一个最常见的崩溃场景——HardFault，把这 23 个寄存器串起来。很多开发者遇到 HardFault 的第一反应是“程序写崩了，然后复位”，但真正的调试高手会马上查看寄存器现场，通过栈帧还原出出错时的调用关系。你会发现，R0-R12、SP、LR、PC、xPSR 这些知识全都能用上，这也正是它们“必知”的原因。

5.1 异常现场：硬件自动压栈的顺序

当 Cortex-M 发生异常时，硬件会自动把一部分寄存器压入当前栈。压栈顺序依次是 xPSR、PC、LR、R12、R3、R2、R1、R0。这里很容易混淆：压进栈里的 PC 是异常发生前正在执行（或将要执行）的指令地址，LR 是异常发生前 R14 的值，而不是 EXC_RETURN。异常响应完成后，当前 LR 会被修改成 EXC_RETURN，但栈帧里保存的 LR 是被打断代码的返回地址。所以你在 HardFault 处理函数里读 LR 得到的是 EXC_RETURN，读栈帧里的 LR 才能还原上层调用者。

硬件事先压栈的好处是，即使中断处理函数里又调用了别的函数，原始现场也已经被保护起来。很多刚学 RTOS 的人不理解为什么任务切换要在 PendSV 里做，其实正是因为 PendSV 异常会在入口处自动保存任务现场，你只用在异常里保存剩下的寄存器，再切换 PSP，最后触发异常返回恢复新任务现场即可。硬件压栈这个动作，本身就是为高效任务切换设计的。

5.2 从 LR 的 EXC_RETURN 判断该看哪个栈

进 HardFault 后，第一件事是看 LR 的值。如果 LR = 0xFFFFFFED，说明异常发生在线程模式，并且线程用的是 PSP，被压栈的现场在 PSP 指向的栈上；如果 LR = 0xFFFFFFF9，说明线程模式用的是 MSP，现场在 MSP 上；如果 LR = 0xFFFFFFF1，说明异常发生在 Handler 模式，现场在 MSP 上。这个判断直接决定你后续该读哪个 SP 去解析栈帧，用错了栈顶，解出来的 PC、LR 全是错的。

调试器打开寄存器窗口时，通常能看到异常发生后 SP 自动变成了 MSP，但如果现场原本在 PSP 上，MSP 并不是你找栈帧的入口。我见过有人拿着 MSP 开始回溯调用栈，解析出来的地址乱七八糟，怀疑内存被写穿，结果只是因为没看 EXC_RETURN。正确步骤是：先把 LR 的值转换成 EXC_RETURN，确定原始 SP，再去对应 SP 位置向上找 8 个寄存器字，从其中一个字里读出 PC。手动解析要小心栈方向是向下生长的，认准栈顶地址比认准栈底更重要。

5.3 从栈帧里的 PC 和 LR 定位出错代码

假设你判断出栈帧在 PSP 上，PSP = 0x20001000，那么栈帧中 R0 位于最低地址 0x20000FE0 附近，往上依次是 R1、R2、R3、R12、LR、PC、xPSR。你读出栈帧里的 PC，比如是 0x08001234，再在反汇编窗口里查看 0x08001234 是哪条指令，通常就能定位到出错的 C 语句。如果栈帧里的 PC 指向一个奇怪地址，比如 0xDEADBEEF 或未对齐地址，那大概率是函数指针被破坏或栈溢出写坏了返回地址。

还需要配合栈帧里的 LR 看调用关系。栈帧里 LR 保存的是出错那一刻 R14 的值，也就是“被中断的函数是从哪里被调进来的”。如果这个值落在 Flash 的代码区，就能继续往上追一层。很多调试器有 Call Stack 窗口，但裸机工程没有调试信息时经常显示不全，这时候手动画栈帧反而更靠谱。我通常的做法是：在 HardFault_Handler 里打断点，用寄存器窗口记下 LR 和当前 SP，然后手动把栈帧里的 PC、LR 抄出来，配合 map 文件定位函数名。这个方法在 C 优化开 O2 时仍然好用，因为只要 PC 落在 Flash 代码区，map 文件就能帮你找到最近的函数符号。

5.4 从内核寄存器延伸到外设寄存器：同一套读写逻辑

回到外设寄存器。你看到 GPIO、串口、定时器那些寄存器时，不要觉得它们和内核寄存器是两个维度。对 CPU 来说，外设寄存器就是内存地址，访问方式本质是 LDR/STR 指令。比如在 STM32 上，RCC 寄存器控制时钟使能，GPIO 寄存器控制引脚模式，它们都映射在总线地址空间里，读写它们同样会使用 PC、SP、R0-R12，同样会更新 xPSR 的标志位。唯一的不同是，外设寄存器的地址由芯片厂商定义，需要查手册。

查外设寄存器时，我会先看寄存器偏移和位域的说明，然后在代码里用 CMSIS 定义的结构体指针访问，这样最不容易写错地址。调试时用调试器的内存窗口直接读 0x40021014 这类地址，观察复位值和实际值的变化，能帮你确认外设是否被正确初始化。甚至像以太网 PHY 这类芯片，它内部的寄存器得通过 MDIO/MDC 接口访问，但读回来的状态也是寄存器位域，处理逻辑和读普通 MCU 寄存器没有本质区别。学会了内核寄存器，再看这些外设寄存器，你会获得一种“所有寄存器都不过如此”的踏实感。

6. 实用调试命令与踩坑经验

最后这部分，我把这些年实际调试中积累的寄存器使用经验集中说一下。不是每个项目都需要熟记所有 23 个寄存器的位域，但有几个技能值得反复练习：在调试器里快速查看寄存器、用寄存器点灯做最小环境验证、理解临界区保护对中断的影响、处理 BootLoader 跳转后的中断问题。这些都是我在真实项目踩过坑之后才彻底明白的。

6.1 调试器里最常用的寄存器查看命令

如果你用 GDB 调试 ARM 芯片，最基础的是info registers，一次能看到 R0-R12、SP、LR、PC、xPSR 等值；想单独看某个寄存器，用p/x $r0或者p/x $lr。如果调试器是 VS Code 里的嵌入式插件，通常有“寄存器”视图，可以直接逐项观察。OpenOCD 的命令行下，你可以输入reg显示所有寄存器，输入reg r0查看 R0，输入mdw 0x20000000读取内存中的栈帧数据。这套组合拳在排查 HardFault 时非常高效。

我个人的习惯是给调试器脚本写一个别名，把“读 LR、读当前 SP、读栈帧前 8 个字”打包成一个命令。毕竟每次 HardFault 都手动抄寄存器太慢了，脚本化之后只要一条命令，就能把异常现场完整打印出来。这个脚本还能顺便把 EXC_RETURN 转换成“当前在哪个模式、用哪个栈”的说明，省得自己对着 0xFFFFFFED 发愣。嵌入式调试，拼的就是谁能在最短时间内把寄存器乱局还原成可理解的调用链。

6.2 用寄存器改动完成“最小环境验证”

很多新手依赖 HAL/库函数，点个灯也要调好几层封装，出了问题不知道是时钟没开还是模式没配。我建议至少在一个板子上练习用寄存器配置外设，比如直接把 RCC 的 GPIO 时钟使能位设为 1，把 GPIO 的模式设为输出，再把 ODR 或 BSRR 置位。整个过程不需要引用任何库函数，打开调试器的寄存器窗口，你能亲眼看到每个位的变化，这种“位即真相”的感觉是理解寄存器的关键。

以常见的 STM32F103 为例，开启 GPIOC 时钟需要把 RCC->APB2ENR 的 bit4 置 1；把 PC13 设为推挽输出，要把 GPIOC->CRH 里对应位段设为 0010；最后让引脚输出低电平，用 GPIOC->ODR 或 GPIOC->BRR 操作。运行后如果 LED 正常点亮，说明你已经完成了“看手册、找地址、配位域”的完整闭环。再往后学串口、定时器，你会发现套路完全一样：时钟、模式、数据、状态，四个维度反复出现。

6.3 踩过的坑：PRIMASK 误伤高优先级中断

有一年做电机控制，我用__disable_irq()保护一段关键参数更新代码，结果硬件调试时发现编码器的 Z 相索引中断经常丢失，导致机械零位偶尔找不到。一开始以为是编码器硬件问题，折腾半天才发现罪魁祸首就是 PRIMASK。它把所有中断都关了，包括本应最高优先级的索引捕捉，只要参数更新代码刚好覆盖到 Z 相脉冲，中断就被吞掉一次。我后来改用 BASEPRI，把阈值设为 1，只屏蔽普通中断，让最紧急的 Z 相中断穿过去，问题立刻消失。

这个坑说明一个重要原则：临界区保护不是把中断全关掉就一定安全，而是要看哪些中断绝对不能错过。BASEPRI 就是为这种场景设计的，可惜不少工程师习惯了__disable_irq()，从没想过它是一条“不分优先级一刀切”的粗策略。如果你用的芯片支持 BASEPRI，强烈建议在需要保护临界区但允许高优先级中断的场景里把它用起来。如果芯片是 Cortex-M0，没有 BASEPRI，那就要在中断优先级设计上做好文章，不要让关键中断长时间等待。

6.4 踩过的坑：BootLoader 跳转 APP 后忘了改 VTOR

另一个很典型的案例是 IAP 升级。我做过一个远程升级 BootLoader，跳转 APP 后串口中断一直不触发，但打日志发现 APP 已经跑起来了，主循环在转，就是任何中断都像消失了一样。后来查了很久才确认是 VTOR 没改。APP 的代码在 0x08010000，中断向量表也在那，但 VTOR 还指向 BootLoader 的 0x08000000，所以串口一旦来数据，CPU 去旧向量表里找入口，找到的还是 BootLoader 的中断响应函数，执行完一条完全没意义的回调，然后直接跑飞。

修这个问题的标准操作是，在 APP 启动的最早期，把SCB->VTOR设置成 APP 的向量表地址，同时确保该地址第一个字是 APP 自己的栈顶，第二个字是 Reset_Handler。修改后加上 DSB 和 ISB，防止流水线继续用旧向量。遇到那些不支持 VTOR 的 M0 内核芯片，则要换一种思路：通过编译链接把 APP 的向量表放在固定地址，或者使用厂商库的特殊机制，不能用“改了就能跳”的惯性思维。踩过一次坑后，我现在写 BootLoader 跳转代码时，第一行就会关注 VTOR，第二行关注 SP，这两个寄存器配合好，中断体系才算是真正“搬家”成功。

这 23 个寄存器，每一个背后都有类似的真实教训。我的习惯是每接触一块新板子，先在调试器里把 R0-R12、SP、LR、PC、xPSR 调出来，跑一遍简单的寄存器点灯程序，再手动设一次 VTOR 做中断重定位实验。这样折腾半天，看着枯燥，但在后续项目里遇到任何灵异问题时，心里会稳很多。寄存器不是用来背的，是用来在关键时刻帮你还原真相的，这才是嵌入式开发真正值得投入时间的地方。