企业官网建设流程全解析

1. 项目概述：为什么AB分区OTA在STM32F103上不是“锦上添花”，而是“生存刚需”

我第一次在工业现场看到某款基于STM32F103的温控模块因OTA升级失败而整机瘫痪，是在2019年冬天。客户产线停了整整八小时，工程师蹲在配电柜前用ST-Link硬刷固件，手冻得发僵，嘴里念叨着：“要是有个回滚机制就好了。”——那一刻我就知道，所谓“OTA升级”，在嵌入式一线从来不是炫技功能，而是产品能否活过第二个版本的生命线。今天这篇《STM32F103_AB_OTA_从零复现教程》，不讲虚的架构图和理论模型，只讲怎么用最基础的STM32F103C8T6最小系统（成本不到8元）、标准库V3.5.0、J-Link V9（非盗版，但也不需要正版SN认证），实打实跑通AB双分区热升级。核心关键词就五个：STM32F103、OTA、AB分区、Bootloader、Flash——它们不是并列关系，而是因果链：因为Flash物理特性不可逆擦除，所以必须用AB分区；因为AB分区要切换运行区，所以必须重写Bootloader；因为Bootloader要接管启动流程，所以必须精确控制Flash扇区布局与向量表偏移；而这一切，最终都落在STM32F103这颗经典但资源拮据的芯片上。

你不需要懂FreeRTOS调度原理，也不必会写USB DFU协议。只要你能用Keil MDK烧录一个点灯程序，就能跟着本文把AB分区OTA跑起来。它适合三类人：一是刚毕业进工控/物联网公司的应届生，被安排做固件升级模块却连Bootloader跳转都调不通；二是中小厂硬件工程师，手头只有几块淘宝买的最小系统板，没时间啃HAL库文档；三是想给老项目加OTA能力但被“bootloader开发”四个字吓退的固件老手。全文所有代码、地址计算、扇区划分、校验逻辑，全部基于真实调试记录——比如我反复验证过：STM32F103C8T6的Flash第1扇区（0x08000000–0x08003FFF）实际可用空间是15.875KB（不是整16KB），因为最后128字节被Option Bytes占用，这个细节不写进教程，你烧进去的Bootloader就会覆盖掉RDP保护位，导致芯片锁死。这种坑，我替你踩过了。

2. 整体设计思路：为什么放弃“单分区IAP”，死磕AB双分区

2.1 AB分区不是为了炫技，而是对抗Flash的物理暴政

先说结论：在STM32F103上做单分区IAP（In-Application Programming）升级，等于在悬崖边修路。它的致命缺陷不是代码复杂，而是不可逆性。STM32F103的Flash擦除以扇区为单位（最小1KB），而一次固件升级必然涉及擦除+写入两个动作。如果升级过程中断电、通信丢包或校验失败，新固件只写入一半，旧固件已被擦除——设备直接变砖。网上很多教程教你怎么用“升级标志位+备份扇区”做简单回滚，但实测发现：当升级失败时，标志位可能写入成功而固件写入失败，Bootloader误判为“升级完成”，结果跳转到一片空白Flash，MCU硬复位循环。这不是软件bug，是Flash物理特性的必然结果。

AB分区则从根本上规避这个问题。它的核心思想极其朴素：永远保留一份可运行的完整固件。A区放当前运行固件，B区接收新固件；升级完成后，Bootloader修改启动标志，下次复位时从B区启动；若B区启动失败，自动回退到A区。整个过程没有“擦除旧固件”的环节——旧固件始终完好躺在那里。我画过一张最简物理布局图（不用Mermaid，纯文字描述）：

Flash 地址范围 | 内容说明 | 大小 | 关键约束 -------------------|--------------------------|----------|------------------ 0x08000000–0x08003FFF | Bootloader（固定位置） | 16KB | 必须从0x08000000开始，否则无法响应复位中断 0x08004000–0x08013FFF | A区应用固件（APP_A） | 64KB | 起始地址必须对齐扇区边界（0x4000） 0x08014000–0x08023FFF | B区应用固件（APP_B） | 64KB | 同样需扇区对齐，且与A区大小严格一致 0x08024000–0x08027FFF | 升级参数区（Flag + CRC） | 16KB | 存储启动标志、校验值、版本号等元数据

注意：这里A/B区各64KB，并非随意设定。STM32F103C8T6总Flash为64KB，但Bootloader占16KB，剩余48KB根本不够放两份固件。所以实际选型必须是STM32F103RCT6（256KB Flash）或更大容量型号。很多新手栽在第一步：拿着C8T6硬搞AB分区，结果编译报错“region `FLASH' overflowed by XXX bytes”。这不是代码问题，是芯片选型错误。我建议直接用RCT6——淘宝批量价约12元，比反复调试C8T6省下的时间成本高得多。

2.2 为什么Bootloader必须“手写”，不能用ST官方IAP示例

ST官方提供的IAP例程（如AN2557）本质是单分区方案，其Bootloader逻辑是：检测升级请求→擦除APP区→写入新固件→跳转。它甚至没考虑AB分区所需的启动标志管理。更关键的是，官方Bootloader默认将APP起始地址设为0x08004000，这在单分区下没问题，但在AB分区中，A区和B区必须有独立的向量表偏移。STM32复位后，CPU从0x08000000读取MSP，从0x08000004读取Reset_Handler地址。如果APP_A放在0x08004000，它的向量表首地址就是0x08004000，但CPU仍会从0x08000000取初始值——这会导致中断向量错乱，定时器中断触发后跳到非法地址。解决方案是：在APP_A和APP_B的startup文件中，手动修改向量表偏移寄存器（VTOR）：

// 在APP_A的main()函数开头添加： SCB->VTOR = FLASH_BASE + 0x4000; // A区向量表基址 // 在APP_B的main()函数开头添加： SCB->VTOR = FLASH_BASE + 0x14000; // B区向量表基址（0x08014000）

这个操作必须在Bootloader跳转后由APP自身执行，不能由Bootloader代劳——因为Bootloader不知道APP的具体向量表位置。而官方IAP示例根本没有这段代码，直接跳转会导致90%的AB分区项目卡在第一个中断上。

2.3 OTA通信协议：为什么坚持用“裸串口+自定义帧”，不用HTTP/MQTT

很多教程一上来就集成LwIP或ESP32作为Wi-Fi透传模块，看似先进，实则埋雷。STM32F103资源极其有限：仅20KB RAM，无硬件浮点，TCP/IP协议栈吃掉至少8KB RAM，留给OTA缓冲区只剩几KB。一旦网络抖动，接收缓存溢出，整个升级流程崩溃。我实测过：用ESP32做透传，当Wi-Fi信号强度低于-70dBm时，1MB固件升级失败率高达37%。

因此本教程采用最原始也最可靠的方案：UART + 自定义二进制帧协议。帧结构极简：

[SOH:0x01] [CMD:1B] [LEN:2B] [PAYLOAD:LEN] [CRC16:2B] [ETX:0x04]

• SOH/ETX是ASCII控制字符，便于调试时肉眼识别帧边界；
• CMD区分命令类型（0x01=请求升级，0x02=发送固件块，0x03=校验确认）；
• LEN为payload长度（不含SOH/ETX/CRC），最大65535字节，足够单帧传输；
• CRC16采用CCITT-FALSE算法，比简单累加更可靠。

优势在于：单片机端只需256字节RX缓冲区（远小于TCP的4KB），PC端用Python serial库即可实现升级工具。我写了个120行的升级脚本，支持断点续传——如果升级中断，下次发送CMD=0x01时，Bootloader返回当前已接收的字节数，PC端从该位置继续发送。这个能力在工业现场至关重要：产线设备升级时突然断电，恢复供电后无需人工干预，自动续传。

3. 核心细节解析：Flash扇区规划、Bootloader跳转、向量表重映射

3.1 Flash扇区划分：精确到字节的地址计算

STM32F103的Flash扇区划分不是均匀的。根据RM0008手册Table 3，其扇区分布如下（以256KB Flash的RCT6为例）：

关键细节：

• Sector 0必须100%留给Bootloader：哪怕Bootloader只占8KB，也不能把剩余8KB分给APP，因为Option Bytes（读保护、写保护）存储在Sector 0末尾，覆盖它会导致芯片锁死。
• APP_A和APP_B必须严格对称：每个区占4个扇区（64KB），起始地址分别为0x08004000和0x08014000。这个地址差（0x10000）不是巧合，而是确保向量表偏移计算统一。
• 参数区（Sector 9）不用于存储固件，只存32字节元数据：包括boot_flag（0xAA55表示启动A区，0x55AA表示启动B区）、app_a_crc、app_b_crc、app_a_version、app_b_version。用16KB扇区存32字节看似浪费，但换来的是擦写寿命——每次升级只擦Sector 9，避免频繁擦写APP区扇区（Flash擦写寿命约10万次，扇区擦写次数直接影响设备寿命）。

提示：在Keil MDK中设置分散加载文件（scatter file）时，必须显式指定各段地址。例如APP_A的分散文件app_a.sct：

LR_IROM1 0x08004000 0x00010000 { ; load region size_region ER_IROM1 0x08004000 0x00010000 { ; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } RW_IRAM1 0x20000000 0x00005000 { ; RW data .ANY (+RW +ZI) } }

这里ER_IROM1的起始地址0x08004000就是APP_A的执行地址，也是向量表基址。

3.2 Bootloader跳转：三步走，缺一不可

Bootloader的核心任务是：检查启动标志→决定跳转地址→安全跳转。很多人卡在第三步——跳转后APP不运行。原因通常是跳转流程不完整。正确流程必须包含以下三步：

第一步：关闭所有外设时钟，防止跳转后外设干扰

// 在跳转前执行 RCC_DeInit(); // 复位RCC寄存器 RCC_HSECmd(DISABLE); // 关闭HSE RCC_HSICmd(DISABLE); // 关闭HSI // 注意：不要关闭SysTick！因为APP可能依赖它

第二步：设置主堆栈指针（MSP），这是最关键的一步

// 从APP首地址读取MSP值（即APP向量表第一个字） uint32_t *app_vector_table = (uint32_t*)APP_A_BASE; // 或APP_B_BASE __set_MSP(app_vector_table[0]); // 设置主堆栈指针

如果不执行这步，CPU仍使用Bootloader的栈空间，而APP的局部变量会覆盖Bootloader栈，导致不可预测行为。

第三步：获取Reset_Handler地址并跳转

typedef void (*pFunction)(void); pFunction jump_to_app; jump_to_app = (pFunction)(*(uint32_t*)(APP_A_BASE + 4)); // Reset_Handler地址在向量表第2项 jump_to_app(); // 执行跳转

注意：APP_A_BASE + 4是因为向量表：[0]=MSP，[1]=Reset_Handler，[2]=NMI_Handler...

实操心得：我在调试时发现，即使代码完全正确，首次跳转仍可能失败。原因是Bootloader的全局变量未清零，残留数据被APP误读。解决方案是在跳转前执行memset((void*)0x20000000, 0, 0x5000)清空SRAM前20KB（APP使用的RAM区域）。这个细节官方文档从不提及，但实测能将跳转成功率从82%提升至100%。

3.3 向量表重映射：为什么不能只改VTOR，还要处理中断

STM32F103的中断向量表默认位于Flash起始地址（0x08000000）。当APP_A运行在0x08004000时，其向量表也在0x08004000。但CPU复位后仍从0x08000000读取向量——这就要求APP_A在启动时主动重映射。方法是设置SCB->VTOR寄存器：

// 在APP_A的main()函数最开头执行 SCB->VTOR = FLASH_BASE + 0x4000; // 指向APP_A向量表

但这只是第一步。更隐蔽的问题是：某些外设中断（如USART1）的优先级分组在Bootloader中已配置，APP_A必须重新配置才能生效。例如，Bootloader可能设置NVIC_PriorityGroupConfig(NVIC_PriorityGroup_2)，而APP_A若不重新设置，调用NVIC_Init()时会因优先级分组不匹配导致中断不触发。我的做法是：在APP_A的SystemInit()之后、main()之前，强制重置NVIC：

// 在APP_A的system_stm32f10x.c中修改SystemInit() void SystemInit(void) { // 原有初始化代码... // 新增：清除NVIC所有挂起标志和使能状态 for (int i = 0; i < 8; i++) { NVIC->ICPR[i] = 0xFFFFFFFF; // 清除挂起 NVIC->ICER[i] = 0xFFFFFFFF; // 禁用所有中断 } // 重新配置优先级分组 NVIC_PriorityGroupConfig(NVIC_PriorityGroup_2); }

这个操作确保APP_A拥有干净的中断环境，避免Bootloader遗留配置的干扰。

4. 实操过程：从Keil工程搭建到PC端升级工具全链路

4.1 Keil MDK工程搭建：三个独立工程的协同

本项目需同时维护三个Keil工程：

• Bootloader工程：编译生成bootloader.hex，烧录到0x08000000；
• APP_A工程：编译生成app_a.bin，烧录到0x08004000；
• APP_B工程：编译生成app_b.bin，烧录到0x08014000。

三个工程必须共享同一套标准库（V3.5.0），且不能使用HAL库——HAL库初始化代码体积大，会挤占宝贵的Flash空间。我统计过：HAL库的HAL_Init()+SystemClock_Config()约占用3.2KB Flash，而标准库精简版仅需800字节。

Bootloader工程关键配置：

• Target选项卡：IROM1起始地址0x08000000，大小0x00004000（16KB）；
• Output选项卡：勾选“Create HEX File”；
• C/C++选项卡：定义宏BOOTLOADER，用于条件编译。

APP_A/APP_B工程关键配置：

• Target选项卡：IROM1起始地址分别为0x08004000和0x08014000，大小均为0x00010000（64KB）；
• Output选项卡：勾选“Create BIN File”（注意不是HEX！BIN是纯二进制，OTA升级必需）；
• C/C++选项卡：定义宏APP_A或APP_B，并在main.c中根据宏启用对应向量表重映射。

注意：APP工程必须禁用“Use Memory Layout from Target Dialog”，改用分散加载文件（scatter file），否则链接器会将代码链接到默认地址0x08000000，导致烧录失败。

4.2 Bootloader核心代码：200行搞定升级逻辑

以下是Bootloader主循环精简版（删除了串口驱动等基础代码，聚焦逻辑）：

#define FLAG_ADDR 0x08024000 #define APP_A_BASE 0x08004000 #define APP_B_BASE 0x08014000 typedef struct { uint16_t boot_flag; // 0xAA55=A区, 0x55AA=B区 uint32_t app_a_crc; uint32_t app_b_crc; uint8_t app_a_ver[8]; uint8_t app_b_ver[8]; } upgrade_param_t; upgrade_param_t *param = (upgrade_param_t*)FLAG_ADDR; void bootloader_main(void) { // 1. 初始化串口、Flash等 uart_init(); flash_init(); // 2. 检查升级请求（通过串口命令或GPIO按键） if (check_upgrade_request()) { upgrade_firmware(); } // 3. 根据启动标志跳转 if (param->boot_flag == 0xAA55) { jump_to_app(APP_A_BASE); } else if (param->boot_flag == 0x55AA) { jump_to_app(APP_B_BASE); } else { // 首次上电，默认启动A区 param->boot_flag = 0xAA55; flash_write_word(FLAG_ADDR, 0xAA55); jump_to_app(APP_A_BASE); } } void upgrade_firmware(void) { uint32_t target_addr; uint8_t buffer[256]; uint16_t len, crc_recv, crc_calc; // 选择目标区：若当前运行A区，则升级B区；反之升级A区 if (param->boot_flag == 0xAA55) { target_addr = APP_B_BASE; } else { target_addr = APP_A_BASE; } // 擦除目标区所有扇区（Sector 5-8） flash_erase_sector(5); flash_erase_sector(6); flash_erase_sector(7); flash_erase_sector(8); // 循环接收固件块 while (1) { if (uart_receive_frame(buffer, &len, &crc_recv)) { if (buffer[0] == 0x02) { // CMD=0x02，固件块 flash_write_buffer(target_addr, buffer+1, len-1); target_addr += len-1; } else if (buffer[0] == 0x03) { // CMD=0x03，校验确认 crc_calc = calculate_crc32(buffer+1, len-1); if (crc_calc == crc_recv) { // 校验成功，更新启动标志 if (param->boot_flag == 0xAA55) { param->boot_flag = 0x55AA; } else { param->boot_flag = 0xAA55; } flash_write_word(FLAG_ADDR, param->boot_flag); break; } } } } }

关键点说明：

• flash_erase_sector()必须按扇区号调用，不能按地址——STM32F103的Flash擦除指令只接受扇区编号；
• flash_write_buffer()每次写入不超过256字节（Flash编程页大小），且地址必须字对齐；
• 校验使用CRC32而非CRC16，因为固件较大时CRC16碰撞概率显著上升（实测1MB固件CRC16冲突率约0.03%，CRC32可忽略）。

4.3 PC端升级工具：Python实现的可靠升级器

我用Python 3.8写了ota_upgrader.py，核心逻辑仅120行，支持Windows/Linux/macOS：

import serial import time import sys import os import binascii def send_frame(ser, cmd, payload=b''): frame = b'\x01' + bytes([cmd]) + len(payload).to_bytes(2, 'big') + payload crc = binascii.crc_hqx(frame[1:], 0) # CCITT-FALSE frame += crc.to_bytes(2, 'big') + b'\x04' ser.write(frame) def upgrade(ser, bin_file, target_addr): with open(bin_file, 'rb') as f: firmware = f.read() # 步骤1：请求升级，获取当前进度 send_frame(ser, 0x01) resp = ser.read(100) if len(resp) < 6 or resp[0] != 0x02: print("Bootloader未响应") return False start_offset = int.from_bytes(resp[1:5], 'big') print(f"从偏移{start_offset}处续传") # 步骤2：分块发送固件 chunk_size = 256 for i in range(start_offset, len(firmware), chunk_size): chunk = firmware[i:i+chunk_size] send_frame(ser, 0x02, chunk) time.sleep(0.01) # 避免串口缓冲区溢出 # 步骤3：发送校验请求 crc32 = binascii.crc32(firmware) & 0xffffffff send_frame(ser, 0x03, crc32.to_bytes(4, 'big')) # 等待确认 timeout = 10 while timeout > 0: if ser.in_waiting: resp = ser.read(1) if resp == b'\x05': # ACK print("升级成功！重启设备...") return True time.sleep(1) timeout -= 1 print("升级超时") return False if __name__ == '__main__': if len(sys.argv) < 4: print("用法: python ota_upgrader.py <COMx> <firmware.bin> <target>") sys.exit(1) ser = serial.Serial(sys.argv[1], 115200, timeout=1) upgrade(ser, sys.argv[2], sys.argv[3]) ser.close()

使用方法：

# 升级B区（当前运行A区） python ota_upgrader.py COM3 app_b.bin B # 升级A区（当前运行B区） python ota_upgrader.py COM3 app_a.bin A

这个工具的优势在于：真正的断点续传。当升级中断后，Bootloader会返回已接收字节数，PC端自动从该位置继续发送，无需人工干预。我在-20℃冷库环境中测试过：连续10次模拟断电，续传成功率100%。

5. 常见问题与排查技巧实录：那些让工程师熬夜的坑

5.1 典型问题速查表

5.2 独家避坑技巧

技巧1：用ST-Link Utility做“Flash快照”对比每次升级失败，不要急着改代码。先用ST-Link Utility连接芯片，导出当前Flash内容（Save to file → Binary），再用WinMerge对比：

• 对比0x08004000–0x08013FFF（APP_A区）与原始app_a.bin，看是否写入完整；
• 对比0x08024000处参数区，看boot_flag是否已更新。 这个方法能在5分钟内定位是Bootloader写入问题，还是APP自身逻辑崩溃。

技巧2：在APP中添加“自检模式”在APP的main()开头加入：

if (GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0)) { // PA0按键按下 // 进入自检模式：点亮LED，发送版本号到串口 while(1) { GPIO_SetBits(GPIOA, GPIO_Pin_1); delay_ms(100); GPIO_ResetBits(GPIOA, GPIO_Pin_1); delay_ms(100); printf("APP_A v1.0.0\r\n"); } }

这样，当升级后设备异常，长按PA0键即可进入自检，确认APP是否真正运行。避免误判为Bootloader问题。

技巧3：扇区擦除前先校验“空扇区”STM32F103擦除扇区后并非全0x00，而是全0xFF。但某些劣质Flash芯片擦除不彻底，残留数据导致写入失败。因此在擦除后、写入前，务必校验：

for (uint32_t addr = sector_start; addr < sector_end; addr += 4) { if (*(uint32_t*)addr != 0xFFFFFFFF) { // 擦除失败，重试或报错 } }

这个检查增加10ms延迟，但能避免90%的“升级成功但APP不运行”问题。

5.3 性能实测数据：AB分区OTA的真实开销

我用逻辑分析仪实测了整个升级流程（64KB固件，115200bps串口）：

• 传输时间：64KB ÷ (115200÷10) ≈ 5.56秒（串口有效带宽按波特率÷10估算）；
• Flash擦除时间：4个扇区 × 1.2秒/扇区 = 4.8秒（STM32F103扇区擦除典型值）；
• Flash写入时间：64KB ÷ 256字节/次 × 20ms/次 = 5.12秒（每次编程耗时20ms）；
• 总升级耗时：约15.5秒（不含校验和跳转）；
• 额外Flash开销：Bootloader 16KB + 参数区 16KB = 32KB，占总Flash 12.5%；
• 额外RAM开销：OTA缓冲区256字节 + CRC计算栈空间 ≈ 300字节，占总RAM 1.5%。

这些数据证明：AB分区OTA在STM32F103上完全可行，且资源开销在可接受范围内。关键不是“能不能做”，而是“敢不敢直面Flash的物理限制，用最笨的办法解决最本质的问题”。

6. 工程落地建议：如何把这套方案用在你的产品里

6.1 硬件层面：最小系统的必要改造

淘宝上卖的STM32F103C8T6最小系统板，通常只有BOOT0/BOOT1跳线，缺少OTA必需的硬件支持。我建议增加三处改动：

• 增加一个用户按键（PA0）：长按进入Bootloader升级模式，短按触发自检；
• 增加一个状态LED（PB1）：Bootloader运行时慢闪，APP运行时快闪，升级中常亮；
• 预留一个SWD接口（CN3）：虽然OTA免接线，但调试阶段必须能用ST-Link烧录Bootloader。

特别提醒：BOOT0引脚必须通过10K电阻上拉到3.3V，并用0Ω电阻接地。这样既能保证正常启动（BOOT0=0），又能在需要时短接跳线强制进入系统存储器启动模式（BOOT0=1），用于恢复Bootloader。

6.2 固件迭代策略：版本号管理与灰度发布

AB分区天然支持灰度发布。我的做法是：

• 版本号格式：X.Y.Z，其中X为主版本（不兼容升级），Y为功能版本（新增API），Z为修复版本（Bugfix）；
• 参数区存储app_a_version和app_b_version，Bootloader启动时比较：
  • 若app_b_version > app_a_version，则启动B区；
  • 若app_b_version == app_a_version，则启动A区；
  • 若app_b_version < app_a_version，则忽略B区，启动A区。 这样，你可以先小批量烧录B区新固件（如10台设备），观察日志；确认稳定后，再推送升级指令，让所有设备切换到B区。整个过程无需停机，真正实现“零 downtime 升级”。

6.3 安全加固：从“能升级”到“安全升级”

当前方案未加密固件，存在被篡改风险。低成本加固方案：

• 签名验证：在PC端用RSA-1024私钥签名固件，Bootloader用公钥验签。STM32F103运行RSA-1024约需800ms，可接受；
• AES-128加密：固件传输前用AES加密，Boot