做嵌入式开发到了一定阶段，串口IAP基本是绕不开的坎。上个月我把一套基于华大MCU HC32F460的控制板从“只能仿真器烧录”改成“支持串口升级”，本想着STM32的IAP套路搬过来就能跑，结果发现HC32F460的中断向量表重定向有好几个坑，折腾两天才把跳转、中断和Flash擦写这条链路彻底理顺。这篇文章把我在HC32F460上做串口IAP的完整思路和实测经验梳理一遍，尤其把中断向量表重定向这块掰开揉碎讲清楚。
先说结论：HC32F460是Cortex-M4F内核，有标准的VTOR寄存器，理论上和STM32F4一样，改SCB->VTOR就能完成中断向量表重定向。但实际工程中，App工程的启动文件、SystemInit函数、链接脚本和Bootloader的跳转顺序都会影响这个操作，任何一环配合错了，轻则中断失灵，重则跳转即HardFault。所以这篇文章适合这几类人：正用HC32F460做产品、准备加IAP功能的工程师；在别的MCU上做过IAP但第一次接触华大的朋友；以及刚入行不久、想系统理解中断向量表重定向原理的嵌入式爱好者。
1. 动手之前先规划分区：Bootloader和App的“地皮”怎么划
1.1 为什么IAP本质是“一个Flash住两家”
MCU上电后从Flash起始地址开始执行，这是Cortex-M内核规定的行为。IAP要做的事情，就是在这个前提下让设备拥有“两个程序”：一个放在最低地址的Bootloader，负责接收固件、擦写Flash、跳转；另一个放在其他地址的App，负责真正的业务逻辑。产品升级时，App运行一段时间后通过串口把新固件发给Bootloader，Bootloader把App区擦掉重写，然后复位或跳转运行新App。
这就像一套房子住进两户人家：Bootloader是门口保安，App是住户。平时住户自己生活，需要换新家具（升级固件）时，保安接管钥匙，把住户房间清空再让新住户入住。而中断向量表重定向，就是解决“新住户搬进来之后，门铃（中断）还能不能敲对门”的问题。
1.2 HC32F460的Flash资源和我的分区方案
HC32F460主Flash容量因型号而异，我手里这颗512KB版本的主Flash从0x00000000开始，按8KB扇区组织（具体扇区尺寸请以你手里型号对应参考手册为准）。规划IAP分区时，主要考虑三点：Bootloader本身不能太大，但要放得下串口驱动、Flash驱动和协议栈；App区要足够大；最好给升级暂存或备份留一点余量。
我用的方案见下表：
| 区域 | 地址范围 | 大小 | 用途 |
|---|---|---|---|
| Bootloader | 0x00000000 ~ 0x0000FFFF | 64KB | 串口驱动、Flash擦写、跳转逻辑 |
| App | 0x00010000 ~ 0x0007FFFF | 448KB | 业务程序、中断向量表 |
| 升级标志区 | App区末尾4字节 | 4B | 记录升级状态（可选） |
64KB的Bootloader对于串口IAP来说非常宽裕，甚至可以放一个简化的命令行交互。App区448KB对大多数业务固件绰绰有余。如果你设备Flash只有256KB，可以压缩Bootloader到32KB，App从0x00008000开始，道理一样。
1.3 升级链路全貌：三方协作
一次完整串口升级涉及三方：上位机、Bootloader、App。
App正常工作，收到上位机的“进入升级模式”指令后，置一个升级标志然后软复位。Bootloader上电后检查升级标志，有效就进入接收模式，通过XMODEM或者自定义协议把固件包收下来，逐包擦写Flash，收完校验通过后清除升级标志，最后跳转App。如果升级标志无效，Bootloader直接跳App，整个过程对用户透明。
这个流程里最容易出问题的节点有两个：一是Bootloader收完数据后跳转App的那一刻，二是App运行后中断是否还能正常工作。这两个节点都跟中断向量表重定向直接相关，后面重点展开。
2. 中断向量表重定向的原理：CPU怎么知道中断去哪找人
2.1 向量表其实是张“地址清单”
Cortex-M4内核每次遇到中断，都要去内存的固定位置查一张表——中断向量表。表里每一项是一个4字节的入口地址，位置0存的是初始主栈指针MSP，位置1存的是复位后第一条指令地址，位置2开始依次是NMI、HardFault、MemManage等异常入口，再往后才是外设中断（USART、TIM、EXTI之类）。
内核查表靠的是向量表偏移寄存器VTOR（地址0xE000ED08）。芯片上电时VTOR默认值是0，也就是从0x00000000开始查表。只要程序不跑出Flash最低地址，这套机制永远不会出错——因为编译时Bootloader和App是分开编译的，Bootloader的中断向量表一定在0x00000000，App的就不一定了。
问题恰好出在这：App被链接到0x00010000之后，它的中断向量表也在0x00010000，但内核复位后VTOR仍然是0。如果不改VTOR，App期间一旦产生中断，内核去0x00000000取到的就是Bootloader的向量表，拿到的中断处理函数地址全是Bootloader的，轻则中断响应错乱，重则直接HardFault。
2.2 重定向做的一件事：把VTOR指向App向量表
所以“中断向量表重定向”本质上就一句话：把SCB->VTOR改成App的起始地址。
SCB->VTOR = APP_START_ADDR;别小看这一行。执行时机、配套的读写权限、以及App工程自身的启动配置，任何一个环节没配合好，这行代码就是白写。
2.3 重定向的两种时机：Bootloader跳转前 or App启动后
网上能找到的IAP例程，设置VTOR的位置五花八门。有的放在Bootloader跳转前，有的放在App的main开头。我在工程里两种都试过，结论是：取决于你想让“谁”负责这段逻辑。
放在Bootloader跳转前：跳转前先把VTOR指到App向量表，App的Reset_Handler从头到尾都运行在“正确的向量表环境”里。哪怕在App的C库初始化阶段就来一个中断（比如看门狗、外部信号），内核也能正确找到App的中断入口。这是我最推荐的方式。
放在App的main开头：代码写起来直观，但存在一个空窗期——从App的Reset_Handler执行到main函数开头，如果期间有任何中断发生，VTOR仍然是Bootloader的值，中断会错误地进入Bootloader的处理函数。更麻烦的是，如果这个中断不该被Bootloader处理，固件行为就不好预测了。
所以我的建议是：Bootloader里设置VTOR为主，App的main里再写一行同样的代码作为双保险（防止调试过程中单独烧App测试时出问题）。
3. Bootloader侧的跳转实现：从关中断到跑飞还差几步
3.1 跳转前的“收尾工作”清单
跳转App不是一句((void(*)(void))(*(uint32_t*)0x10004))()就能解决的。跳转前必须做这些事：
- 关掉全局中断：
__disable_irq()，防止跳转过程中被打断； - 停掉SysTick：SysTick是Cortex-M内核里的定时器，它的中断可能会在跳转后踩到App的向量表切换窗口；
- 把已经打开的外设全部复位到默认状态：串口、定时器、ADC、DMA等，尤其是DMA，如果跳转时还有DMA在搬运数据，App初始化时容易出诡异问题；
- 关闭和复位所有使能的中断源，避免跳转后有挂起中断被意外响应。
这些“收尾”工作在IAP文档里经常被一笔带过，但实际踩坑时大部分问题都出在这里。华大官方驱动库的外设DeInit函数基本都能用，跳转前统一调用一遍对应的DeInit最稳妥。
3.2 校验App固件的有效性：防止跳到空白区
Bootloader在跳转前要确认App区确实有程序，否则跳过去就是执行0xFF，硬要运行必然HardFault。我用的是最常用的“双验证”：
一是栈指针验证：App的向量表首元素是初始MSP，对于HC32F460这类Cortex-M4 MCU，SRAM地址一般在0x20000000以后，所以读出来的值高12位应该是0x200。实际写代码时，检查它是否落在合法的SRAM地址范围即可。
二是复位向量验证：App的向量表第二个元素是Reset_Handler地址，读出来应该在Flash的App区地址范围内，即0x00010000到Flash末尾之间。这两项检查都过了，才执行真正的跳转。
如果校验失败，Bootloader不能干等着，应该回到串口接收状态继续等固件，或者进入一个简单的错误提示流程。
3.3 跳转代码：完整可直接用的版本
以下是经过实测的Bootloader跳转函数，KEIL/AC5编译器下直接用：
#define APP_START_ADDR 0x00010000u typedef void (*app_entry_t)(void); static void boot_jump_to_app(void) { uint32_t app_stack = *(volatile uint32_t *)APP_START_ADDR; uint32_t app_reset = *(volatile uint32_t *)(APP_START_ADDR + 4u); app_entry_t app_entry; /* 1. 关全局中断，停内核定时器 */ __disable_irq(); SysTick->CTRL = 0u; /* 2. 检验固件有效性 */ if ((app_stack & 0xFFF00000u) != 0x20000000u) { return; } if ((app_reset & 0xFFF00000u) != 0x00000000u) { return; } /* 3. 重定向中断向量表到App区 */ SCB->VTOR = (uint32_t)APP_START_ADDR; /* 4. 设置主栈指针，确保在MSP状态跳转 */ __set_MSP(app_stack); __set_CONTROL(0u); __ISB(); /* 5. 跳转到App的Reset_Handler */ app_entry = (app_entry_t)app_reset; app_entry(); }提醒一点：部分编译器/优化等级下，__set_CONTROL(0u)之后需要紧跟__ISB()指令同步流水线。如果不加ISB，某些Cortex-M系列上会出很隐蔽的时序问题，跳转后第一次中断行为异常。
3.4 跳转即HardFault的三个高频原因
我把实测中遇到的HardFault原因整理了一下，基本都是这四类之一：
一是跳转前没有把外设中断源清干净。全局中断__disable_irq()只是屏蔽了中断响应，NVIC里挂起的中断标志还在。跳进App后App一旦开中断，挂起的Bootloader中断会立刻触发，而此时App可能还没初始化完对应外设。
二是链接脚本和实际下载地址不一致。App编译时ROM起始地址是0x00010000，但如果烧录工具把固件烧到了0地址，或者Bootloader跳转时读的是0地址，那读出来的vector全是Bootloader自己的，校验直接不过。
三是跳转目标选错了，跳到了main而不是Reset_Handler。跳到main会绕过启动文件的.data/.bss段初始化，全局变量全是垃圾值，跑起来必然异常。一定要跳Reset_Handler。
四是栈环境不对。如果之前的代码在用PSP（进程栈）而跳转前没切回MSP，C库初始化会往一个不存在的栈上压数据，直接炸。前面代码用__set_CONTROL(0)就是干这个的。
4. App侧工程配合：链接脚本、SystemInit和VTOR的三角关系
4.1 先改链接地址：App的“地址出身”决定一切
App固件能否在0x00010000正确运行，首先取决于编译时链接器是否真的把代码放到了0x00010000。用Keil MDK的话，主要有两个地方要改：Target页的IROM1起始地址改为0x00010000，Size改为0x70000；以及分散加载文件（.sct）里的加载域和执行域起始地址。
IROM1改完后，Keil会自动生成对应的.sct，不需要手改。但如果你的工程是手动管理的分散加载文件，就要注意.sct里LR_IROM1和ER_IROM1的地址必须同步改，我见过有人只改了LR段、执行域还是0，结果下载后代码和向量表全乱套。
用IAR的朋友对应改链接配置里的ROM起始地址即可。GCC环境改linker script里的FLASH ORIGIN。原理都一样：让链接器认为代码就住在0x00010000，生成的向量表、绝对寻址、函数地址才全部基于这个地址。
4.2 SystemInit会不会覆盖VTOR？必须亲手查一遍
这是F460 IAP里最容易被忽视的坑。很多MCU厂家的SystemInit函数末尾会主动设置VTOR，比如把VTOR写回Flash基地址0。如果你在Bootloader跳转前已经设好了VTOR=0x00010000，App启动后SystemInit里这行代码一跑，VTOR又被改回0，App中断全部指回Bootloader向量表，表现就是“App能跑，但任何中断都不进App的中断函数”。
不同MCU、不同版本的系统初始化文件行为不一样，所以拿到华大的system_hc32f460.c之后，先搜索里面有没有“VTOR”关键字。有的话，看清楚赋的是固定值还是带VECT_TAB_OFFSET的宏。如果它把VTOR设回了固定的FLASH_BASE，我建议改成：
#define VECT_TAB_OFFSET 0x00010000u SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET;或者干脆屏蔽掉SystemInit里的VTOR赋值，改到main开头统一处理。
4.3 最稳妥的VTOR设置位置：App的main第一行
这一点我犹豫过。前面说推荐Bootloader跳转前设置VTOR，但严谨的做法是：App的main函数第一行也设置一次。原因有两个：一是开发阶段经常单烧App测试（不经过Bootloader），如果App自己不设置VTOR，单烧时中断全废，排查半天才发现没设VTOR；二是万一某版Bootloader跳转前忘了设置，App这一行还能兜底。
也就是说，成熟的工程里VTOR设置要“双保险”：Bootloader跳转前写一次，App的main第一行再写一次。每次写之前把VTOR当前值通过串口打印出来，还能快速确认到底哪一层把VTOR改坏了。
App侧代码：
int main(void) { SCB->VTOR = APP_START_ADDR; /* 后面的业务初始化... */ }注意放在SystemInit之后、任何中断使能之前。如果SystemInit又重置了VTOR，main里这句就是最后的正本清源。
4.4 启动文件是否有特殊处理：检查Reset_Handler
App工程的启动汇编文件里，Reset_Handler通常会先调用SystemInit，再进__main。有些启动文件会在调用SystemInit之前操作向量表，但大多数Cortex-M的启动文件不管VTOR，靠SystemInit管。对HC32F460来说，启动文件的默认流程问题不大，但建议把反汇编打开看一眼，确认启动代码里没有“把中断向量表复制到SRAM”这种操作。有些老教程喜欢把向量表搬到SRAM再运行，对应地还要改VTOR到SRAM地址，这种玩法在IAP场景里纯属增加复杂度，完全没必要。
5. 串口升级协议与Flash擦写：从收到字节到写进Flash
5.1 协议选型：自定义协议还是XMODEM
Bootloader串口协议有两条路：自己定一套，或者用现成协议。
自己定协议自由度最高，但你要处理分帧、粘包、校验、重传、超时，一套完整的健壮协议写下来不轻松。我建议Bootloader场景直接用XMODEM，理由很简单：成熟、公开、校验可靠、工具现成。XMODEM把数据分成128字节（或1KB）的包，每包带编号，支持CRC16校验，接收方每包回ACK/NAK，发送方等不到ACK会自动重传。上位机不用自己写，XCOM、SSCOM、SecureCRT都内置XMODEM发送功能。跑一趟下来，Bootloader接收代码的核心就是“收包-校验-写Flash-回ACK”，逻辑非常清爽。
如果固件大于1MB或者网络条件差，可以再考虑自定义协议，但那属于中后期优化。首版IAP用XMODEM，性价比最高。
5.2 串口接收：轮询够用，但DMA+空闲中断更稳
Bootloader阶段串口接收，工程上有两种主流做法。简单方案是轮询加超时：串口中断每收一个字节塞进环形缓冲区，主循环每隔一小段时间检查缓冲区是否有完整帧。复杂但高效的是DMA+空闲中断：DMA把串口数据搬到内存，总线空闲时产生空闲中断，主循环一次性拿整帧数据。
实测下来，如果Bootloader只做升级不做别的，轮询加超时完全够用。HC32F460的主频200MHz，处理串口那点数据量绰绰有余。上DMA反而要注意DMA传输结束中断和空闲中断的时序配合，调试周期更长。我首版用的就是串口中断+环形缓冲+XMODEM状态机，稳定性很好。
唯一要提醒的是：串口波特率不要贪高。IAP这种长传输场景，115200是安全选择，230400到460800也可以，但USB转串口芯片型号不一样，高位波特率丢包率差异很大。量产环境里用CH340、CP2102的时候，建议先做30分钟持续传输的压力测试，确认不丢包再定波特率。
5.3 Flash擦写：解锁、按扇区擦、注意等待周期
HC32F460的Flash擦写和所有MCU一样，有几个必须遵守的规矩：
第一，操作前要解锁Flash。华大的驱动库里有FLASH_Unlock/Lock接口，忘了解锁，擦写操作会被硬件拒绝，返回错误甚至直接触发异常。
第二，擦除和编程的最小单位不同。擦除按扇区（8KB），编程可以按字节或字/双字。写App固件时，先把整片App区涉及的扇区全部擦掉，再逐段写入，千万别写一段擦一段——擦除会清掉整个扇区，后擦的操作会把前面写的数据也干掉。
第三，Flash擦写期间CPU取指可能停摆。HC32F460在擦写内部Flash时，Flash控制器会暂停CPU读取，如果此时程序正好运行在Flash里，会停下等待。Bootloader在擦写App区前，最好把接收缓冲区和关键临时变量放到RAM里，避免擦写过程中出现奇怪的异常。
第四，每次重新擦写前要把上一次可能的半包数据清掉。我遇到过重传升级时，App区前半段是新数据、后半段还是旧数据的混合体，跑起来各种随机崩溃。后来加了“升级前全片擦除+每包写前校验扇区状态”两步，问题才根治。
6. 实测排错记录：跳转失败、中断失灵、串口丢包怎么查
这一节把我在HC32F460 IAP过程中实际遇到的三个问题完整复盘，每个都包含现象、定位过程和最终的解决手段。
6.1 现象一：跳转进入App后立刻HardFault
第一次联调，Bootloader能从串口收到固件，写Flash也提示成功，但一跳到App就进HardFault。用仿真器跟进去看，HardFault发生在App的Reset_Handler里，具体位置不固定，一会儿在SystemInit里面，一会儿在__main里面。
定位过程：先检查了App的栈指针和复位向量，都在合法范围内；再把Bootloader的跳转代码简化到只剩“设置MSP、跳Reset_Handler”，还是一样。最后想到我还挂着一个定时器中断和串口DMA中断，虽然跳转前调用了__disable_irq，但这两个中断的NVIC挂起位还在。App复位后SystemInit还没跑完，用户代码也没开中断，照理不会响应中断……问题出在启动汇编里有过一次开中断动作，挂起的中断立刻乘虚而入。
解决：跳转前不仅关全局中断，还要把所有已使能的外设中断在NVIC里明确清除，并调用对应外设的DeInit复位外设。DMA的通道也全部失能。改完再跳，HardFault消失。
6.2 现象二：App能跑，但USART中断、外部中断全部没反应
这个问题比HardFault更难发现。App业务看起来正常：主循环在跑、LED在闪、按键轮询也有效。但所有依赖中断的外设全部罢工，串口收不到数据，外部中断也没反应。
定位过程：先用仿真器在中断函数里打断点，完全进不去；检查NVIC配置，中断源和优先级都使能了；再查看SCB->VTOR的值，发现它是0，而不是0x00010000。问题清楚了：Bootloader跳转前明明设置了VTOR，但App的SystemInit执行时把它覆盖回0了。
解决：在App的main函数第一行强设SCB->VTOR = APP_START_ADDR，同时把system_hc32f460.c里可能重置VTOR的代码段注释掉，双保险做完之后，所有中断恢复正常。建议所有做F460 IAP的朋友先看一下自己用的HC32驱动库版本，不同版本的SystemInit行为不完全一样。
6.3 现象三：串口收到的固件包总有零碎丢包
现象是：用XCOM发送固件，Bootloader能收能写，但写进Flash的程序跑不起来，对比hex发现中间有些字节错了。再测，发现丢包位置没有规律，但是只要把波特率降到115200，丢包率明显下降；用CH340和CP2102两个芯片表现也不同。
定位过程：用逻辑分析仪看波形，发现部分数据帧的电平转换时有毛刺，再排查发现是USB转串口线质量一般，加上Bootloader接收端没有做滤波，高波特率时采样点容易踩到跳变沿。这属于物理层问题，不是协议问题。
解决：固定使用质量可靠的USB转TTL线，波特率定在115200，XMODEM本身带CRC校验，只要不是物理链路烂到每包都错，都能通过重传机制自动纠正。如果量产需要更高波特率，建议在Bootloader里加个简单的“波特率探测”逻辑，上位机先发特定字符序列，Bootloader自动适配，而不是写死一个高波特率。
6.4 调试工具怎么选：RTT View的价值
IAP调试阶段，我强烈建议用SEGGER RTT View。理由不用多说：不占额外串口、速度快、几KB的缓冲就能打海量日志。在Bootloader和App里各放一个RTT打印函数，跳转前后的日志一接上，问题定位快很多。
我调试6.2问题时，就是在Bootloader里打印跳转前VTOR值、App的SystemInit之后打印VTOR值，两个一对比，立刻看清SystemInit把它清零了。这在纯串口日志下也能做到，但RTT不掉串口线、不干扰IAP通讯，体验好太多。唯一注意：RTT走的是SWD调试口，调试完量产固件里记得把RTT相关代码关掉或用宏隔离。
7. 量产级IAP要补的几道保险：掉电回滚、升级标志和看门狗
7.1 升级写一半断电了怎么办：双备份和升级标志
串口IAP最怕的不是升级失败，而是升级过程中断电。刚擦完App区还没写完新固件就断电，设备变成一块砖。如果只靠JTAG救砖，量产现场就麻烦了。
低成本的做法是规划一个“临时App区”或者完整的“备份App区”。Bootloader先把新固件收完、校验通过之后，再决定是否覆盖当前App；或者始终保留上次能用的App，新固件写入另一块区域，下次启动时再切换。对Flash容量紧张的产品，至少要做到“升级标志+超时回退”：Bootloader发现超过一段时间没收到完整固件包，就放弃升级，继续跑旧App。
HC32F460这种Flash普遍在256KB以上的MCU，双备份对大多数应用都是可接受的，无非是App可用空间减半。真没法做双备份的产品，我也会坚持“先收完整包再擦写”的思路，避免边收边擦、断电后新老全无。
7.2 升级标志的实现：放Flash末尾还是内部EEPROM区
升级标志位的作用是让Bootloader知道“上电后进入升级模式还是直接跳App”。常见位置有两个：外部EEPROM，和主Flash末尾专门留的扇区。
用外部EEPROM的好处是擦写次数多、不占用主Flash，但要额外器件和I2C/SPI驱动。用主Flash末尾区域的好处是省器件，但要注意：App区擦写时如果连标志区一起擦掉，Bootloader就无法判断是否该进入升级模式。所以标志区建议独立放在App区之外，比如Bootloader区最末尾的半个扇区，或者独立占一个扇区，与App区物理隔离。
我采用的方案：Bootloader区最后一个扇区留出几个字节作为标志区。App正常收到升级请求后向这个地址写“0xA5A5A5A5”，然后软复位；Bootloader启动检查到这个值就进入升级模式，进入后立刻把标志清除，防止意外再次复位又进升级模式。
7.3 看门狗怎么放：Bootloader里尽量温和，App里可以严格
独立看门狗在IAP里是个双刃剑。App主程序可以用看门狗防跑飞，但Bootloader升级过程中如果断电或卡在某步，看门狗复位虽然能救回设备，但也会打断正在进行的Flash擦写，可能让Flash状态更糟。
我的建议是：Bootloader阶段不要开独立看门狗，或者开一个超时时间很长（比如几秒）的窗口，并且在Flash擦写完成后才喂狗。App阶段正常开启看门狗，跑飞时系统复位回Bootloader。Bootloader看到升级标志无效，直接跳旧App，设备自动恢复。这样既保住了看门狗的防跑飞能力，又不会在Flash擦写的关键时刻被咬一口。
这次做HC32F460串口IAP，最大的体会就是：中断向量表重定向看似只有一行代码，实际是Bootloader、App工程、链接配置和启动文件四者之间的配合问题。先把原理吃透，再顺着排查链路一步步验证，比盲目复制例程靠谱得多。后面再让我做其他MCU的IAP，这套“分区规划—跳转收尾—双保险VTOR—协议选型—异常排查”的流程，大概率还是会继续用下去。
