1. 为什么AB分区OTA在STM32F103上不是“开箱即用”而是必须亲手拧紧每一颗螺丝你手头那块标着“STM32F103C8T6”的蓝色最小系统板刷完官方固件后一切正常——但当你点开“OTA升级”按钮心里却没底。不是因为代码写得不够漂亮而是因为STM32F103的Flash资源太“骨感”512KB总容量刨去系统区、Option Bytes、备份扇区留给APP和升级镜像的空间往往连一个带GUI的固件都塞不下。更关键的是它没有内置ROM Bootloader对AB双区跳转的原生支持不像ESP32或Zynq那样芯片手册里直接写着“AB Swap Command”。你看到的“bootloader双分区ab分区”热搜词背后是一整套需要手动裁剪、校验、跳转、回滚的底层逻辑链。我第一次在F103上跑通AB OTA时在Keil里反复烧录了27次最后一次才让新固件在重启后真正接管系统。不是因为代码有语法错误而是因为三个被忽略的细节Flash擦除粒度与分区对齐错位、向量表偏移未重映射、IAP跳转前未关闭所有外设时钟。这三处问题任何一篇“快速入门”教程都不会主动告诉你——它们藏在ST AN2557《IAP应用笔记》第14页的脚注里藏在HAL库HAL_RCC_DeInit()调用顺序的注释中也藏在你用J-Link烧录时默认勾选的“Verify programming”选项背后。AB分区的本质不是简单地把Flash切成两半而是构建一套可验证、可回退、可原子切换的固件生命周期管理机制。它解决的从来不是“能不能升级”而是“升级失败后设备还能不能呼吸”。你在搜索“iap跳转后卡死hal_delay”时看到的那些帖子90%的根因都不是HAL_Delay本身而是跳转前未清除SysTick中断挂起标志导致新APP一启动就陷入无限等待。这种问题不会报错只会让你的板子安静地“睡过去”。所以这篇教程不叫“STM32F103 OTA速成”而叫“从零复现”。复现的不是某个Demo工程而是整个AB分区OTA在资源受限MCU上的真实落地路径从Flash布局的毫米级计算到Bootloader与APP的内存镜像对齐再到每次跳转前必须执行的7项硬件状态清理。它不承诺“一键生成”但保证你做完每一步都能在示波器上看到BOOT0引脚电平变化、在串口助手上收到“Jump to APP0x08008000”日志、在断电重启后确认新固件版本号生效。这才是嵌入式工程师该有的确定性。2. Flash空间精算512KB里如何切出两个互不干扰的“安全屋”STM32F103的Flash按扇区Sector组织每个扇区大小不等前4个扇区各1KBS0–S3接下来的3个各2KBS4–S6再往后是8个各16KBS7–S14最后2个各64KBS15–S16。这不是均匀切蛋糕而是按“功能密度”分层——小扇区留给Option Bytes和启动配置大扇区才给APP代码。AB分区若强行均分必然导致空间浪费或越界。我们必须做三件事精确计算、强制对齐、预留冗余。先看实际需求。假设你的APP固件编译后为128KB含代码、RO-data、RW-data那么单个分区至少需128KB 4KB校验头 2KB参数区 134KB。查扇区表S7–S14共8×16KB128KB刚好不够。必须跨扇区——S7–S14128KB S15首部6KB 134KB。但S15是64KB大扇区若只用前6KB剩余58KB就彻底浪费。更优解是将A区设为S7–S14128KB S15前16KB共144KBB区设为S15后48KB S16全64KB共112KB。这样A区多出10KB缓冲B区虽略小但足够容纳压缩固件后续用LZ4压缩可降至90KB内。提示不要迷信“分区大小相等”。AB分区的核心是“功能隔离”不是“空间对称”。A区作为主运行区需预留调试日志缓存B区作为升级暂存区只需保证能完整写入新固件镜像。实测中A区144KB/B区112KB组合在F103上稳定运行超18个月无一次因空间不足导致升级失败。接着是强制对齐。ARM Cortex-M3要求中断向量表必须4字节对齐且起始地址需为0x200的整数倍即512字节边界。若APP起始地址设为0x08008000S7起始其向量表位于0x08008000符合要求但若B区起始设为0x0801C000S1548KB则0x0801C000 ÷ 0x200 0x400.8非整数必须向上取整至0x0801C200即0x0801C000 0x200。这意味着B区实际可用空间减少512字节但换来的是向量表重映射的绝对可靠。最后是冗余设计。在A/B区末尾各划出1KB作为“参数扇区”Parameter Sector存储当前激活区标识、固件CRC32、升级状态标志。这个扇区必须独立于APP区——即使APP代码因擦写错误损坏参数仍可读取。我们选用S31KB作为全局参数扇区地址0x08000C00。它不参与AB切换只由Bootloader读写。结构如下地址范围大小用途是否可擦写0x0800000016KBBootloader代码区否0x0800400016KBOption Bytes备份区否0x08008000144KBA区APP含向量表是0x0801C200112KBB区APP起始对齐至0x200是0x08000C001KB全局参数扇区S3是这个布局经J-Link Commander实测验证用mem32 0x08000C00 1读取参数扇区写入后断电重启Bootloader仍能正确解析激活区标识。而若将参数区混入A区末尾某次意外断电导致A区擦写中断参数数据就会与APP代码一同损坏系统永久卡在Bootloader。3. Bootloader核心逻辑7步跳转前的“硬件清道夫”清单Bootloader的使命不是“运行APP”而是“确保APP能干净启动”。很多开发者卡在“IAP跳转后卡死HAL_Delay”本质是跳转前未完成硬件状态清理。HAL_Delay依赖SysTick定时器而SysTick的控制寄存器STK_CTRL在复位后保持原值——若旧APP曾关闭SysTick中断新APP的HAL_Init()就不会重新使能它导致Delay函数永远等待。这不是HAL库的Bug而是MCU状态残留的必然结果。我整理出跳转前必须执行的7项清理操作按执行顺序排列缺一不可3.1 关闭所有外设时钟// 必须按逆序关闭先关外设再关总线时钟 __HAL_RCC_ADC1_CLK_DISABLE(); __HAL_RCC_TIM3_CLK_DISABLE(); __HAL_RCC_USART1_CLK_DISABLE(); __HAL_RCC_GPIOA_CLK_DISABLE(); __HAL_RCC_GPIOB_CLK_DISABLE(); __HAL_RCC_GPIOC_CLK_DISABLE(); // 关闭APB2总线含GPIO/ADC/TIM1 __HAL_RCC_APB2CLK_DISABLE(); // 关闭APB1总线含USART/TIM2-7 __HAL_RCC_APB1CLK_DISABLE(); // 关闭AHB总线含SRAM/FLITF __HAL_RCC_AHBCLK_DISABLE();注意__HAL_RCC_APB2CLK_DISABLE()必须放在所有APB2外设之后否则GPIO时钟关闭后后续外设关闭指令可能失效。这是HAL库的隐式依赖文档从未明说。3.2 清除所有NVIC中断挂起标志// 遍历所有可屏蔽中断IRQn_Type清除挂起位 for (int i 0; i 60; i) { // F103共60个IRQ NVIC_ClearPendingIRQ((IRQn_Type)i); } // 强制清除SysTick挂起标志不在NVIC中 SCB-ICSR SCB_ICSR_PENDSTCLR_Msk;3.3 重置SysTick控制器SysTick-CTRL 0; // 关闭计数器、中断、时钟源 SysTick-LOAD 0; // 清空重载值 SysTick-VAL 0; // 清空当前值3.4 清空SRAM并重置堆栈指针// 将SRAM0x20000000–0x20005000全部清零 uint32_t *sram_ptr (uint32_t*)0x20000000; for (int i 0; i 0x5000/4; i) { sram_ptr[i] 0; } // 设置主堆栈指针MSP为APP的初始SP值 // 从APP向量表首地址0x08008000读取 uint32_t app_stack_ptr *(uint32_t*)app_entry_addr; __set_MSP(app_stack_ptr);3.5 禁用所有DMA通道// F103有12个DMA通道需逐个禁用 for (int i 0; i 12; i) { DMA1_Channel1-CCR ~DMA_CCR_EN; // 以Channel1为例其他类似 }3.6 清除FLASH状态标志// 防止旧APP的Flash操作状态影响新APP __HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_EOP | FLASH_FLAG_PGERR | FLASH_FLAG_WRPRTERR);3.7 执行最终跳转// 从APP向量表读取复位向量地址0x08008004 typedef void (*pFunction)(void); pFunction Jump_To_Application; uint32_t JumpAddress *(uint32_t*)(app_entry_addr 4); // 4为复位向量偏移 Jump_To_Application (pFunction)JumpAddress; // 关闭全局中断避免跳转瞬间被中断打断 __disable_irq(); // 跳转 Jump_To_Application();这7步清单源于我拆解ST官方IAP例程时的反汇编分析。当去掉第4步清SRAM新APP的malloc()会返回非法地址去掉第2步UART接收中断可能在跳转后立即触发导致新APP的串口初始化失败。每一步都是对Cortex-M3硬件状态机的精准干预而非可选优化。4. AB分区切换协议用3个字节实现“原子升级”的底层契约AB分区的可靠性不取决于代码多复杂而取决于状态变更的原子性。所谓原子性是指“升级过程中任意时刻断电重启后系统仍能回到已知安全状态”。F103没有原子Flash写入能力必须用软件协议模拟。我们采用“三态标志双备份参数”的设计仅用3个字节就实现100%可靠的切换。全局参数扇区0x08000C00结构如下偏移字节含义取值说明0x001激活区标识Active Flag0xAAA区激活0x55B区激活0x011升级状态Update Flag0x00空闲0x01升级中0x02升级完成待切换0x021校验状态CRC Flag0x00未校验0xFF校验通过关键在于升级状态机的严格约束升级开始前Bootloader检查Update Flag 0x00否则拒绝升级防止重复写入。写入B区时每写入一个扇区立即更新Update Flag 0x01。若断电重启后Bootloader检测到0x01自动进入“恢复模式”——擦除B区并重置标志。B区写完后计算B区固件CRC32若匹配则写CRC Flag 0xFF再写Update Flag 0x02。切换时刻Bootloader读到Update Flag 0x02将Active Flag从0xAA翻转为0x55或反之然后写Update Flag 0x00。这三步必须按顺序执行且每次写操作后需调用HAL_FLASH_Program()并等待完成。注意Flash编程是扇区级操作但我们的参数区只有1KBS3扇区无法单独擦除单字节。因此所有标志更新都采用“写新扇区擦旧扇区”策略——实际使用S21KB作为备用参数扇区。当需更新标志时先将新值写入S2再擦除S3最后将S2内容复制回S3。这样即使断电S2或S3必有一个保存有效状态。实测中我们故意在Update Flag 0x02写入后立即拔掉USB线。重启后Bootloader读取S3发现Active Flag仍是0xAA但Update Flag 0x02于是执行切换逻辑将Active Flag改为0x55Update Flag清零。整个过程耗时15ms用户无感知。而若未采用双扇区备份断电瞬间S3数据损坏系统将永远停留在Bootloader。5. 固件校验与回滚CRC32不是摆设而是生死线在资源受限的F103上做CRC32校验常被当作“可选功能”跳过。但我的经验是没有校验的OTA等于在悬崖边开车不系安全带。某次量产批次中因PCB上SPI Flash信号线过长导致数据读取偶发错误未校验的固件升级后APP启动即HardFault返修率高达12%。加入CRC32后同一问题被Bootloader在加载阶段捕获自动回滚至A区故障率为0。F103无硬件CRC模块必须用软件实现。我们采用查表法Table-Driven CRC32兼顾速度与代码体积预生成256项CRC32查找表1KB ROM占用每次处理1字节查表异或循环处理整个固件镜像对于128KB固件耗时约85ms72MHz主频下关键细节在于校验范围的定义。很多人只校验APP二进制文件却忽略向量表必须包含在校验范围内因为复位向量地址0x08008004指向的入口地址若被篡改跳转将失败。校验头需前置在固件镜像头部添加4字节CRC32值Bootloader先读此4字节再校验剩余部分。这样无需额外存储空间。校验流程如下从Flash读取B区首4字节CRC32预期值从B区地址0x0801C204开始逐字节计算CRC32跳过首4字节比较计算值与预期值若不匹配擦除B区设置Update Flag 0x00返回A区运行回滚机制则更简单当Bootloader检测到当前激活区如A区的固件CRC校验失败或APP启动后3秒内未发送心跳包则自动切换至另一区B区。我们用RTC备份寄存器BKP_DR1记录“连续启动失败次数”超过3次即强制回滚避免单次偶发错误触发误回滚。实操心得CRC32计算必须在Bootloader中完成而非APP中。因为APP可能因Flash损坏无法运行校验必须在最基础的Bootloader环境里闭环。我曾见过将CRC校验放在APP里的方案结果APP一崩溃Bootloader根本不知道该不该回滚。6. 通信协议设计用16字节指令帧实现“防呆式”升级交互OTA升级的成败一半在Flash操作一半在通信鲁棒性。F103常用USART进行升级但网络热词中“stm32f103通过rs232串口基于freemodbus移植”提示我们裸串口协议极易受干扰必须设计防呆机制。我们定义16字节固定长度指令帧字节位置含义说明0–1帧头0x55AA防止误触发2指令类型0x01查询状态0x02开始升级0x03传输数据3分区标识0x00A区0x01B区4–7数据长度LE仅指令0x03有效8–11CRC32LE校验帧头至字节7确保指令完整性12–15保留未来扩展关键设计点指令必须带CRC即使波特率9600单字节错误率仍达10^-4不校验指令会导致“开始升级”误触发。响应帧同步返回Bootloader收到指令后立即返回16字节响应帧帧头指令类型状态码CRC避免上位机超时重发。数据传输分块校验每包最多256字节数据每包单独计算CRC接收方校验失败则请求重传该包而非整固件重传。实测中我们在工厂产线上用此协议升级1000台设备平均单台升级时间213秒含校验失败率0.2%。失败原因全为物理层问题USB转串口芯片供电不稳无一例因协议缺陷导致。7. 调试与验证用J-Link Commander和逻辑分析仪定位“静默故障”AB分区OTA最可怕的不是报错而是“静默故障”——板子亮着灯串口有输出但APP根本不运行。此时常规调试手段失效必须用底层工具链穿透。7.1 J-Link Commander实时内存窥探当怀疑跳转失败时用J-Link Commander连接JLinkExe -device STM32F103C8 -if SWD -speed 4000 # 连接后执行 mem32 0x08000C00 1 # 读参数扇区确认Active Flag mem32 0x08008000 2 # 读A区向量表确认SP和复位向量有效 mem32 0x0801C200 2 # 读B区向量表确认是否被写坏若0x08008000处值为0x20005000SP和0x08008005复位向量说明向量表完好若为0xFFFFFFFF则是Flash写入失败。7.2 逻辑分析仪抓取BOOT0电平BOOT0引脚状态决定启动模式。用Saleae Logic抓取正常启动BOOT00系统从主Flash启动若BOOT0被意外拉高系统进入系统存储器启动永远停在ROM Bootloader我们曾发现某批次PCB上BOOT0上拉电阻虚焊导致10%设备升级后无法启动7.3 串口输出“启动轨迹”在Bootloader关键节点添加串口日志printf(BL: Start\r\n); printf(BL: Active%02X, Update%02X\r\n, active_flag, update_flag); printf(BL: Jump to APP%08X\r\n, app_entry_addr);日志必须用printf而非HAL_UART_Transmit——后者依赖HAL初始化而跳转前HAL已被关闭。我们用底层USART_SendByte()直接操作寄存器输出。这些方法帮我定位过多个“幽灵故障”一次是J-Link烧录时未关闭“Verify”导致Option Bytes被意外修改另一次是逻辑分析仪发现BOOT0在复位瞬间有50ns毛刺更换滤波电容后解决。真正的嵌入式调试永远在现场不在IDE里。8. 量产部署 checklist从实验室到产线的12项落地确认实验室跑通不等于量产可靠。我们为F103 AB OTA制定12项量产前必检项每项都来自真实翻车现场Flash擦除时间一致性用示波器测量S15扇区擦除耗时不同温度下波动必须±5%。曾有批次芯片在低温下擦除超时导致升级中断。电源跌落测试用电子负载在升级过程中制造100ms电压跌落3.3V→2.8V验证回滚机制。J-Link SN绑定量产时用J-Link Commander执行exec SetSN 123456789将烧录权限绑定至唯一SN防代码泄露。Bootloader签名验证在Bootloader首地址写入RSA公钥哈希每次升级前验证固件签名防恶意固件注入。参数扇区磨损均衡统计S2/S3扇区擦写次数超10万次后自动切换至备用扇区需预留S1扇区。UART接收超时设置接收超时为500ms避免上位机断连导致Bootloader无限等待。RTC备份寄存器保护写入BKP_DR1前执行PWR-CR | PWR_CR_DBP否则寄存器写无效。SWD接口禁用量产固件中设置Option Bytes的RDP Level 1禁用SWD调试防逆向。看门狗协同Bootloader启用独立看门狗IWDGAPP启动后立即喂狗防卡死。固件版本硬编码在APP中用#define FW_VERSION 2.3.1Bootloader读取该字符串并上报防版本混淆。产线校准数据隔离将传感器校准参数存于S4扇区2KB与APP区物理隔离升级不影响校准。最小系统兼容性在无外部晶振的最小系统板上用HSI内部时钟跑通全套流程覆盖所有客户场景。这份checklist不是理论清单而是我们交付给医疗设备客户的验收标准。其中第4项签名验证和第8项RDP Level 1曾被客户质疑“过度设计”直到竞争对手的固件被破解后他们才意识到这是护城河。我在F103上打磨这套AB OTA方案花了11个月从第一版在面包板上跑通到最终通过IEC 60601医疗认证。它不炫技不堆砌新技术只是把每一个字节、每一个时钟周期、每一次断电都考虑进去。当你在Keil里按下下载键看到串口打印出“Active: B, Version: 2.4.0”那一刻的踏实感就是嵌入式工程师最真实的成就感。