1. 项目概述为什么AB分区OTA在STM32F103上不是“锦上添花”而是“生死线”你手头有一块跑着温控算法的STM32F103C8T6最小系统板固件已经稳定运行了八个月。某天客户突然要求加一个远程参数校准功能你改完代码、编译通过、用J-Link烧录测试——一切OK。第二天一早产线反馈50台设备全部变砖串口无响应J-Link连不上SWD引脚测不到时钟。你拆开其中一台发现Flash里前4KB全是0xFFBootloader跳转地址被擦成了0x00000000。这不是运气差这是单一分区OTA的必然宿命。AB分区OTA对STM32F103这类资源极度受限的Cortex-M3芯片而言从来就不是什么高大上的“在线升级黑科技”它是一套用空间换时间、用冗余保生存的硬核容错机制。它的核心逻辑非常朴素永远保留一份已知可用的完整固件A区所有升级操作都在另一份空白区域B区进行只有当B区写入完成、校验无误、且能成功跳转执行后才把启动指针从A切到B。哪怕升级中途断电、通信中断、甚至Flash写入一半被拉闸下一次上电芯片依然会从A区冷启动设备照常工作——用户根本感知不到后台发生过一场“生死劫”。这背后牵扯的全是硬骨头STM32F103的Flash擦除必须按页1KB/页而标准库v3.50里没有现成的AB分区管理API它的SRAM只有20KB放不下双份固件更容不下一个完整的压缩解包器它的Bootloader必须自己重写不能依赖ST官方提供的UART Bootloader那个只支持串口下载不支持应用层触发的OTA流程最要命的是一旦Bootloader跳转逻辑出错或者APP固件入口地址没对齐到4字节边界就会直接卡死在HardFault_Handler连调试信息都吐不出来。网上那些“5分钟搞定STM32 OTA”的教程90%都省略了Flash页擦除时序、向量表偏移重映射、IAP校验失败后的回滚策略这些真正决定成败的细节。本教程不讲虚的只带你从零开始一行一行敲出能在真实产线环境扛住断电、通信抖动、Flash老化等恶劣条件的AB分区OTA实现。适合所有正在用STM32F103做工业传感器、智能电表、楼宇控制器的工程师也适合被“error: flash download failed - target dll has been cancelled”折磨到怀疑人生的嵌入式新手——这个错误90%是因为你在未关闭全局中断的情况下擦除了包含中断向量表的Flash页。2. 整体架构设计与关键取舍为什么放弃“优雅”选择“粗暴可靠”2.1 分区规划不是数学题是物理约束下的妥协STM32F103C8T6的Flash总容量为64KB但实际能用于APP的远少于这个数。我们先画一张真实的内存地图地址区间大小用途关键约束0x08000000–0x08003FFF16KBBootloader区必须包含复位向量、中断向量表、IAP擦写函数、跳转逻辑需预留至少2KB应对未来功能扩展0x08004000–0x0800BFFF32KBA区主程序存放当前运行的APP固件起始地址必须是Flash页边界0x08004000是第16页起始0x0800C000–0x08013FFF32KBB区升级区存放待升级的新固件大小必须≥A区否则无法容纳新版本你可能会问为什么A/B区各32KB64KB Flash减去16KB Bootloader只剩48KB平分就是24KB。但这里有个致命陷阱STM32F103的Flash擦除是以页Page为单位每页1KB。如果你把A区设为24KB0x08004000–0x0801BFFF那它跨越了24个页。而OTA升级时B区需要先整片擦除再写入。如果B区也按24KB规划它就必须从0x0801C000开始但0x0801C000之后只剩12KB空间到0x08027FFF根本不够放一个24KB的固件。更糟的是0x0801C000不是Flash页边界第28页起始是0x0801C000错第28页是0x0801C000查RM0008手册Table 11第28页起始地址是0x0801C000不是0x0801C000翻手册确认第0页0x08000000第1页0x08000400…第28页是0x0800B000不对重新计算每页1KB0x400字节第n页起始0x08000000 n×0x400。第16页0x0800000016×0x4000x08001000错了0x08000000是第0页0x08000400是第1页所以第16页是0x0800000016×0x4000x08001000但0x08001000是第16页查手册Table 11明确写着STM32F103xx medium-density devices have pages of 1 Kbyte, starting from address 0x08000000 (page 0), 0x08000400 (page 1), ..., up to 0x0800FC00 (page 63)。所以第16页起始是0x0800000016×0x4000x080010000x080000000x10000x08001000对。但我们的Bootloader要占16KB即16页0x0000–0x3FFF所以Bootloader结束于0x08003FFF下一页第16页起始是0x08004000。这才是A区的起点。因此A区从0x08004000开始占32页32KB到0x0800BFFF结束。B区紧接着从0x0800C000第28页起始开始占32页到0x08013FFF结束。这样A/B区都是整页对齐擦除时只需调用FLASH_ErasePage(0x08004000)和FLASH_ErasePage(0x0800C000)不会跨页误擦。这个规划不是拍脑袋是手册白纸黑字的物理约束倒逼出来的唯一解。提示很多初学者栽在分区地址不对齐上。例如把A区设为0x08004100结果擦除时FLASH_ErasePage(0x08004100)会自动向下取整到0x08004000把Bootloader末尾1KB也擦掉了。务必用地址0xFFFFF000对齐到4KB或查手册确认页边界。2.2 Bootloader与APP的职责切割谁该干脏活谁该享清福一个健壮的AB分区系统本质是两个独立程序的精密协作。它们之间必须有清晰的“楚河汉界”否则就是灾难的开始。Bootloader的铁律绝不主动修改自身代码Bootloader的Flash区域0x08000000–0x08003FFF在运行时必须是只读的。任何升级操作只能擦写A区或B区Bootloader自身代码和数据必须固化。只做三件事a) 上电后检查B区有效性CRC32校验魔数验证b) 若有效则跳转至B区c) 若无效则跳转至A区。其余所有事接收升级包、解析、写Flash、校验均由APP发起并控制。向量表重映射是生命线当APP在B区运行时其中断向量表在0x0800C000但CM3内核默认从0x08000000取向量。必须在APP启动时执行SCB-VTOR FLASH_BASE | 0x0000C000;将向量表基址重映射到B区首地址。否则任何中断如SysTick、USART都会跳转到Bootloader的中断服务程序导致不可预测行为。APP的契约义务提供标准化的IAP接口在APP的main()之前必须定义一个全局函数指针数组暴露IAP_WriteFlash,IAP_ReadFlash,IAP_GetAppStatus等函数。Bootloader通过这个接口与APP通信而不是直接调用APP内部函数。承担全部升级逻辑APP负责通过UART/USB/以太网接收升级包通常为bin文件将其解包、校验、写入B区指定地址并在写入完成后设置一个标志位如在B区末尾写入特定魔数0xDEADBEEF。安全退出机制APP在完成B区写入并校验无误后不能直接跳转。必须先设置一个“待重启标志”例如在备份SRAM或Flash特定位置写入0xAA55然后调用NVIC_SystemReset()软复位。复位后Bootloader读取该标志确认应从B区启动。这种设计看似繁琐实则是为了隔离风险。如果Bootloader自己去实现UART接收和Flash写入一旦UART驱动有bug导致死循环整个系统就彻底锁死连J-Link都无法连接。而让APP来干即使APP升级逻辑崩溃Bootloader依然能保证从A区启动设备可恢复。2.3 为什么不用HAL库坚持用标准库v3.50网上大量教程推荐用STM32CubeMX生成HAL库工程来做OTA。我试过也踩过坑。HAL库的HAL_FLASHEx_Erase()函数封装了页擦除逻辑看起来很美。但问题在于HAL库的Flash驱动默认启用了FLASH_FLAG_EOP操作完成和FLASH_FLAG_WRPRTERR写保护错误中断。在OTA升级过程中如果恰好有SysTick中断或其他外设中断抢占了Flash擦除操作而你的中断服务程序里又调用了HAL_Delay()它依赖SysTick就会陷入死锁——因为SysTick被挂起HAL_Delay()永远等不到超时。标准库v3.50的FLASH_ErasePage()是纯轮询实现不依赖任何中断只要在擦除前关闭全局中断__disable_irq()擦除后开启__enable_irq()就能100%避免此类竞态。虽然代码多写几行但换来的是在产线7×24小时运行的绝对可靠。对于资源紧张的F103少一个中断服务程序就少几百字节RAM占用这笔账必须算清楚。3. 核心细节解析与实操要点从向量表重映射到CRC32校验的每一处陷阱3.1 向量表重映射不是配个寄存器就完事向量表重映射Vector Table Relocation是AB分区能跑起来的第一道门槛。很多教程只告诉你一句SCB-VTOR 0x0800C000;然后就没了。但实际中这句话放在哪里决定了你是成功还是HardFault。错误做法在APP的main()函数第一行就写SCB-VTOR 0x0800C000;。后果此时C库的初始化如.data段复制、.bss段清零尚未完成SCB结构体可能还未被正确映射访问SCB-VTOR会触发UsageFault。正确做法在APP的启动文件startup_stm32f10x_md.s中在Reset_Handler标签之后、跳转到main之前插入重映射代码。具体步骤打开startup_stm32f10x_md.s找到Reset_Handler标号。在LDR R0, SystemInit指令之后、LDR R0, main指令之前插入LDR R0, 0x0800C000 ; B区向量表起始地址 MOV R1, #0x20000000 ; SCB-VTOR寄存器地址 (0xE000ED08) STR R0, [R1, #8] ; 将R0值写入VTOR (偏移8字节)确保SystemInit()函数中没有调用任何会修改SCB-VTOR的代码标准库v3.50的SystemInit不会动它。为什么必须在这里做因为Reset_Handler是CPU复位后执行的第一段代码此时所有硬件寄存器都处于初始状态SCB基地址0xE000ED00是确定的VTOR寄存器偏移0x08可以安全访问。等C库初始化完成栈指针、全局变量都就绪了再跳进main就不会有地址访问异常。注意SCB-VTOR的值不是直接写入地址而是写入FLASH_BASE | offset。offset必须是256字节的整数倍即低8位为0。B区向量表必须从0x0800C000开始因为0x0800C000 0xFFFFFF00 0x0800C000满足对齐要求。如果B区从0x0800C100开始VTOR写入0x0800C100会导致内核从错误地址取向量必死无疑。3.2 Flash页擦除的时序与保护别让“擦得干净”变成“擦得绝望”STM32F103的Flash擦除不是瞬间完成的它需要时间。根据手册擦除一页1KB典型时间为20ms最大可达40ms。如果你在擦除后立刻尝试写入或者在擦除过程中响应了中断就会触发FLASH_SR_BSY忙标志导致后续操作失败。实操要点擦除前必须关闭所有可能触发Flash操作的中断不仅仅是SysTick还包括任何使用HAL_Delay()、osDelay()如果你用FreeRTOS的定时器。最稳妥的做法是擦除全程关闭全局中断__disable_irq(); FLASH_ErasePage(0x0800C000); __enable_irq();。擦除后必须轮询等待完成标准库FLASH_ErasePage()函数内部已经包含了轮询FLASH_SR_BSY的逻辑但它返回的是FLASH_Status。你必须检查返回值FLASH_Status status FLASH_ErasePage(0x0800C000); if(status ! FLASH_COMPLETE) { // 擦除失败可能是写保护未解除或电压不稳 while(1); // 进入死循环便于调试 }写保护解除是前提F103的Flash默认是写保护的。在擦除或写入前必须调用FLASH_Unlock()操作完成后必须调用FLASH_Lock()上锁。FLASH_Unlock()需要向KEYR寄存器写入两个特定密钥0x45670123, 0xCDEF89AB顺序不能错否则锁死。我见过太多人因为复制粘贴时漏掉一个0导致Flash再也无法写入只能用J-Link的“Unlock Flash”功能救急。一个血泪教训某次调试我把FLASH_Unlock()放在了main()里然后在while(1)循环里反复擦写B区做测试。结果第一次擦写成功第二次就报FLASH_ERROR_WRPRT。原因FLASH_Lock()只锁了一次但FLASH_Unlock()需要每次操作前都调用。正确的模式是FLASH_Unlock(); FLASH_ErasePage(0x0800C000); // ... 写入数据 ... FLASH_Lock(); // 每次操作后立即上锁3.3 CRC32校验为什么不用简单的累加和OTA升级的核心信任链始于对B区固件完整性的校验。很多人图省事用一个16位累加和sum data[i]来校验。这在实验室环境下可能没问题但在产线一个电源纹波、一次EMI干扰就足以让累加和“碰巧”通过。CRC32是工业级标准它能检测出所有单比特错误、所有双比特错误、所有奇数个比特错误以及长度≤32比特的突发错误。实现要点校验范围必须精确不是校验整个B区0x0800C000–0x08013FFF而是校验B区中APP固件的实际长度。假设你的APP.bin文件大小为28672字节0x7000那么校验范围就是0x0800C000–0x08012FFF0x0800C000 0x7000 - 1。多校验一个字节CRC值就不同。校验值存储位置将计算出的CRC32值4字节写入B区的固定偏移例如B区末尾的4个字节0x08013FFC–0x08013FFF。Bootloader启动时先读取这4个字节作为期望值再对B区固件主体0x0800C000–0x08012FFF重新计算CRC32两者比对。字节序陷阱STM32是小端机Little-Endian。CRC32计算函数返回的uint32_t值其最低字节LSB存储在最低地址。因此当你把crc_value写入Flash时应该用uint8_t crc_bytes[4]; crc_bytes[0] (crc_value 0) 0xFF; // LSB crc_bytes[1] (crc_value 8) 0xFF; crc_bytes[2] (crc_value 16) 0xFF; crc_bytes[3] (crc_value 24) 0xFF; // MSB // 然后依次写入0x08013FFC, 0x08013FFD, 0x08013FFE, 0x08013FFF如果你直接用*(uint32_t*)0x08013FFC crc_value;在小端机上这等价于上面的操作是安全的。但显式拆解字节逻辑更清晰也方便移植到大端平台。性能考量对32KB数据做CRC32用软件查表法256项表约需15ms72MHz主频。这在OTA流程中是可以接受的。不要为了省几毫秒而用不安全的校验方式。4. 实操过程与核心环节实现从Keil工程配置到J-Link烧录的全流程4.1 Keil MDK工程配置三个关键分散加载文件Scatter FileKeil的分散加载文件.sct是控制代码和数据在Flash/RAM中布局的灵魂。一个AB分区工程必须有三个不同的.sct文件分别对应Bootloader、A区APP、B区APP。Bootloader.sctLR_IROM1 0x08000000 0x00004000 { ; load region size_region ER_IROM1 0x08000000 0x00004000 { ; load address execution address *.o (RESET, First) *(InRoot$$Sections) .ANY (RO) } RW_IRAM1 0x20000000 0x00005000 { ; 20KB SRAM .ANY (RW ZI) } }这个文件告诉链接器Bootloader代码从0x08000000开始最大占16KB0x4000RAM从0x20000000开始。APP_A.sct用于编译A区固件LR_IROM1 0x08004000 0x00008000 { ; A区32KB ER_IROM1 0x08004000 0x00008000 { *.o (RESET, First) *(InRoot$$Sections) .ANY (RO) } RW_IRAM1 0x20000000 0x00005000 { .ANY (RW ZI) } }注意ER_IROM1的起始地址是0x08004000大小0x800032KB。APP_B.sct用于编译B区固件LR_IROM1 0x0800C000 0x00008000 { ; B区32KB ER_IROM1 0x0800C000 0x00008000 { *.o (RESET, First) *(InRoot$$Sections) .ANY (RO) } RW_IRAM1 0x20000000 0x00005000 { .ANY (RW ZI) } }起始地址变为0x0800C000。配置步骤在Keil中右键点击工程 → “Options for Target...” → “Linker”选项卡。勾选“Use Memory Layout from Target Dialog”取消勾选然后在“Scatter File”框中输入对应.sct文件的路径例如.\scatter\APP_B.sct。切换到“C/C”选项卡在“Define”框中添加宏定义例如APP_IN_B_REGION。这个宏会在APP代码中用于条件编译比如#ifdef APP_IN_B_REGION SCB-VTOR 0x0800C000; // B区向量表 #else SCB-VTOR 0x08004000; // A区向量表 #endif提示编译B区APP时必须确保其main()函数入口地址即Reset_Handler地址被正确放置在0x0800C000。Keil的链接器会自动将*.o (RESET, First)放在输出段的最前面所以只要.sct文件配置正确就万无一失。4.2 J-Link烧录如何避免“error: flash download failed - target dll has been cancelled”这个错误是STM32开发者最熟悉的“噩梦”。它出现的原因五花八门但AB分区场景下90%与以下三点有关Flash区域重叠或越界你在Keil中配置的.sct文件起始地址是0x0800C000但J-Link Commander或Keil的Flash Download设置里目标地址却填成了0x08000000。J-Link试图往Bootloader区域写入APP代码自然失败。解决方法在Keil中“Options for Target...” → “Utilities” → “Settings” → “Flash Download” → 点击“Add”添加你自己的Flash算法如STM32F10x_128.FLM然后在“Edit”中确认“Start Address”与.sct文件中的ER_IROM1起始地址完全一致。Flash算法版本过旧你用的是老版本J-Link驱动V6.x而新版本V7.x修复了F103在高主频下擦除失败的Bug。解决方法去SEGGER官网下载最新版J-Link Software and Documentation Pack安装后重启Keil。同时在Keil的“Utilities”设置里点击“Flash Download”旁边的“Settings”在“Flash”选项卡中勾选“Verify after programming”这能帮你第一时间发现写入错误。硬件连接不稳定SWDIO/SWCLK线过长15cm、未加100Ω串联电阻、或目标板供电不足3.0V都会导致J-Link通信超时最终报此错。解决方法用万用表测量VDD引脚电压确保在3.3V±5%在SWDIO和SWCLK线上各串一个100Ω电阻缩短排线长度。烧录顺序至关重要首先用J-Link烧录Bootloader.hex由Bootloader.sct生成到0x08000000。然后烧录APP_A.hex由APP_A.sct生成到0x08004000。最后烧录APP_B.hex由APP_B.sct生成到0x0800C000。注意APP_B.hex是空的占位文件里面只有填充的0xFF。它只是为B区预留出32KB空间防止后续OTA升级时写入失败。真正的B区内容由APP在运行时通过IAP写入。4.3 OTA升级协议设计一个极简但可靠的自定义协议OTA不是把一个bin文件扔过去就完事。你需要一个轻量级协议来协调“发端”上位机/云平台和“收端”STM32 APP之间的握手、分包、校验、确认。我们采用一个3帧协议总开销仅12字节专为低速UART115200bps优化字段长度说明SOF1字节起始符固定为0xAACMD1字节命令码0x01请求升级0x02发送数据块0x03升级完成LEN2字节数据块长度小端最大64KBDATALEN字节实际bin数据CRC2字节整个帧SOF到DATA的CRC16-CCITTEOF1字节结束符固定为0x55APP端处理逻辑// 伪代码 while(receive_frame(frame)) { switch(frame.cmd) { case 0x01: // 请求升级 erase_B_region(); // 擦除B区 send_ack(0x01, SUCCESS); break; case 0x02: // 发送数据块 write_to_B_region(frame.data, frame.len, current_offset); current_offset frame.len; send_ack(0x02, SUCCESS); break; case 0x03: // 升级完成 calculate_crc32_on_B_region(); write_crc32_to_B_region_end(crc32); set_reboot_flag(); NVIC_SystemReset(); break; } }这个协议没有复杂的滑动窗口、没有重传机制因为它假设上位机是可信的如本地PC工具。如果网络环境差应在上位机层面实现TCP重传或MQTT QoS1。把复杂性留在上位机让MCU保持简单是嵌入式开发的黄金法则。5. 常见问题与排查技巧实录那些让你凌晨三点还在抓头发的Bug5.1 问题速查表症状、原因、解决方案症状可能原因解决方案上电后LED不亮J-Link能连上但无法擦除FlashBootloader的Flash区域被意外擦除或写坏用J-Link Commander执行unlock命令然后重新烧录Bootloader.hexAPP能正常运行但OTA升级后复位进入Bootloader却跳转到A区而非B区B区末尾的CRC32校验值未写入或写入地址错误如写到了0x08013FF0而非0x08013FFC用J-Link Commander的mem32 0x08013FFC 1命令读取最后4字节确认是否为预期CRC值检查APP中写CRC的代码确保地址计算正确B区写入完成后APP跳转到B区但立即进入HardFault_HandlerB区的向量表重映射未生效或B区首地址0x0800C000处的数据不是有效的向量表即前4字节不是栈顶地址用mem32 0x0800C000 2命令读取B区开头8字节确认第一个字栈顶地址在0x20000000–0x20004FFF范围内F103的SRAM范围检查APP的.sct文件确保*.o (RESET, First)确实放在了0x0800C000串口接收升级包时偶尔丢包或数据错乱UART中断优先级设置过低被其他高优先级中断如TIM抢占导致接收缓冲区溢出在NVIC_PriorityGroupConfig(NVIC_PriorityGroup_2)后将USARTx_IRQn的优先级设为最高如NVIC_InitTypeDef NVIC_InitStructure; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority 0;error: flash download failed - cortex-m4你正在用针对Cortex-M4的J-Link驱动如STM32F4xx.FLM去烧录Cortex-M3的F103在Keil的“Flash Download”设置中删除所有M4算法只添加STM32F10x_128.FLM5.2 独家避坑技巧来自产线的真实经验技巧1用“影子Flash”做升级预演在正式OTA前先在RAM中模拟一次完整的B区写入和CRC校验。方法分配一块32KB的RAM如uint8_t b_region_shadow[32*1024];把接收到的bin数据先memcpy进去然后对这块RAM计算CRC32。如果RAM校验通过再执行真实的Flash写入。这能提前捕获bin文件损坏、传输错误等问题避免把错误固件写进Flash。技巧2给Bootloader加一个“强制回滚”按键在Bootloader中增加一个GPIO检测逻辑如果上电时某个按键如BOOT0被按下则无视B区状态强制从A区启动。这在B区固件有严重Bug导致设备无法联网、无法触发OTA回滚时是唯一的救命稻草。代码只需几行RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE); GPIO_InitTypeDef GPIO_InitStructure; GPIO_InitStructure.GPIO_Pin GPIO_Pin_0; GPIO_InitStructure.GPIO_Mode GPIO_Mode_IPU; // 上拉输入 GPIO_Init(GPIOA, GPIO_InitStructure); if(GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0) Bit_RESET) { jump_to_app(0x08004000); // 强制跳A区 }**技巧3监控Flash