Bootloader 实战 (1)：启动的接力棒 —— 详解 STM32 与 RL78 的向量表重定向差异

前言 从“点灯工程师”进阶到“系统工程师”，手写 Bootloader 是一道必经的坎。 很多人觉得 Bootloader 只是一个“跳转程序”，只要把 PC 指针改一下就行了。但当你真正面对量产产品时，你会发现：为什么 APP 里的中断没反应？为什么跳转后程序莫名死机？为什么 STM32 能做到的事，换了瑞萨 RL78 或 51 就彻底失效了？ 本系列文章将从底层机制出发，手把手带你设计一个永不“变砖”的 OTA 系统。今天第一篇，我们要解决的是最核心的问题：如何把 CPU 的控制权，完美地从 Bootloader 交接到 APP 手中？

一、 核心矛盾：谁占据了“上帝视角”？

所有的 MCU 上电后，硬件逻辑都会强制 CPU 去访问一个固定地址（通常是 0x00000000 或 Flash 起始地址），从中读取**栈指针（SP）和复位中断处理函数（Reset Handler）**的位置。

这就引出了 OTA 设计的第一个核心矛盾：地址冲突。

在 OTA 架构中，Flash 被划分为两个主要区域：

1. Bootloader 区（占据起始地址，例如 0x0800 0000）

2. APP 区（偏移地址，例如 0x0800 4000）

上电时，CPU 自然运行 Bootloader。但问题来了：当 Bootloader 跳转到 APP 后，如果此时触发了一个定时器中断，CPU 该去哪里找中断服务函数（ISR）？

CPU 的硬件逻辑默认还是去 0x0000 附近的中断向量表（Vector Table） 查找入口。如果