MCU远程在线IAP升级：Bootloader分区、Flash擦写与中断向量重定向解析

简介：面向使用华大HC32L136进行量产产品开发的工程师，这份工程提供完整远程在线升级参考方案，包含引导程序、应用程序和配套上位机软件，重点解决设备已部署后固件难以现场升级的问题；HC32F030、HC32L130以及HC32L(F)17X/19X系列也可参考移植。压缩包共282个文件，整体约3.29MB，除C源码、头文件、IAR/Keil工程文件与链接脚本外，还有J-Link烧录脚本、bin/hex固件和清理编译中间文件的工具脚本，覆盖编译、链接、烧录到调试的完整链路。目前已有3525人学习下载。通过该工程可以理清升级分区划分、引导跳转逻辑、通信协议和上位机交互方式，也能复用现成工程模板、上位机代码及烧录配置，快速搭建自己的远程升级方案。工程目录模块划分清晰，适合对照启动流程与运行逻辑做二次开发。

1. 远程在线IAP升级：让MCU擦写自己正在运行的Flash，凭什么不把自己写死

把 HC32L136 / HC32F030 / HC32L130 这类 M0+ 内核 MCU 做成远程在线 IAP 升级，有一个很反直觉的事实：你的 App 正跑在 Flash 里，而 IAP 要擦写的偏偏就是 Flash 本身。这就好比站在自己正锯着的树枝上继续锯——锯断的那一刻，你一定会掉下去。它能 work，靠的绝不是运气，而是 bootloader 与 App 在物理上的严格分区隔离、Flash 擦写代码被搬到 RAM 里执行、以及中断向量表逻辑上的谨慎重定向。搞懂这套机制，你才能回答一个很多人说不清楚的问题：为什么同一份升级包在一台设备上顺利升完，在另一台上跳转就死机？这背后是分区设计、跳转协议和 Flash 时序共同作用的结果，也是本文要拆开的部分。

2. 分区与启动链路：Bootloader 和 App 的地址契约是怎么签下来的

远程 IAP 的第一步不是写协议，而是画地址图。Bootloader 和 App 各自独立编译，各自拥有一份中断向量表，它们能协作的前提是双方都严格遵循一份“分区契约”。这个契约一旦签错，后面所有代码都是在给玄学打工。

2.1 复位后发生的第一件事：两行地址决定整个系统的命运

Cortex-M0+ 内核复位后，不执行你写的任何 C 代码，硬件只做一件事：从地址0x00000000读出 4 字节作为初始 MSP（主栈指针），再从0x00000004读出 4 字节作为复位向量，然后跳转到复位向量指向的地址开始执行。这是设计死的，没法绕过，也不需要绕过——IAP 的一切都建立在这条规则上。

典型的分区表长这样：

上面0x1000、0xF000是示意值，真正选多少由芯片的 Flash 擦除粒度决定。HC32 系列不同型号的页（Page）和扇区（Sector）大小不一样，有的按 512B 擦除，有的按 1KB 或更大处理。App 起始地址必须向上对齐到擦除粒度边界，同时满足第 4 章要说的 VTOR 对齐要求。

为什么要物理隔离？因为 Boot 升级 App 的过程，本质上是擦掉 App 区再写入新固件。如果 Boot 和 App 的边界没落在扇区边界上，擦除某一扇区时把 Boot 尾巴也擦掉了，那才是真正的“一次性变砖”。所以 Boot 区一般做成固定大小，不随代码量浮动，链接脚本里明确写上FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x1000，让编译器在 Boot 超过 4KB 时直接报错，而不是默默占掉 App 的地盘。

2.2 HC32L136 / HC32F030 / HC32L130：没有统一分区表，只有统一判断方法

这三个型号覆盖了低功耗和通用控制两条产品线，Flash 容量、RAM 大小、擦除粒度、Flash 等待周期都不相同。网上流传的“bootloader 代码通用”是不靠谱的——代码逻辑能复用，但分区参数必须按型号查手册重新填。我一般按三步确定分区：

第一步，查对应型号数据手册的 Flash 特性表，找到最小擦除单位。这一步决定 App 起始地址的“步长”。第二步，确认 Boot 需要的体积。不要把 Boot 设计得刚好够用，预留一个扇区余量给后续协议升级。第三步，把参数区放在独立的扇区里。这一点常被忽视，很多人把升级参数存到 App 区末尾，结果每次更新参数都要擦写 App 区的扇区，两边互相干扰。

一个值得养成的习惯：把分区表定义成头文件里的宏，Boot 和 App 的链接脚本都引用它。比如#define APP_BASE_ADDR 0x00001000u，内部 Flash 大小不够时，改一处宏再全局重编。这样两个工程的地址契约就从“口头约定”变成了“代码约束”，编译器会在越界时给你翻脸。

2.3 IAP、ISP 与 ICP：三种下载方式背后的控制权差异

很多人把 IAP、ISP、ICP 混为一谈，其实它们控制权的归属完全不同。ICP 是通过 SWD 接口外接调试器，内核被调试器接管，Flash 由外部工具擦写，设备本身只是被操作对象。ISP 则依赖芯片出厂固化的 ROM 程序：上电时用特殊引脚电平触发，ROM 里的下载程序把串口初始化好，然后被动接收数据。ISP 的好处是不需要用户写任何代码，坏处是 ROM 程序固定，你没法往里面加协议，也没法通过无线网络触发。

IAP 的逻辑完全不同：Bootloader 是用户自己写的、跑在目标芯片上的程序，它接管串口、解析协议、调用 Flash 控制器完成擦写。远程在线升级只能是 IAP——因为只有 IAP 是“设备上已有软件在跑，还能自我更新”。有些方案做的是“应用代码触发后跳转到系统存储区再执行 ISP”，这本质上是 IAP 先完成跳转、ISP 再完成传输的混合流程，控制权在两层之间交接，交接时同样要处理中断向量表和栈切换，和 Boot 跳 App 没本质区别。

3. 升级协议核心机制：帧格式、CRC 覆盖范围与页缓冲为什么这样设计

分区画好之后，摆在面前的就是数据通道问题。远程升级协议要干的活很简单：把上位机手里的固件包，可靠地搬进目标 Flash。但“简单”二字在串口丢包、擦写耗时、断电干扰面前，变得相当不简单。

3.1 一帧升级报文拆开看：同步、命令、长度与校验的职责分离

自定义升级协议大多长这样：

#pragma pack(push, 1) typedef struct { uint8_t head0; // 0xA5 uint8_t head1; // 0x5A uint8_t cmd; // 命令字 uint16_t len; // data 长度 uint32_t addr; // flash 目标地址或包序号 uint8_t data[256]; // 载荷，最大长度受接收缓冲限制 uint16_t crc; // CRC16，覆盖 cmd ~ data 结束 } upgrade_frame_t; #pragma pack(pop)

帧头不参与 CRC 计算，这是我的惯例。原因是帧头用于字节级同步，如果同步本身受到干扰导致错位，CRC 救不了“这个字节是不是帧头”的问题。接收方的解析状态机先找帧头，再按长度字段收完整帧，最后算 CRC 决定 ACK 还是 NAK。注意len字段本身也出错的情况——一个常见的防御手段是给长度加一个累加和校验，或者干脆用“固定长度帧 + 分片”的方式，把每个分片长度固定成 64 或 128 字节，简化解析。

握手阶段，Boot 上电后先回传本机信息：Boot 版本、当前 App 版本、分区起始地址、页大小。上位机拿到这些参数后才能决定一帧装多少数据。比如页大小是 1KB，每帧数据段设为 256B，则 4 帧凑满一页再触发一次擦写；如果页大小是 512B，2 帧就够了。这个“页大小”参数必须由 Boot 上报，上位机不要硬编码，否则换一个型号的 MCU 就得改一次上位机逻辑。

3.2 边收边写为什么会翻车：从串口缓冲到 Flash 等待周期

很容易想到的实现是：每收完一帧，立刻解析、立刻擦写 Flash。但实际工程没人敢这么写，原因有两个。第一，串口波特率 115200 时，1KB 数据接收约耗时 90ms，而擦除一个扇区可能就要 20~50ms——在这 50ms 里 UART 依旧在接收后续数据，如果不用 DMA 双缓冲，数据必然溢出。第二，HC32 系列的 Flash 控制器在擦写期间，CPU 访问 Flash 会被硬件挂起等待；如果你的擦写代码本身还放在 Flash 里，就会出现“代码在执行，但每条指令取指都在等 Flash 忙完”的尴尬僵局。

所以常见的实现思路是：串口用 DMA 加双缓冲，收满一帧就切换缓冲，主循环处理上一帧，DMA 继续收下一帧；而 Flash 擦写函数整体搬到 RAM 执行，并且擦写期间关全局中断。关中断的理由很直接：擦写操作的命令序列需要 CPU 在确定的时间窗口内持续提供地址和数据，中断一进来，Flash 控制器状态机就可能被打乱。

__attribute__((section(".ramfunc"))) void flash_program_sector(uint32_t addr, uint8_t *buf, uint32_t len) { flash_unlock(); // 1. 按厂商序列解锁 Flash 控制器 flash_erase(addr); // 2. 擦除目标扇区 for (uint32_t i = 0; i < len; i += 4) { flash_write_word(addr + i, *(uint32_t *)&buf[i]); // 3. 字写编程 } flash_lock(); // 4. 重新加锁，防止误写 }

flash_unlock()这一步最容易被忽略。为了防止程序跑飞时误擦 Flash，芯片控制器默认是锁着的，必须写入固定序列的解锁键才能操作。不同型号解锁键值和顺序不同，以数据手册为准。这里说的“RAM 执行”需要链接脚本配合：.ramfunc段会被启动代码从 Flash 复制到 RAM，调用入口指向 RAM 里的副本。没有这个链接脚本配置，__attribute__((section(".ramfunc")))只是把函数排到特殊段里，不会自动搬进 RAM，这也是一个常见的“看起来配置了但没生效”的坑。

3.3 断点续传如何做到：参数区结构与“写完即记录”的顺序约定

远程升级的对象经常是低功耗无线节点，一发几百 KB，中途断链太常见了。没有断点续传，每次断链都从头传，用户体验和功耗双双爆炸。断点续传的关键不是“记住传了多少字节”，而是“记住了多少内容已经被可靠写入 Flash”。

Boot 的做法是：每成功写满一页（或一个扇区），就把当前的页号和一个累计 CRC 写到参数区。重新上电或断线重连时，上位机下发查询命令，Boot 回报“当前有效页号”，上位机从下一页继续发。这里有一个顺序细节：必须先写数据、读回校验通过，再更新参数区记录；如果先写参数再写数据，中途断电就会出现“参数说这页写好了，数据其实没写完”的错位。

参数区的写入也要讲究。Flash 的特性是只能 1 写成 0，擦除后才能恢复成 1，所以每次更新页号前必须擦除参数扇区。如果擦除后、写入前发生断电，参数区就处于“空”状态，Boot 会认为升级从未开始。一种稳妥的做法是连续记录两份参数，一份写成功后紧接着写另一份；启动时先读第二份，若第二份 CRC 非法则读第一份。这样任何时刻只有一份参数可能损坏，另一份总能给出上次的可靠进展。代价是参数区占用翻倍，但对于小容量 MCU 来说，这比整包重传划算得多。

4. 跳转与中断向量重定向：从 Boot 到 App 的临门一脚为何频繁摔死

数据写完、校验通过，最后一步是跳转。这一步代码量可能不到十行，却是整个 IAP 流程中翻车率最高的地方。很多人把跳转理解成“用函数指针调用 App 的 main”，这个理解差得很远——你跳的其实是 App 的复位向量，而不是某个函数。

4.1 跳转函数的三步：换栈顶、取复位向量、交 PC

typedef void (*entry_func_t)(void); #define APP_BASE 0x00001000u void jump_to_app(void) { uint32_t app_sp = *(volatile uint32_t *)APP_BASE; // 1. App 栈顶 uint32_t app_pc = *(volatile uint32_t *)(APP_BASE + 4); // 2. App 复位向量 entry_func_t entry = (entry_func_t)app_pc; __disable_irq(); // 关全局中断 SCB->VTOR = (uint32_t)APP_BASE; // 向量表重定向 __set_MSP(app_sp); // 切换主栈指针 entry(); // 跳到 App 复位向量，不再返回 }

这段代码做了三件事：第一，从 App 向量表起始地址读出第一个 4 字节，那是 App 链接时由启动文件定义的初始栈顶__initial_sp；第二，读出第二个 4 字节，那是 App 复位处理函数的入口地址；第三，把这类寄存器换成 App 的栈，再把 PC 直接交给复位向量。

注意最后一句后面不能再有任何代码，跳转是单向的。如果跳转后 App 复位函数 return 了，说明 App 栈被破坏或者启动代码异常，程序会回溯到执行栈里残留的地址——这通常表现为 HardFault 或者干脆跑飞。另一个容易踩的点是跳转前没有清外设中断的 pending 位。如果在 Boot 阶段串口收到了数据且中断使能，跳转瞬间中断触发，而 App 的向量表还没就绪，内核会去新的向量表读中断处理函数地址，读出来的要么是0xFFFFFFFF（Flash 擦除后的姿态），要么是 App 还没来得及初始化的某段代码，结果是死机。

4.2 VTOR 偏移与 M0+ 的中断向量重定向细节

M0+ 内核的向量表偏移寄存器 VTOR 位于0xE000ED08，写入的偏移值必须对齐到向量表大小向上取整的 2 的幂。工程实践中 App 起始地址通常已经按扇区对齐，天然满足这个要求——比如偏移0x1000远大于一个几十个中断的表的尺寸，肯定合法。

这里有个容易被忽略的点：VTOR 要在 Boot 里设一次，在 App 启动代码里再设一次。很多人只在 Boot 里设，App 里不设，结果单独烧录 App 时一切正常（因为 App 烧在0x00000000，默认偏移就是 0），配合 Boot 后中断全部进错门。App 的启动文件第一件事就应该执行类似SCB->VTOR = APP_BASE;的赋值，最好放在SystemInit()最前面。

另外，M0+ 没有中断向量转发的硬件辅助机制，部分芯片的 VTOR 实现还有勘误。如果你发现设置了 VTOR 后，某个外设中断依然进不了 App 的处理函数，一个常见的兜底方案是在 Boot 的向量表里预留一份“影子索引”：每个中断入口只写一行跳转指令，跳到 App 向量表里对应序号的处理函数。这等于用软件把中断二次转发，代价是每次中断多几个周期的跳转延迟。能用硬件 VTOR 解决就尽量别上这套，它属于最后的救命稻草。

提示：跳转前调用NVIC_ClearPendingIRQ清掉所有挂起的中断，比只__disable_irq()更彻底。只关中断不查 pending，某些型号会在 App 使能中断瞬间立刻触发一次陈旧中断。

4.3 App 主动回到 Boot：魔法数与软复位的约定

远程升级不只是 Boot 跳 App，更常见的是 App 在运行中收到升级指令，然后主动让位给 Boot。大多数设备没有物理按键，不可能让用户断电拨开关进 Boot。通用做法是“RAM 魔法数 + 系统软复位”，只要复位后 RAM 不被清零，Boot 就能识别这个“召唤”。

#define UPGRADE_MAGIC 0xA5A55A5Au volatile uint32_t *upgrade_flag = (volatile uint32_t *)0x2000F000u; void request_upgrade(void) { *upgrade_flag = UPGRADE_MAGIC; // 写魔法数 NVIC_SystemReset(); // 软复位 }

Boot 上电后先检查这个地址上的值是否等于魔法数，等于则直接进入升级模式，不等于才正常跳转 App。这个设计看起来简单，但有两个易碎点。其一，RAM 地址要选在启动代码的零初始化范围之外，否则 C 运行时的memset一段清零把你刚写的魔法数抹掉。常见的做法是在链接脚本里划出一个独立的NOINIT段，把该变量放进去。其二，系统软复位不保证复位所有外设，如果你在 App 里开着串口 DMA 就复位，Boot 起来时会发现 DMA 还在偷偷搬运数据，串口数据流一开始就是乱的。所以request_upgrade()里要先停 DMA、关串口，再写魔法数、复位。

5. 远程 IAP 避坑：五个让设备瞬间变砖的现场、根因与解法

远程升级代码最后说到底是“成功是应该的，失败是常态”的系统工程。以下五个问题我在不同项目里至少碰到过三次，每一条都按“现象 → 原因 → 解决”记录，当成一份维修手册用。

5.1 跳转过去就死机

现象：Boot 日志打印“jump to app ok”，但 App 没跑起来，程序卡死在默认中断处理函数里。

原因有三个，按优先级排序：一是 App 启动代码没有重新设置SCB->VTOR，中断一来读的还是 Boot 向量表；二是跳转前没有清外设挂起中断，串口或定时器在跳转瞬间产生中断；三是 App 链接脚本里的起始地址和 Boot 写死的APP_BASE不一致，两边各喊各的地址。

解决：跳转前依次做“关全局中断 → 清所有外设中断 pending → 设置 VTOR → 切 MSP → 跳转”。App 侧在SystemInit()最前面无条件设置一次 VTOR，不依赖任何外部条件。再做一层保险：把APP_BASE和 App 链接脚本的ORIGIN提取成同一个头文件，编译期校验，而非运行时猜测。

5.2 擦写 Flash 时主控“僵死”

现象：升级进度条卡在“正在擦除 App 区”，MCU 像死了一样，喂狗也没反应，只能断电重启。

原因：擦写代码还留在 Flash 里。Flash 控制器进入 busy 状态期间，CPU 从 Flash 取指会被挂起；此时碰巧某个中断到达（中断服务程序也在 Flash），或者擦除扇区与当前执行代码同属一个 Flash 区域，总线就僵住了。

解决：把flash_erase、flash_program_word等函数放进.ramfunc段，运行时拷贝到 RAM 执行。同时擦写期间__disable_irq()，确保命令序列不被中断打乱。验证方法很直接：在擦写函数入口点亮一个 GPIO，擦写过程中用示波器看 GPIO 波形，如果波形中途出现长时间高电平或跳变，说明有中断渗入或取指挂起。

5.3 CRC 校验玄学失败

现象：同一个升级包，上位机本地算 CRC 正确，Boot 每次都回 NAK。用串口抓包看，收到的字节和发送端逐字节一致，但 CRC 就是对不上。

原因：最常见的不是传输损坏，而是双方对“CRC 覆盖范围”的定义不一致。上位机可能把帧头也算进去了，Boot 按协议只算命令到数据；或者上位机用 CRC32，Boot 用 CRC16；再或者 DMA 缓冲区溢出丢了一个字节，导致后面所有包的字节偏移了一位，整体错位。

解决：把 CRC 范围写进协议文档的第一页，并在 Boot 端把“实际收到的数据长度”和“解析出来的长度字段”做比对，不一致直接 NAK 并要求重发。加一个包序号的累加和作为二级校验，能挡住绝大多数错位型错误。这里要切忌“看抓包改代码”的调试习惯——抓包工具显示的字节是链路层视图，CRC 校验发生在解析后，两者错位时抓包永远对，校验永远错。

5.4 升级中途断电，旧固件也没了

现象：升级到一半断电或断链，重启后 Boot 能进升级模式，但 App 区已经被擦空，没有任何可运行代码，只能上烧录器救砖。

原因：流程是“先擦除整个 App 区，再写入新固件”，擦除完成、写入未完成的窗口期里，任何打断都留下一个半成品 Flash。没有保留旧固件的备份区，就没有后悔药。

解决：容量允许时双 Bank（见第 6 章）。容量不允许时，至少把过程改成“按扇区边擦边写并做扇区级校验”，同时引入升级状态机：升级开始前清除“App 有效”标志，全部完成后置回，Boot 启动时发现无有效 App 就长驻升级模式等待重传，而不是跳转。最不济也要在芯片外部挂一颗 SPI Flash，升级前把旧 App 整包备份出去，失败时从外部搬回。成本不高，但能把变砖概率降到接近零。

5.5 看门狗在升级途中反复咬合

现象：升级到一半 MCU 自动复位，日志显示复位源是独立看门狗，升级永远失败在同一个进度点。

原因：擦除一个扇区的耗时超出了看门狗超时周期。有些看门狗默认超时才 100~300ms，而整扇区擦除加验证可能就逼近这个数；如果还连着擦了两三个扇区，必咬无疑。另一种情况是 Boot 等待上位机下一帧时没有喂狗逻辑，上位机稍微停顿几秒，狗就饿死了。

解决：喂狗点放在“完整接收一帧并且完成页写入”之后，而不是放在处理流程的中间。如果上位机暂停发送，Boot 应该进入一个空闲循环，间歇喂狗并维持升级会话，直到超时才判定断链。常见反面做法是“升级开始前直接把看门狗关掉”，这个方案要坚决抵制——升级包损坏时恢复机制完全失效，设备连 Boot 都进不了。看门狗是给你兜底的，不是给你添乱的。

注意：喂狗不能只加在协议解析处，要确认它兜住了最耗时的 Flash 擦写区间。如果你在flash_erase前后分别喂了一次狗，但一次擦写本身就要 150ms，而狗超时 100ms，那这狗白喂了。

6. 双分区还是单区回滚：远程升级最后一道设计取舍

最后要回答的问题不是“怎么升级”，而是“升级失败了怎么办”。这里没有银弹，只有按 Flash 容量做的取舍。双分区（A/B Bank）方案是把 Flash 一分为二，当前 App 在 A 区跑，新固件下载到 B 区，校验通过后置标志并复位，Boot 从 B 区启动；B 区跑起来后，App 业务层上报成功，下次复位再切回 B 区继续用。若 B 区起不来，Boot 超时自动回退 A 区。这个方案的确定性最强——任何时刻总有一个完整可用的 App 在 Flash 里，代价是可用 Flash 容量直接减半，对 HC32L136 这类小容量低功耗芯片来说，业务代码装不下就免谈。

我一般更倾向于“单区 + 降级策略”的现实组合：Boot 保持最小体积，App 区不做整区预擦除，而是按扇区边擦边写并逐扇区校验；升级开始前清掉有效标志，全部完成后置回。如果中途失败，Boot 进入恢复模式等待重新下发，不提供回退到旧版本的能力——这是容量受限下的妥协，但它保证设备永远有一条“重新升级”的活路，而不是只能寄回返修。

两种方案的本质差异是：双区把“回滚”做成了硬件级确定性，单区把“回滚”换成了“重试权”。对存量设备改造而言，能在不改硬件的前提下通过恢复模式保住设备在线，比追求完美回滚更务实。从那以后我每次做远程升级方案，都会强制自己先画一张“升级失败状态机”，哪条路径断了、设备落在哪个状态、用户还能不能救回来，全部画清楚了再动协议设计。这个习惯帮我挡掉了不止一次线上批量变砖的事故，希望帮到你。

本文还有配套的精品资源，点击获取