搞嵌入式的人，迟早会跟 Bootloader 正面撞上。最近我在一个技术群里看到有人问：“STM8S003F3P6 刷了 Bootloader 之后，中断全都不干活了，为什么？”紧接着又有人追问：“IAP Boot 里面定义的变量，复位之后还会在吗？”这两个问题看似零散，其实恰好戳中了 Bootloader 知识体系里最容易踩坑的三个点：启动流程怎么走、中断向量表怎么处理、变量和上下文怎么交接。本文想把 Boot ROM、User Bootloader、IAP、OTA 沿着一条真实的产品启动链路全部拆开，结合 STM32、STM8、ESP32、HC32L136、MTK Android 12 这些具体平台，把“能跑”和“跑得稳”之间的差距讲清楚。适合正在做 MCU 固件升级、被启动异常折腾到怀疑人生、或者刚开始接触 OTA 的嵌入式开发者。
1. 先搞清楚 Bootloader 到底在解什么题
1.1 从一次“变砖”事故引出的核心问题
先说一个我早期做产品的真实事故。有一批设备已经量产交付，客户返修说某个传感器数据偶发错误，我们定位到是 App 里一个中断处理函数写错了。修复很简单，重新编译固件也就几十秒，但怎么把新固件送到现场设备上成了大麻烦。设备没有联网，没有 USB 口，唯一的对外接口是调试串口，而且这个调试串口从来没做过升级功能。最后只能让客户把设备寄回来，拆机、接 SWD、烧录、再寄回去。那一刻我意识到：如果当初在产品里留一个能自我更新的引导程序，这单返修最多是一个远程电话就能解决的事。
Bootloader 要解决的核心问题就是这么朴素：让设备具备“自我升级”和“自我修复”的能力，而不是每次改代码都靠拆机、靠调试器、靠返厂。再往深一层，它还要保证升级过程中断电、断线、传错包都不会把设备变成砖头。这也是为什么说 Bootloader 不是“一个跳转函数”，而是一整套启动与恢复机制。
1.2 芯片上电后，内部到底跑了什么
很多人对 Bootloader 的理解是“一段跳转到 App 的代码”，这个印象不能算错，但过于简化。真实的上电过程是一个三级接力：Boot ROM、User Bootloader、App，每一级都有明确的分工。
芯片上电后，CPU 首先执行的不是你的代码，而是芯片出厂时固化在 ROM 里的一段引导程序，也就是 Boot ROM。它对 flash 和 SRAM 做基本初始化，然后根据引脚电平、选项字节或 flash 内容判断接下来该干什么：要么进入下载模式等外部工具写入固件，要么把控制权转交给 Flash 里的用户程序。用户程序区如果放了 User Bootloader，就由 User Bootloader 继续做升级判断和 App 跳转；如果没放，就直接从复位向量启动 App。OTA 则是 User Bootloader 或 App 在运行时通过无线网络获取新固件，再调用 IAP 能力完成写入。
这条链路里最容易出问题的地方，恰恰是接力棒的交接位置：Boot ROM 往 User Bootloader 交接时可能误入下载模式，User Bootloader 往 App 交接时可能出现中断向量表错位，App 升级过程中可能因为断电导致写了一半的固件直接无法启动。后面几节我会逐个展开。
1.3 Boot ROM、User Bootloader、IAP、OTA 的定位
这四个名词经常被混用，但它们的层级完全不同。用一张表可以看得很清楚：
| 概念 | 代码放在哪里 | 能否修改 | 干什么用 |
|---|---|---|---|
| Boot ROM | 芯片内部 Mask ROM | 不可修改 | 上电后的第一段代码，负责启动介质选择和下载模式 |
| User Bootloader | Flash 用户区 | 可修改 | 产品自定义的引导程序，负责校验、跳转、接收新固件 |
| IAP | 用户程序或 Bootloader 中实现的逻辑 | 可修改 | In Application Programming，在应用运行过程中自编程写入 Flash |
| OTA | 通常是 App 或 Bootloader 配合服务端 | 可修改 | Over The Air，通过网络完成固件获取、校验、触发 IAP 升级 |
简单概括：Boot ROM 是芯片厂家写好的“第一口饭”，User Bootloader 是你自己写的“饭堂打饭阿姨”，IAP 是“把饭菜重新装盘”的技术动作，OTA 则是“远程叫外卖”的产品形态。绝大多数产品的稳定性问题，都出在 User Bootloader 与 App 的交接，以及 IAP 写 Flash 的边界处理上。
2. Boot ROM：芯片出厂自带的“第一口饭”
2.1 为什么芯片里必须有一段“出厂代码”
一个很反直觉的事实是：Flash 里的程序并不是芯片一上电就能自动跑起来的。芯片需要一段“先行代码”来决定从哪里加载程序、怎么初始化最基本的时钟和存储器，甚至判断当前是不是要进入下载模式。这段代码必须在任何用户代码之前就存在，所以芯片厂家会在出厂时把它固化进 Mask ROM，这就是 Boot ROM。
你可以把 Boot ROM 类比成电脑的 BIOS 或 UEFI。电脑开机后 BIOS 负责找硬盘、初始化内存、决定从哪个介质启动，然后才把控制权交给操作系统。MCU 里的 Boot ROM 也是同样的角色：它初始化最基本的运行环境，读取启动配置，然后决定把控制权交给 Flash、SRAM 还是内部下载协议。理解了这一点，就不会再把“Bootloader 只能自己写”当成理所当然。
2.2 STM32、STM8、ESP32 的 Boot ROM 行为对比
不同芯片厂商对 Boot ROM 的用法差异很大，踩坑的方式也各不相同。我挑三个最常见的平台说。
STM32 的 Boot ROM 叫 System Memory，是否进入它由 BOOT0 和 BOOT1 引脚电平决定。上电时如果 BOOT0 拉高，芯片就会从 System Memory 启动，此时可以通过 USART1 或其他串口用内置 bootloader 下载固件；BOOT0 拉低则从用户 Flash 启动。这里有个经典坑：量产板如果 BOOT0 引脚飞线没处理好，或者外部干扰导致上电瞬间电平不对，设备就会“莫名其妙”进入下载模式，表现为程序不跑、串口还能握手。排查这种问题不能只盯代码，要用万用表实测上电瞬间的引脚电平。
STM8 的 Boot ROM 行为又不一样。STM8 没有 BOOT 引脚，它是通过选项字节和一个 GPIO 状态来决定是否进入 bootloader。以 STM8S003F3P6 为例，官方 bootloader 的进入条件需要在复位时满足特定引脚状态，很多人第一次接触时根本找不到入口，最后是靠 STVP 或者串口工具按特定时序才勉强连上。
ESP32 的一级 Bootloader 在 ROM 里，但它不会直接加载 App，而是先去 Flash 找二级 Bootloader，再由二级 Bootloader 根据分区表加载 App。ESP32 的启动链路比 STM32 多一层，好处是出厂引导逻辑非常灵活，坏处是分区表一旦写错，设备会卡在“boot loop”里反复重启。
2.3 误入下载模式与“假死”现象
Boot ROM 层面最常见的故障就是“假死”：芯片没坏，但它停在 Boot ROM 里等你下载程序，而现场人员不知道，以为设备挂了。这类问题的排查思路其实很固定：
- 第一步，测量目标芯片的供电、时钟、复位脚是否正常。
- 第二步，用调试器连接，尝试读取 PC 指针当前停在哪个地址。如果停在 0x1FFFxxxx 附近（STM32 的 System Memory 区域）或者停在 flash 之外的地址，说明进入了 Boot ROM/下载模式。
- 第三步，检查启动引脚电平、选项字节、以及 Flash 首地址内容是否为空。
Flash 全空的芯片开机后也会停在 Boot ROM，这时候很多人的第一反应是“芯片坏了”，其实只是没有程序可引导。搞清楚 Boot ROM 的存在，这些现象就都解释得通了。
3. User Bootloader：从零写一个能跳转的引导程序
3.1 第一步是画好 Flash 分区地图
写 User Bootloader 不是打开工程直接写跳转代码，第一步一定是规划 Flash 分区。以 STM32F103 这种常见 MCU 为例，一个典型的 256KB Flash 分区长这样：
| 起始地址 | 大小 | 内容 |
|---|---|---|
| 0x08000000 | 32KB | Bootloader |
| 0x08008000 | 192KB | App |
| 0x0801F800 | 2KB | 升级标志与版本参数区 |
Bootloader 放在最低地址，因为芯片复位后默认从 0x08000000 取向量表。App 放在 Bootloader 之后，起始地址要按扇区对齐，因为大部分 MCU 的 flash 擦除单位是扇区，不对齐会导致擦写时误伤邻居。参数区我用独立扇区存放，里面记录当前固件版本、升级待完成标志、升级次数计数，这些信息在 OTA 回滚和防砖逻辑里非常关键。
分区规划的原则很简单：Bootloader 和 App 的地址空间绝不能重叠；参数区要有独立扇区，不能和代码混在一起；如果以后要做双 Bank，还要把 App 区拆成两个等大小的 Bank。这些决策最好在项目第一天就定死，后期想改分区会非常痛苦。
3.2 跳转动作的本质：改栈指针、改 PC
很多教程把跳转代码写得像是某种魔法，其实它的本质就两件事：把主栈指针 MSP 改成 App 的栈顶地址，把程序计数器 PC 改成 App 的复位函数地址。Cortex-M 内核上电后会从向量表第一个字取 MSP 的值，从第二个字取复位向量地址，跳转代码模仿的正是这个过程。
下面是一段标准的 STM32 跳转代码：
typedef void (*pFunction)(void); static void jump_to_app(uint32_t app_addr) { uint32_t sp = *(volatile uint32_t *)app_addr; uint32_t pc = *(volatile uint32_t *)(app_addr + 4); pFunction app_entry = (pFunction)pc; __disable_irq(); // 恢复默认中断向量表，避免 VTOR 还停在 Bootloader 区域 SCB->VTOR = FLASH_BASE; __set_MSP(sp); app_entry(); }这段代码有三个关键点。第一，为什么要从 App 起始地址读值？因为 App 的二进制文件开头就是向量表，第一个字必须填栈顶地址，第二个字填 Reset_Handler 地址，这是 Cortex-M 硬编码的约定。第二，为什么要关闭全局中断？因为跳转瞬间 VTOR 切换到 App 的向量表之前，如果中断正好触发，CPU 会拿着旧的向量表和新的栈指针去处理中断，轻则进 HardFault，重则彻底跑飞。第三，为什么 SCB->VTOR 要重新赋值？因为某些情况下 Bootloader 运行时会为了自己的外设中断把 VTOR 改成 Bootloader 区域，不恢复的话 App 的中断全部错位。
3.3 STM8S003F3P6 为什么“跳过去就没中断”
STM8 和 STM32 有本质区别：STM8 没有 VTOR 寄存器，中断向量表物理固定在 0x008000 区域，而且这个区域就是 Flash 的起始地址。这意味着 Bootloader 和 App 谁占了 0x008000 起始区，谁才拥有真正生效的中断向量表，另一方即使把自己的中断函数编译到天涯海角，硬件也不会去找它。
STM8S003F3P6 出现“Bootloader 跳转后 App 中断无法使用”的原因就在这里：Bootloader 在低地址区，占用了物理向量表；App 被链接到高地址，它的中断函数地址确实存在，但硬件触发中断时依然从 0x008000 读取向量，读到的要么是 Bootloader 的默认处理逻辑，要么是空的，App 的中断自然不执行。
实际量产方案一般采用 Flash 自编程把 App 的向量表搬进 0x008000 区域。具体做法是：App 在编译时把自己的向量表整体放置到 App 区起始位置，并在向量表之后附加一份“新向量表数据”；Bootloader 跳转前，将这份数据用 Flash 编程接口写入 0x008000 物理向量区，完成后再跳转。做到这一步后，App 的中断才能真正生效。
这块调试经验我多说一句：如果不想在 Bootloader 里做这么重的 Flash 搬移操作，最简单的替代方案是让 Bootloader 极简化，不使用任何中断，并且把物理向量区完全交给 App。但这要求 Bootloader 几乎不能依赖外设中断，很多功能场景下会有约束。两种方案我都实践过，工程上还是推荐前者，一劳永逸。
3.4 IAP Boot 里的变量，复位后到底去哪了
这也是热搜里那个高频问题：“IAP Boot 里面定义的变量复位后会怎样？”先说结论：跳转 App 这个动作本身不会让 RAM 清零，但 App 的启动代码会重新初始化 .data 和 .bss 段，把 Bootloader 留下的全局变量覆盖掉，所以你在 App 里读不到 Bootloader 的变量内容，并不是数据“凭空消失”，而是地址被重新初始化了。
详细拆一遍：Bootloader 运行中，全局变量在 RAM 的特定地址。执行跳转后，没有硬件复位，只是 PC 跳到了 App 的 Reset_Handler。但 App 的启动代码紧接着会做两件事：把 Flash 里预存的 .data 初值复制到 RAM，把 .bss 区域清零。如果你的 Bootloader 全局变量刚好落在 App 的 .data/.bss 范围内，内容会被覆盖；如果落在范围外，内容还在，但已经没有意义了，因为没有任何代码会去用它。
如果你想在 Bootloader 和 App 之间传数据，正确姿势不是依赖“碰巧还在的 RAM”，而是定义一个链接脚本里固定地址的共享区，或者使用芯片的备份寄存器、参数 Flash 区。固定 RAM 地址的写法类似：
#define SHARED_ADDR_BASE 0x20001000 typedef struct { uint32_t magic; uint32_t upgrade_flag; uint32_t firmware_version; } shared_data_t; #define shared_data (*(shared_data_t *)SHARED_ADDR_BASE)前提是 Bootloader 和 App 的链接脚本都要把这一段 RAM 预留出来，不要在 .data/.bss 段里占用它。用这种方式传递升级标志、错误码、上电原因，在量产设备里非常实用。
4. IAP：让固件升级成为一次普普通通的操作
4.1 固件包格式与一次完整的升级流程
IAP 的全称是 In Application Programming，意思是设备在运行过程中自己对 Flash 编程。但“自己写 Flash”只是最后一步，前面还得解决一个关键问题：固件怎么传进来、怎么保证它是对的。
一个可靠的固件包不能只是一堆二进制数据，至少要包含如下字段：
| 字段 | 作用 | 长度建议 |
|---|---|---|
| 帧头魔数 | 识别数据包起始，防止错乱 | 2~4 字节 |
| 固件版本号 | 版本比较，避免降级误刷 | 4~8 字节 |
| 固件长度 | 知道要接收多少数据 | 4 字节 |
| 固件数据 | 实际二进制内容 | 按扇区分包 |
| CRC32/签名 | 完整性校验/合法性校验 | 4~64 字节 |
| 结束标志 | 明确传输结束，便于确认 | 2 字节 |
一次完整的串口 IAP 升级流程是这样的：Bootloader 收到上位机的升级请求后，擦除 App 区，然后一包一包接收固件数据，每收到一包就校验 CRC，写入 Flash 后把当前写到的地址记录下来，让意外断传后可以从断点继续。全部写完后再读回一整遍做 CRC 校验，校验通过才清除“升级待完成”标志，跳转 App。任何一个环节校验失败，就回滚或者停留在 Bootloader 等待重传。
这里我特别想强调“边写边留进度”的价值。有一次客户现场用串口升级，线接触不良，每传几 KB 就断一次，但因为有断点续传，同一个升级任务断断续续十来次最终还是完成了。如果没有进度记录，每次断线都得从头再来，传大固件时体验会非常崩溃。
4.2 单 Bank 与双 Bank：安全升级的分水岭
IAP 实现上有一个影响安全性的关键决策：用单 Bank 还是双 Bank。
单 Bank 方案是常见 MCU 的入门做法：Flash 里只有一份 App，升级时先擦掉旧 App，再写入新 App。优点是不费 Flash，缺点是擦除后、写完成前如果断电，设备直接变砖，只能靠外置工具或 Boot ROM 恢复。单 Bank 方案适合产品还在开发阶段、或者升级场景可以容忍“必须返修”的情况。
双 Bank 方案把 App 区拆成 A/B 两份，当前运行的是 A，升级时往 B 写，写完后把启动标志切到 B，下次上电从 B 启动。如果 B 启动失败，Bootloader 还能把启动标志切回 A，实现自动回滚。代价是 Flash 占用翻倍，但它是 OTA 产品最稳妥的底座。我个人的经验是：只要 Flash 容量允许，优先双 Bank，因为产品一旦上线，你永远无法预测用户那边的网络和电源状况。
| 特性 | 单 Bank | 双 Bank |
|---|---|---|
| Flash 占用 | 低 | 高（约 2 倍） |
| 升级失败后果 | 可能变砖 | 可自动回滚 |
| 实现复杂度 | 简单 | 中等 |
| 适合场景 | 开发阶段、小固件 | 量产 OTA 设备 |
4.3 回滚、防砖与升级标志位设计
防砖的核心是让 Bootloader 在每次上电时都先问一个问题：“上一次升级真的完成了吗？”这个问题的答案放在哪、怎么维护，就是升级标志位的设计。
我的做法是在参数区单独放一个结构体，包含 magic、升级标志、当前固件版本号、下次启动地址、升级尝试次数。Bootloader 上电后检查这个结构体：
- 如果升级标志为“无任务”，直接启动当前 App。
- 如果升级标志为“待完成”，说明上次升级没有收尾，Bootloader 根据备份区是否有完整固件决定继续完成还是回滚。
- 如果升级标志为“待完成”且启动后 App 在限定时间内没有上报运行正常，Bootloader 要能强制回滚到旧版本。
这里有个很实用的工程补丁：配合一个独立看门狗，App 启动后 30 秒内上报“我活着”信号，Bootloader 再把标志位从“待确认”改成“已完成”。如果 App 本身起不来，看门狗超时复位，Bootloader 发现标志还是“待确认”，就自动回滚到备份版本。这套机制虽然土，但在无数产品上证明过有效性。
4.4 HC32L136 这类国产 MCU 的 IAP 实操要点
最近问 HC32L136 IAP 的人明显变多了，这类国产 MCU 在做 IAP 时有一些共性问题值得专门说。
第一，Flash 编程的时序和等待周期。国产 MCU 的 Flash 控制器实现各有差异，但有一条通用铁律：擦写 Flash 期间 CPU 不能从 Flash 取指，否则取到的可能是垃圾指令。解决方法是把擦写函数搬到 RAM 里执行，或者关闭中断并在很短的时间内完成擦写。很多国产 MCU 的参考手册里有例程，但直接 Ctrl+C 到自己的工程往往跑不通，就是因为没有做 RAM 执行或中断处理。
第二，中断向量表的处理。有些国产 MCU 有类似 STM32 的 VTOR 寄存器，有些没有。HC32L136 这类产品要先查参考手册确认，如果它本身支持向量偏移，直接设置即可；如果不支持，就得像我前面写 STM8 那样做向量表搬移或规避中断。
第三，低功耗模式对 Flash 的影响。一些 MCU 在低功耗唤醒后，Flash 等待状态或读取配置会回到默认值，导致从唤醒到重新初始化 Flash 这段时间里读代码出错。IAP 期间最好明确禁止进入低功耗模式，升级完成后再恢复。
实操上的建议是：拿到一款新 MCU 做 IAP，不要一上来就相信网上现成的工程，先把该芯片参考手册里“Flash memory programming”章节完整读一遍，再对照电源电压和时钟频率设置等待周期。这半小时的投入，能省下后面调莫名其妙的死机问题的几天时间。
5. OTA：把升级从“线缆”搬到“云端”
5.1 从串口 IAP 到 OTA，多出来的那些事
如果说 IAP 解决的是“设备能自己写 Flash”，OTA 解决的是“新固件怎么跑到设备上”。把串口线换成无线网络，看起来只改了一下传输通道，实际上新增了四件麻烦事：第一是设备要能联网并解析协议；第二是固件要能可靠下载，哪怕是弱网环境；第三是升级触发要有人管，不能全设备同一秒抢带宽；第四是升级后要能确认效果，不然你永远不知道哪些设备成功了哪些失败了。
一套典型的 OTA 升级链路是这样的：设备通过 MQTT 或 HTTP 向升级服务端查询版本，服务端返回“有新版本，下载地址为 xxx”；设备下载固件包到外部 Flash 或内部临时分区，边下边校验 CRC；下完整包后写入双 Bank 的空闲区，写入完成后置位升级标志，执行软复位；Bootloader 上电检查标志，确认后启动新 App；App 启动后主动上报新版本号，服务端把该设备标记为升级成功。
这中间任何一环都可能失败，所以 OTA 比串口 IAP 更需要把“失败承认”放在设计里。比较稳妥的做法是：设备侧维护一个升级状态机，第一次失败先重试，连续失败几次就停在旧版本并上报错误码，不要不停重启循环升级。
5.2 全量包、增量包与差分包，怎么选
OTA 固件包有几种形态，“全量包”“增量包”“差分包”经常被混着提，但它们不是同一个维度。
全量包是最简单也最稳的形态：整个 App 二进制打成一个包，任何设备不管当前什么版本，下载后都能直接写入升级。优点是不依赖设备现有版本，生成和管理都简单；缺点是体积大，流量成本高。热搜里总能看到“一加 OTA 全量包”“OTA 全量包下载”这类词，就是因为手机厂商为了保证兼容性，跨版本升级时经常采用全量包策略。
增量包和差分包其实是一类思路：基于旧版本，只打包变化的部分。优点是体积小，缺点是设备必须能确认自己的当前版本，且新旧版本之间要有明确的升级路径。如果版本跨度太大，比如从 V1.0 直接升到 V3.0，增量补丁可能打不出来，服务端就得准备多套增量包。很多 OTA 系统最后都是“默认全量包、网络昂贵或空间紧张场景才用增量包”的组合策略。
| 类型 | 包体积 | 生成复杂度 | 升级安全性 | 典型场景 |
|---|---|---|---|---|
| 全量包 | 大 | 低 | 高 | 跨大版本、兼容性优先 |
| 增量包 | 小 | 高 | 中 | 小规模补丁、流量敏感 |
| 差分包 | 小 | 高 | 中 | 特定版本路径优化 |
5.3 延迟升级与强制升级的产品与工程逻辑
用户侧的升级体验设计得不好，会让一个原本能救命的功能变成投诉源头。“苹果 OTA 延迟升级查询入口”这类热搜词说明一个事实：很多用户想控制设备什么时候升级，而不是被动接受。
从产品逻辑上说，升级弹窗有几种做法。提示升级：只提示，用户可以选以后再说；延迟升级：用户或企业可以设置一个时间窗口，比如“今晚两点之后再升级”；强制升级：某些版本有严重安全漏洞或不可兼容的格式变更，必须立刻升级，否则功能不可用。
从工程逻辑上说，延迟升级的核心是“自律”：相同 MAC 地址或设备 ID 的设备要遵守全局升级节奏，避免同一时间点集体下载，打爆服务端带宽。一个常见做法是把目标设备按 ID 分片，每个分片在启动升级前先和服务端同步一个随机延迟时间，再开始下载。强制升级则要配合回滚保护，因为强制升级一旦出问题，用户端没有任何挽回手段，只能依赖上一节说的双 Bank 自动回滚。
5.4 ESP32 OTA 实操：分区表、API 和典型坑
ESP32 是 OTA 开发绕不开的参考平台，因为它的 OTA 链路做得非常完整。用 ESP-IDF 做 OTA 时，分区表是关键。一个典型的分区表长这样：
# Name, Type, SubType, Offset, Size nvs, data, nvs, 0x9000, 0x4000 otadata, data, ota, 0xD000, 0x2000 app0, app, factory, 0x10000, 0x200000 app1, app, ota_1, 0x210000, 0x200000这个表里 app0 是出厂固件，app1 是 OTA 备用区。运行时 ESP-IDF 推荐的 API 组合是：用esp_ota_get_running_partition获取当前运行分区，用esp_ota_get_next_update_partition获取可写入分区，写入完成后用esp_ota_set_boot_partition切换启动分区，最后调用esp_restart重启。
ESP32 OTA 的几个典型坑我挨个说。第一个坑是分区表里 app 分区偏移必须是 0x10000 对齐，否则 bootloader 启动会失败。第二个坑是 otadata 分区不能手动清理，它记录了当前选择哪个 app 分区，手动改了会让系统分不清该从哪个分区启动。第三个坑是下载固件时如果用 HTTP 明文传输，一旦网络被干扰，拉下来的固件可能不完整，一定要做全量校验再写入。第四个坑是升级完成后的第一次启动如果异常，需要应用自身在启动早期向 Bootloader 报告状态，IDF 提供的esp_ota_mark_app_valid_cancel_rollback就得在合适时机调用，错过了回滚窗口就麻烦了。
6. 排错实战：几个高频 Bootloader 问题的完整链路
6.1 STM8S003F3P6 中断失灵：先看 PC 再看向量表
回到开头的那个问题。遇到 STM8S003F3P6 Bootloader 跳转后中断失灵，我的排查顺序是这样的：第一步用调试器挂着，看跳转后 PC 停在哪，如果 PC 在 App 主循环里正常转，说明基本跳转成功；第二步随便触发一个中断，看 PC 是否跳去了预期地址，如果中断后 PC 跑飞或者根本不进中断，基本锁定是向量表问题；第三步读一下 0x008000 区域内容，对比 App 工程 MAP 文件里各中断处理函数的地址，就能确认真实向量表和 App 预期向量表不一致。
解法就是我前面写的向量表搬移：App 链接时把向量表完整放在 App 区头部，Bootloader 在跳转前通过 Flash 自编程把这份向量表写入 0x008000 物理区域。这个操作要注意两点：写入期间要关中断，防止出现不可预知的中断跳转；Flash 擦写耗时较长，最好在跳转前完成，不要在跳转后再补。
6.2 “变量丢失”：不是数据没了，而是上下文换了
“IAP Boot 里定义的变量复位后会怎样”这个问题在实践中一般表现为：Bootloader 设置了一个升级标志，跳转 App 后想读取它来判断是否进入升级模式，结果读到的是乱码或者初值。要记住，Bootloader 和 App 是两个独立编译的程序，各自维护自己的变量初始化逻辑，RAM 不是跨越两个程序的共享舞台，除非你主动规划共享区。
排查这个问题最直接的方法是看 MAP 文件：把 Bootloader 的全局变量地址和 App 的 .data/.bss 段范围都找出来，对照一下就知道谁覆盖了谁。我在实际项目中踩过多次之后，养成了一个习惯：所有 Bootloader 与 App 需要交接的字段，一律放进固定地址共享结构体，不依赖任何编译器默认行为。
6.3 MTK Android 12 应用层调用 OTA 的流程与权限
MTK Android 设备上，App 想主动触发 OTA 升级，通常不是直接把固件“写进芯片”，而是要借助 Android 系统的 recovery 或 update_engine 机制。应用层的常规流程是：应用先从升级服务器下载完整 OTA 包，校验签名和 MD5，然后调用系统提供的接口进入 recovery 模式，由系统在重启时完成固件解包和分区写入。整个升级过程应用层其实只在前面一小段，真正决定成败的是签名校验是否通过。
MTK Android 12 上涉及几个注意点：一是 SELinux 权限，普通应用没有权限直接调用 recovery 相关接口，通常需要系统签名应用或者通过系统服务代理；二是 AB 分区的平台，升级接口和传统 recovery 方式不一样，要看厂商是否走 update_engine；三是如果产品是自己定制的系统，最好让应用只做下载展示和用户确认，升级状态机放在系统服务里，这样权限边界清晰，也不容易出现应用被杀导致升级中断的问题。
这个方向很容易踩权限坑，我建议的方案是：应用层负责下载、校验、提示，真正触发系统升级的动作通过一个系统级 Broadcast 或自定义系统服务完成，应用自身尽量不做“和 recovery 分区直接交互”的事。
6.4 最后一道防线：Boot ROM 兜底救砖
不管 Bootloader 写得再好，总有机会遇到升级把 User Bootloader 自己也写坏的情况。这时候最后一根救命稻草就是 Boot ROM 里出厂的下载模式。前面第 2 节说过，STM32 有 BOOT 引脚进入 System Memory，STM8 可以通过选项字节和特定引脚进入 bootloader，ESP32 则有串口下载模式。只要 Boot ROM 还在，芯片就有条路能重新写入有效程序，就不会变成彻底废砖。
所以做量产设备时，最好把“进入出厂下载模式”的硬件路径保留下来，哪怕只是预留一个测试点或者一个拨码开关位。我在一个户外设备项目里就吃过教训：整机密封，唯一的 BOOT 引脚测试点在生产时被省略了，结果有台设备在客户现场升级写坏了 User Bootloader，只能整机寄回。后来改版恢复了测试点，远程救砖就变成了几句话能说清的操作。
顺带提一句，网上有些人做“自动救砖”工具，原理基本都是靠 Boot ROM 下载模式监听一段时间内是否有连接请求，有则进入下载，没有则正常跳转。这个思路本身没有问题，但它能不能救砖，前提是 Boot ROM 通道还通着，所以硬件上把下载接口留出来，永远比任何软件方案都可靠。
做 Bootloader 这些年，我最大的体会是：先想清楚怎么回来，再想清楚怎么过去。跳转代码可以很简洁，但回滚设计、标志位维护、向量表交接、升级失败兜底，才是真正决定一个产品能不能远程救活的关键。最后再分享一个小技巧：在 Bootloader 里保留“开机前按住某个按键不松开就进入升级模式”的机制，这套设计在产线和现场调试里救过我无数次，值得所有做固件升级的开发者抄进自己的工程里。
