STM32F103 AB分区OTA实战：从单区变砖到工业级可靠升级-开发者社区

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

我第一次在工业现场看到因OTA失败导致整批设备停机，是在一家做智能电表的客户产线。那台STM32F103C8T6主控板，烧录了新固件后卡在启动校验环节——既没进App，也没回退到旧版本，整机黑屏。售后工程师带着J-Link连夜飞过去，拆壳、焊点、接SWD，折腾六小时才救活一台。后来查日志发现，问题出在IAP升级时擦除Flash过程中突然断电，旧固件被擦掉一半，新固件又没写完，Bootloader找不到有效入口，直接死循环。这不是个例。我在过去三年里帮17家中小厂商做过固件升级方案评审，其中12家用的还是单分区IAP，全部踩过“升级变砖”的坑。而AB分区OTA，本质上就是给固件升级装上双保险——A区跑当前稳定版，B区静默接收新固件；升级完成再原子切换启动地址，哪怕断电、复位、校验失败，系统总能回退到上一个可用版本。标题里的“STM32F103_AB_OTA_从零复现教程”，说白了就是手把手带你把这块经典芯片从“裸奔式升级”拉到工业级可靠标准。它不依赖任何云平台、不绑定特定通信模块（UART/USB/CAN/WiFi都可接入），核心逻辑全在芯片本地实现。关键词里反复出现的STM32F103、OTA、AB分区、Bootloader、IAP，每一个都不是虚词：STM32F103是资源受限但生态成熟的典型代表；OTA是远程升级的统称；AB分区是容错机制的物理基础；Bootloader是掌控启动权的“守门人”；IAP（In Application Programming）则是它执行擦写操作的底层能力。你不需要懂RTOS，不需要接ESP32做网关，甚至不用联网——只要你会用Keil或STM32CubeIDE，有块最小系统板和J-Link，就能把这套机制跑通。它解决的不是“能不能升级”，而是“升级失败后设备还能不能用”。这才是嵌入式开发者真正该死磕的硬核能力。

2. 整体架构设计与关键决策逻辑

2.1 为什么必须用AB分区？单分区IAP的致命缺陷在哪

很多人以为IAP就是OTA，其实这是个危险误区。IAP只是技术手段——允许App代码自己擦写Flash；OTA是应用场景——远程更新固件；而AB分区，才是让IAP在真实场景中不死机的工程解法。我拿STM32F103的Flash布局来算笔账：它典型配置是64KB Flash（以C8T6为例），其中20KB留给Bootloader，剩余44KB分给App。单分区方案下，升级流程是：App收到新固件→跳转到Bootloader→擦除整个App区（44KB）→写入新固件→校验→跳回App。问题就出在“擦除整个App区”这一步。Flash擦除是以扇区为单位的，F103的扇区大小是1KB或2KB（具体看型号），擦除一个扇区需要10~20ms。44KB至少要擦22次，全程耗时近500ms。这期间如果断电，Flash里存的全是0xFF和部分写入的乱码，Bootloader校验失败，启动失败。更糟的是，旧固件已被擦除，无处回退。AB分区把44KB App空间一分为二：A区22KB，B区22KB。升级时只擦B区（22KB，约250ms），A区保持原样运行。新固件写入B区并校验通过后，仅需修改一个标志位（存在Option Bytes或专用Flash页），下次启动时Bootloader读到标志位，就从B区启动。整个过程A区始终在线，断电也不影响已运行的业务逻辑。这不是理论假设——我实测过，在写入B区第15KB时突然拔掉USB供电，重新上电后系统自动从A区启动，日志显示“Recovery: last upgrade failed, fallback to A partition”。这才是工业现场敢用的方案。

2.2 Bootloader为何不能和App合并在一个工程里？

新手常犯的错误，是把Bootloader逻辑写进App里，用函数指针跳转。这看似省事，实则埋雷。STM32F103的启动流程是硬件强制的：复位后，CPU从0x08000000（System Memory）或0x08000000（Main Flash）取向量表。Bootloader必须占据Flash起始地址，否则无法接管启动权。如果Bootloader和App共用一个工程，编译器会把所有代码按链接脚本顺序排布，Bootloader可能被挤到后面，导致复位后直接跑App，Bootloader形同虚设。正确做法是物理隔离：Bootloader单独编译，烧录到0x08000000起始地址，占用固定空间（我推荐20KB，留足未来扩展）；App从0x08005000开始（跳过Bootloader区），A区和B区在此基础上偏移。这样每次烧录App时，Bootloader完全不受影响。有人问：“那Bootloader怎么知道该跳A区还是B区？”答案是：它不“知道”，它只读一个启动标志。这个标志存在两个地方：一是Option Bytes里的User Option Byte（8位，可存状态），二是专门划出的1KB Flash页（如0x0800F000）存结构体。我倾向后者，因为Option Bytes擦写次数有限（万次级），而Flash页可擦写10万次，且能存更多数据（如版本号、校验和、时间戳）。标志结构体长这样：

typedef struct { uint32_t magic; // 魔数 0x5AA55AA5，防误判 uint8_t active_bank; // 0=A, 1=B uint32_t version; // 当前运行版本 uint32_t crc32; // 校验和 } boot_flag_t;

Bootloader启动时，先读这个结构体，校验magic和crc32，再根据active_bank决定跳转地址。App升级时，只改这个结构体，不碰Bootloader代码。这种解耦让维护变得简单：Bootloader十年不用动，App迭代几十版，互不影响。

2.3 为什么选IAP而非ISP？JTAG/SWD调试口要不要保留？

ISP（In System Programming）靠外部工具（J-Link）烧录，IAP靠芯片自己擦写。标题强调“IAP”，是因为OTA必须IAP——远程下发的固件包，得由设备自己存到Flash里。ISP做不到这点。但IAP有个隐藏前提：Bootloader必须能访问Flash控制器、解锁写保护、处理擦除时序。STM32F103的Flash编程手册（PM0075）第3.3节明确要求：执行IAP前，必须调用FLASH_Unlock()，且擦除/写入操作需在HSI或PLL稳定后进行。很多初学者忽略这点，直接调FLASH_ProgramWord()，结果写入失败却无报错。至于JTAG/SWD口，我的建议是永远保留。理由很现实：AB分区再稳，也防不住逻辑bug。比如某次升级后App里一个CAN中断优先级配错，导致死锁。这时J-Link能强制停机、读寄存器、查堆栈，比等设备自动回退快十倍。我在Bootloader里留了“强制进入Bootloader模式”按键：BOOT0拉高+复位，跳过标志检查，直接进Bootloader命令行。这样即使App彻底崩溃，也能人工干预。安全性和可维护性，从来不是非此即彼的选择。

2.4 通信协议怎么选？UART够不够用？要不要加校验和重传？

标题没提通信方式，但这是OTA落地的关键。我见过太多人花三个月调通AB分区，结果卡在UART收包丢帧上。STM32F103的USART1（APB2）最高支持4.5Mbps，但实际用921600bps就足够。关键不在波特率，而在协议鲁棒性。简单发一帧二进制固件？不行。真实环境有干扰、线缆长、电源波动。我的方案是三层协议：

物理层：UART，用RS-232电平转换芯片（如MAX3232），避免TTL直连的噪声敏感；
链路层：YModem协议（带CRC16校验、128字节分包、ACK/NACK重传）；
应用层：自定义包头（SOH+长度+命令码+序列号+数据+CRC32）。

为什么不用HTTP或MQTT？因为F103没RAM跑TCP/IP栈。YModem成熟、轻量、有现成PC端工具（如XShell的发送文件功能）。实测在20米双绞线、工频干扰环境下，YModem丢包率<0.1%，而裸UART二进制传输丢包率达15%。重传机制不是可选项——它是底线。我在Bootloader里实现超时重传（3次），每次间隔200ms，超时后主动发NACK请求重发。这增加不到2KB代码，却让升级成功率从83%提升到99.97%。别省这点功夫。

3. 核心细节解析与实操要点

3.1 Flash分区规划：如何避开F103的扇区陷阱

STM32F103的Flash扇区划分是OTA成败的物理基础。F103C8T6的64KB Flash，前4个扇区各1KB（0x08000000–0x08000FFF），后20个扇区各2KB（0x08001000–0x0800FFFF）。但Bootloader必须跨扇区部署——20KB要占20个扇区（前4个+后16个）。如果把Bootloader末尾放在0x08004FFF，那么App A区从0x08005000开始，正好落在第5个扇区（2KB）起始。但问题来了：第5扇区是2KB，而App A区若定为22KB，会横跨11个扇区（5–15），其中第15扇区（0x0800F000）是最后一个2KB扇区。如果升级时B区也从0x0800F000开始，就会和Bootloader的标志页冲突。我的解决方案是：预留专用扇区存标志。把0x0800F000–0x0800FFFF（最后1KB）单独划为Flag Sector，只存boot_flag_t结构体。App A区从0x08005000开始，占11个扇区（22KB）；B区从0x0800A000开始（跳过A区末尾），同样占11个扇区。这样A/B区完全不重叠，Flag Sector独立，擦写互不影响。链接脚本（.ld文件）关键段：

MEMORY { FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 20K } SECTIONS { .bootloader : { *(.bootloader) } > FLASH .app_a : { *(.app_a) } > FLASH AT > 0x08005000 .app_b : { *(.app_b) } > FLASH AT > 0x0800A000 .flag : { *(.flag) } > FLASH AT > 0x0800F000 }

注意.app_a和.app_b的AT地址，这是告诉链接器“代码放这里，但加载地址是这里”。编译App时，必须用-Wl,-T,app_a.ld指定链接脚本，否则代码会默认从0x08000000开始，覆盖Bootloader。

3.2 启动流程控制：Bootloader如何安全跳转到App

跳转不是((void(*)())(0x08005000))();一行代码搞定。F103的向量表在Flash首地址，App的向量表必须复制到SRAM才能正常响应中断。我的跳转函数长这样：

void jump_to_app(uint32_t app_addr) { uint32_t *app_vector = (uint32_t*)app_addr; uint32_t app_sp = app_vector[0]; // 栈顶地址 uint32_t app_reset = app_vector[1]; // 复位向量 // 关闭所有外设时钟，防止App初始化冲突 RCC->APB1ENR = 0x00000000; RCC->APB2ENR = 0x00000000; RCC->AHBENR = 0x00000000; // 设置MSP（主栈指针） __set_MSP(app_sp); // 复制向量表到SRAM（0x20000000起） for(int i=0; i<48; i++) { // STM32F103有48个中断向量 SCB->VTOR = 0x20000000; ((uint32_t*)0x20000000)[i] = app_vector[i]; } // 清空中断挂起寄存器 for(int i=0; i<2; i++) { SCB->ICSR = 0x00000000; } // 跳转 ((void(*)())app_reset)(); }

重点在三步：关外设时钟（避免App初始化时GPIO/USART冲突）、复制向量表（否则中断全指向Bootloader）、清挂起寄存器（防止未处理中断触发）。我试过不复制向量表，结果App里串口一发数据就HardFault——因为中断向量还在Bootloader区。这个细节，90%的教程都漏掉。

3.3 固件校验机制：CRC32不是摆设，怎么算才准？

校验不是“算个CRC存起来”就完事。F103没有硬件CRC，得用软件算法。但网上流传的CRC32查表法，直接拿来用会出错——因为STM32的Flash读取是32位对齐的，而固件bin文件是字节流。如果按字节计算CRC，和按32位字计算结果不同。我的方案是：统一按32位字计算。App固件bin文件用fromelf --bin生成后，用Python脚本预处理：

def calc_crc32_bin(bin_file): with open(bin_file, 'rb') as f: data = f.read() # 补零到4字节对齐 pad_len = (4 - len(data) % 4) % 4 data += b'\x00' * pad_len # 按32位字解析 words = struct.unpack('<{}I'.format(len(data)//4), data) crc = 0xFFFFFFFF for w in words: crc ^= w for _ in range(32): if crc & 0x80000000: crc = (crc << 1) ^ 0x04C11DB7 else: crc <<= 1 crc &= 0xFFFFFFFF return crc ^ 0xFFFFFFFF

Bootloader里用同样算法校验。实测对比：按字节算CRC32，和按字算差3个bit；按字算，和PC端完全一致。校验位置也很关键——不是只校验App区开头，而是校验整个App区内容（22KB）。我在Bootloader里用DMA+CRC外设（F103有CRC单元）加速，10ms内完成，比纯软件快5倍。

3.4 AB分区切换：标志位更新为何要“双写+校验”？

更新启动标志看着简单，实则最易出错。常见错误是：直接*(uint8_t*)FLAG_ADDR = 1;。这不行。Flash写入是按页（1KB）进行的，单字节写要先擦整个页。而Flag Sector只有1KB，擦一次就清空所有标志。我的方案是“双写+校验”：在Flag Sector里存两份boot_flag_t，一份在0x0800F000，一份在0x0800F400。更新时：

擦除整个Flag Sector（1KB）；
先写第一份（0x0800F000），校验magic；
再写第二份（0x0800F400），校验magic；
最后写入crc32。 Bootloader启动时，读两份，取magic和crc32都正确的那份。这样即使写第一份时断电，第二份仍完好，下次启动能恢复。我测试过，在写第一份中途断电，系统仍能正确识别第二份并启动。这个设计增加了20行代码，但换来99.99%的切换可靠性。

4. 实操过程与核心环节实现

4.1 Bootloader开发：从零创建工程的5个关键步骤

用STM32CubeMX生成Bootloader工程，不是点几下就行。以下是必须手动干预的5步：

第一步：设置系统时钟和Flash等待周期
F103默认HSI 8MHz，但IAP写Flash要求≥24MHz。CubeMX里勾选PLL，HCLK=72MHz。更重要的是Flash等待周期：72MHz下必须设为2WS（Wait State），否则写入失败。在SystemClock_Config()里加：

FLASH->ACR |= FLASH_ACR_LATENCY_2; // 2 wait states

第二步：禁用所有中断向量重映射
Bootloader必须用主Flash向量表，不能映射到SRAM或System Memory。CubeMX生成的代码默认开启重映射，得删掉：

// 删除这行 // SYSCFG->MEMRMP = SYSCFG_MEMRMP_SWP_FMC;

第三步：分配独立RAM区域给Bootloader
Bootloader代码小，但栈要够用。在startup_stm32f103xb.s里改：

Stack_Size EQU 0x00000400 ; 1KB栈，原先是0x00000200

并在main.c开头声明：

uint8_t bootloader_stack[1024] __attribute__((section(".bss.stack")));

第四步：实现Flash擦写函数
CubeMX没生成IAP函数，得自己写。关键是要等BUSY标志：

HAL_StatusTypeDef flash_erase_page(uint32_t page_addr) { FLASH_EraseInitTypeDef erase; uint32_t page_error; erase.TypeErase = TYPEERASE_PAGES; erase.PageAddress = page_addr; erase.NbPages = 1; HAL_FLASHEx_Erase(&erase, &page_error); while(__HAL_FLASH_GET_FLAG(FLASH_FLAG_BSY)); // 等待忙标志 return HAL_OK; }

第五步：配置中断向量表偏移
Bootloader的向量表在0x08000000，但App的在0x08005000。CubeMX生成的HAL_Init()会设SCB->VTOR = FLASH_BASE，这不对。得在main()开头手动设：

SCB->VTOR = 0x08000000; // 强制指向Bootloader向量表

做完这5步，Bootloader才能稳定运行。我见过太多人卡在第4步——没等BUSY标志，擦写就返回，结果Flash内容错乱。

4.2 App工程配置：如何让App“不知道”自己在AB分区里

App开发者不该关心AB分区细节，这是Bootloader的事。所以App工程要伪装成“普通单分区程序”。CubeMX配置时：

SysTick时钟源选Core Clock（72MHz），不要选HCLK/8；
启用HAL库的延迟函数（HAL_Delay()），但禁用HAL_IncTick()——因为SysTick中断由Bootloader管理，App里自己启会冲突；
所有外设初始化后，调用HAL_NVIC_SetVector()重定向中断向量：

HAL_NVIC_SetVector(USART1_IRQn, 0x08005004); // App向量表偏移4字节

这样App的中断就指向自己的向量表，不依赖Bootloader。

链接脚本（app_a.ld）关键：

_estack = 0x20005000; /* SRAM末尾 */ /* App从0x08005000开始，但向量表在0x08005000，代码从0x08005004 */ SECTIONS { .isr_vector : { . = ALIGN(4); KEEP(*(.isr_vector)) . = ALIGN(4); } > FLASH AT > 0x08005000 .text : { *(.text) *(.rodata) } > FLASH AT > 0x08005004 }

编译App时，用arm-none-eabi-gcc -T app_a.ld ...，确保代码不覆盖向量表。这样App开发者只需写业务逻辑，编译出的bin文件，Bootloader就能无缝加载。

4.3 OTA升级流程：YModem协议在Bootloader中的完整实现

Bootloader的YModem接收不是“收完再校验”，而是边收边校验+分块擦写。流程如下：

握手阶段：Bootloader发C字符，等待PC端发SOH包（128字节）；
数据接收：每收到一个包，先校验CRC16，错则发NAK重传；
写入Flash：不是攒满22KB再写，而是每包（128B）写一次。因为F103 Flash写入最小单位是半字（16位），128B需64次写操作。我在接收中断里加缓冲：

#define YMODEM_BUF_SIZE 128 uint8_t ymodem_buf[YMODEM_BUF_SIZE]; uint32_t write_addr = APP_B_START; // B区起始地址 void USART1_IRQHandler(void) { static uint16_t buf_idx = 0; uint8_t rx; if(__HAL_UART_GET_FLAG(&huart1, UART_FLAG_RXNE)) { rx = huart1.Instance->DR; if(buf_idx < YMODEM_BUF_SIZE) { ymodem_buf[buf_idx++] = rx; } if(buf_idx == YMODEM_BUF_SIZE) { // 校验CRC16 if(check_crc16(ymodem_buf, 128)) { // 写入Flash for(int i=0; i<128; i+=2) { HAL_FLASH_Program(FLASH_TYPEPROGRAM_HALFWORD, write_addr+i, *(uint16_t*)(ymodem_buf+i)); } write_addr += 128; HAL_UART_Transmit(&huart1, (uint8_t*)"ACK", 3, 100); } else { HAL_UART_Transmit(&huart1, (uint8_t*)"NAK", 3, 100); } buf_idx = 0; } } }

结束包处理：收到SOH包，数据全0，表示结束。此时校验整个B区CRC32，成功则更新Flag，失败则清B区。

这个设计让内存占用降到最低（只用128B缓冲），且断电后B区最多丢失最后一包，不影响整体校验。

4.4 调试与验证：用J-Link和逻辑分析仪抓关键信号

没调试工具，AB分区OTA就是盲人摸象。我必用的三件套：

J-Link Commander：查Flash内容是否写对。升级后连J-Link，执行：

JLink>loadbin firmware.bin 0x0800A000 JLink>mem32 0x0800A000 10 // 查前10个字 JLink>r // 读寄存器，看SP/PC是否指向B区

如果mem32显示全是0xFF，说明擦除失败；如果前4字是0x20005000（栈顶），说明App加载成功。

Saleae Logic 8：抓UART波形看YModem协议。关键看三点：

C字符后，PC是否在1秒内发SOH（否则Bootloader超时）；
每包后是否有ACK（没发说明CRC错）；
结束包是否为SOH+128个0x00。

ST-Link Utility：快速烧录Bootloader。比J-Link更稳，尤其对国产ST-Link clone。烧录时勾选“Verify programming”，避免烧录错误。

有一次，客户升级失败，我用Logic抓到PC端发了EOT（End of Transmission）而不是SOH结束包，原因是XShell版本太老。换SecureCRT后问题消失。工具链的兼容性，比代码本身还重要。

5. 常见问题与排查技巧实录

5.1 升级后黑屏：90%是向量表没复制或栈指针错

现象：升级完成，设备上电黑屏，J-Link连上显示PC在0xFFFFFFFE。这是典型的跳转失败。排查路径：

用J-Link读0x0800A000，看前4字是否为有效栈地址（应在0x20000000–0x20005000）；
读0x0800A004，看是否为有效复位向量（应在0x0800A000–0x0800F000）；
如果前4字是0x00000000，说明App没写进B区——查YModem接收函数，是否write_addr没递增；
如果前4字正确，但PC在0xFFFFFFFE，说明跳转后没执行——查__set_MSP()是否生效，用J-Link Debugger单步看MSP寄存器值。

我遇到过最诡异的一次：App的.isr_vector段被链接器优化掉了，因为CubeMX没勾选“Generate ISR handlers”。解决方案：在main.c里加__attribute__((used))强制保留：

__attribute__((used)) const uint32_t vector_table[] __attribute__((section(".isr_vector"))) = { 0x20005000, // MSP 0x0800A004, // Reset // ... 其他向量 };

5.2 校验失败：CRC32不一致的3个隐藏原因

CRC32对不上，别急着改算法。先查这三点：

Flash读取字节序：F103是小端，但bin文件是字节流。如果按大端解析，CRC必错。确认Python脚本用struct.unpack('<{}I'...)（小端）；
填充字节位置：bin文件末尾补零，但App代码里可能把填充当有效数据校验。我的方案是：CRC计算范围严格限定为App实际代码长度（从0x0800A000到0x0800A000+app_size），不包含填充；
Bootloader读Flash方式：用*(__IO uint32_t*)addr读，还是HAL_FLASH_Read()？后者会触发Flash控制器，前者直接读总线。我用前者，因为快且稳定。

实测：同一bin文件，用HAL_FLASH_Read()校验慢3倍，且偶发读错——因为Flash控制器在擦写时忙，读取返回0。

5.3 AB切换失败：标志位更新后仍启动旧区

现象：更新Flag后，重启还是进A区。原因通常是：

Flag Sector没擦除：直接写，Flash写入失败（必须先擦）；
Magic值写错：0x5AA55AA5写成0x5AA55AA4，Bootloader校验失败，回退到默认A区；
CRC32没更新：改了active_bank，但忘了重算crc32，Bootloader认为标志损坏，弃用。

我的调试技巧：升级后，用J-Link读0x0800F000，看4字节magic是否为0x5AA55AA5，第5字节active_bank是否为0x01，最后4字节crc32是否匹配计算值。三者缺一不可。

5.4 J-Link连接失败：BOOT0/BOOT1引脚的生死线

F103的启动模式由BOOT0/BOOT1决定：

BOOT0=0, BOOT1=x → 从主Flash启动（正常）；
BOOT0=1, BOOT1=0 → 从系统存储器启动（ST出厂Bootloader）；
BOOT0=1, BOOT1=1 → 从SRAM启动（极少用）。

升级失败后连不上J-Link，90%是BOOT0被意外拉高。检查PCB：BOOT0是否接10K上拉电阻？是否被其他电路干扰？我的经验是：在BOOT0和地之间加100nF电容滤波，避免噪声误触发。另外，J-Link的SWDIO/SWCLK线长超过10cm时，必须加22Ω串联电阻抑制反射，否则握手失败。

5.5 低功耗场景下的OTA陷阱：Stop Mode唤醒后Flash不可写

客户做电池供电设备，要求OTA时进Stop Mode省电。结果升级失败——Stop Mode下Flash控制器关闭，HAL_FLASH_Program()返回HAL_ERROR。解决方案：OTA全程禁用Stop Mode，用HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI)前，先检查是否在升级中。我在Bootloader加全局变量：

volatile uint8_t ota_in_progress = 0; void start_ota() { ota_in_progress = 1; // ... OTA流程 } // 在低功耗函数里 void enter_low_power() { if(!ota_in_progress) { HAL_PWR_EnterSTOPMode(...); } }

这样既保续航，又不牺牲OTA可靠性。