企业官网建设流程全解析

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

你手头有一块跑着温控算法的STM32F103最小系统板，正部署在工厂车间的PLC从站里。某天凌晨三点，客户电话打来：“升级后设备死机，产线停了两小时。”你翻出升级日志——原来新固件里一个ADC采样时序参数写错了，但旧版本早已被覆盖，回滚？没留后路。这就是没有AB分区的OTA最真实的代价：一次失败，就是一次不可逆的现场事故。

AB分区OTA，本质不是给单片机加个“软件更新按钮”，而是构建一套嵌入式系统的故障容错机制。它把Flash划成两个独立区域（A区和B区），每次升级不覆盖当前运行的固件，而是写入另一个空闲区；校验通过后，Bootloader才切换启动地址。哪怕新固件存在严重bug、甚至编译出错导致跳转非法地址，系统重启后仍能自动回退到上一个稳定版本——这才是工业场景下OTA的底线要求。

我做过7个基于STM32F103的量产项目，其中4个因早期未采用AB分区，在现场升级中遭遇过至少1次“变砖”事件。最典型的是某智能电表项目：升级包在传输中途因RS485总线干扰丢包，Bootloader误将残缺固件写入主区，整批设备需返厂重烧。后来我们强制推行AB方案，配合CRC32+SHA256双校验，三年内零现场回退失败。这不是炫技，是用空间换时间、用Flash容量换系统鲁棒性——F103虽只有128KB Flash，但只要合理规划，完全能撑起AB双区（A区64KB运行App，B区64KB待升级，再留4KB给Bootloader，足够）。

这个教程叫“从零复现”，意味着不依赖STM32CubeMX自动生成的复杂框架，也不用HAL库里封装好的IAP函数。我们要亲手写Bootloader跳转逻辑、手动解析固件头、逐字节校验Flash写入、设计分区状态标志位——因为只有抠到寄存器级，你才能真正理解：为什么SCB->VTOR = APP_BASE_ADDR必须在跳转前执行；为什么擦除B区前要先清除RCC->CR里的PLLON位；为什么__set_MSP(*(uint32_t*)APP_BASE_ADDR)这行代码少一个星号就会导致HardFault。这些细节，恰恰是网上90%的“OTA教程”刻意回避的雷区。

适合谁学？如果你正在用STM32F103做工业控制、医疗设备或任何不允许远程“变砖”的产品，这个教程就是你的保命手册。如果你只是想做个LED闪烁OTA演示，那大可去抄几行HAL库代码——但请记住，真实世界里，客户不会为“演示成功”买单，只会为“永不宕机”付费。

2. 整体架构设计：为什么放弃“单区覆盖式OTA”，而选择AB分区的硬核取舍

2.1 AB分区 vs 单区OTA：一场关于“失败成本”的计算

单区OTA的逻辑极其简单：下载新固件 → 擦除当前App区 → 写入新固件 → 跳转执行。看似高效，实则暗藏三重致命风险：

• 传输中断风险：若升级过程遭遇断电、通信丢包或看门狗复位，Flash中残留半截固件，重启后Bootloader加载非法代码，直接HardFault；
• 校验盲区风险：多数教程只在校验整个固件文件MD5，但Flash物理写入可能因电压波动导致某一页写入失败（如第0x08008000页写入时VDD跌落），MD5校验仍通过，运行时却在该页触发BusFault；
• 回滚无解风险：一旦覆盖，旧版本彻底消失，现场工程师只能带J-Link烧录器赶往百公里外的客户现场。

AB分区用明确的空间隔离规避了上述问题。其核心设计哲学是：永远保留一个已知可用的固件副本。A区运行时，B区用于接收新固件；B区校验通过后，Bootloader修改启动标志位，下次重启即从B区启动；若B区启动失败，Bootloader检测到标志异常，自动回退至A区——整个过程无需人工干预。

提示：有人质疑“F103 Flash太小，AB分区太奢侈”。实测数据：某温控终端App仅占用42KB，预留2KB升级头（含CRC、版本号、签名），AB双区共需88KB，占128KB Flash的68.75%，完全可行。关键在于精简App代码——去掉未使用的STD库函数、关闭浮点运算、用汇编重写关键中断服务例程，可再压缩15%空间。

2.2 Bootloader与App的边界划分：地址空间与权限的铁律

STM32F103的Flash从0x08000000开始，共128KB。我们按如下方式硬性划分：

这个划分不是随意的。F103的启动流程规定：复位后CPU从0x08000000读取MSP初始值，从0x08000004读取Reset_Handler地址。因此Bootloader必须严格置于0x08000000，且其向量表首地址必须是0x08000000。而App的向量表不能放在默认位置（否则会与Bootloader冲突），必须通过NVIC_SetVectorTable(NVIC_VectTab_FLASH, APP_BASE_ADDR)重映射——这是AB分区能工作的前提。

注意：很多初学者在CubeMX里勾选“IAP”选项后，生成的Bootloader会把App起始地址设为0x08002000，这会导致A/B区只剩不到60KB，且与标准Bootloader地址冲突。务必手动修改链接脚本（stm32f103xb.ld），将Bootloader段定义为：

.bootloader : { . = ALIGN(4); _bootloader_start = .; *(.bootloader) . = ALIGN(4); _bootloader_end = .; } > FLASH

并在Bootloader源码中用__attribute__((section(".bootloader")))标记关键函数，确保它们被链接到指定区域。

2.3 分区状态管理：用32位标志位实现原子性切换

AB分区的核心难点不在写入，而在“如何安全地告诉Bootloader：下次该从哪边启动”。常见错误做法是用Flash某一页存储“active=0x01”这样的字符串——但Flash擦除以页（1KB）为单位，写入以字（4字节）为单位，若在擦除页时断电，整个页数据丢失，状态标志归零，系统将无法判断该启哪个区。

我们采用双标志位+校验和的原子切换方案：

• 在Bootloader末尾预留4字节（0x08003FFC）作为状态寄存器；
• 定义两个标志位：ACTIVE_A = 0xA5A5A5A5，ACTIVE_B = 0x5A5A5A5A；
• 切换逻辑：
  1. 校验B区固件完整性（CRC32 + SHA256）；
  2. 若通过，向状态寄存器写入ACTIVE_B；
  3. 执行FLASH_ErasePage(0x08003FFC)（注意：此地址所在页是Bootloader专属页，不与其他区共享）；
  4. 再写入ACTIVE_B；
  5. 关键步骤：调用FLASH_ProgramWord(0x08003FFC, ACTIVE_B)，而非分多次写入；
  6. 确保写入后读回验证。

为什么这样更安全？因为Flash编程操作本身是原子的（单字写入失败则整字无效），且状态寄存器独占一页，避免与其他数据擦写冲突。Bootloader启动时仅需读取该地址的值，即可确定启动区——无需解析文件系统、无需遍历Flash，毫秒级决策。

实测对比：某项目曾用字符串标志方案，在1000次模拟断电测试中，有7次状态丢失导致启动失败；改用双标志位后，10000次测试零失败。这不是玄学，是Flash物理特性的必然结果。

3. 核心模块实现：从Bootloader跳转到App的每一行代码都关乎成败

3.1 Bootloader启动流程：复位后的第一行指令究竟在做什么

当STM32F103按下复位键，硬件执行以下不可更改的序列：

1. CPU从0x08000000读取MSP初始值（栈顶地址）；
2. 从0x08000004读取Reset_Handler函数地址；
3. 跳转至该地址执行Bootloader的Reset_Handler。

此时，Bootloader的C环境尚未初始化——全局变量未清零、.data段未复制、.bss段未置零。因此，Bootloader的Reset_Handler必须手动完成这些工作，否则后续代码可能读取到随机值。

标准Bootloader启动代码（精简版）：

void Reset_Handler(void) { // 1. 初始化栈指针（硬件已做，此处仅确认） __set_MSP(*((uint32_t*)0x08000000)); // 2. 手动复制.data段（从Flash到RAM） uint32_t *flash_data = (uint32_t*)0x08004000; // 假设.data存于App区起始 uint32_t *ram_data = &_sidata; uint32_t *ram_data_end = &_edata; while(ram_data < ram_data_end) { *ram_data++ = *flash_data++; } // 3. 清零.bss段 uint32_t *bss_start = &_sbss; uint32_t *bss_end = &_ebss; while(bss_start < bss_end) { *bss_start++ = 0; } // 4. 调用main main(); }

实操心得：很多人忽略.data段复制，导致Bootloader里定义的全局变量（如uint32_t upgrade_flag）始终为0。用调试器观察内存：复位后0x20000000（SRAM起始）处是否为预期值？若否，一定是.data未正确复制。CubeMX生成的startup_stm32f103xb.s里有完整复制逻辑，但需确认链接脚本中_sidata、_edata等符号定义准确。

3.2 App跳转的四步铁律：缺一不可的寄存器配置

从Bootloader跳转到App，绝非简单((void(*)(void))app_entry)()就能搞定。F103的ARM Cortex-M3内核要求严格的上下文切换，否则必然HardFault。必须执行以下四步：

1. 禁用所有中断：防止跳转过程中中断服务例程（ISR）抢占执行；
2. 重映射中断向量表：将NVIC向量表基址指向App的Flash起始地址；
3. 设置主栈指针（MSP）：从App的向量表首地址读取新的栈顶值；
4. 加载复位处理函数并跳转：从App向量表第二项（0x04偏移）读取Reset_Handler地址。

完整跳转函数：

typedef void (*pFunction)(void); void Jump_To_Application(uint32_t app_addr) { pFunction Jump_To_App; uint32_t *jump_address; // 1. 关闭所有中断 __disable_irq(); // 2. 重映射向量表（关键！） SCB->VTOR = app_addr; // app_addr = 0x08004000 或 0x0800C000 // 3. 设置MSP（从App向量表首地址读取） jump_address = (uint32_t*)app_addr; __set_MSP(*jump_address); // 注意：*jump_address 是栈顶地址 // 4. 获取App的Reset_Handler地址（向量表第二项） Jump_To_App = (pFunction)(*(jump_address + 1)); // 5. 清除所有挂起的中断（重要！） SCB->ICSR = SCB_ICSR_PENDSVCLR_Msk | SCB_ICSR_PENDSTCLR_Msk; // 6. 跳转 Jump_To_App(); }

注意：SCB->VTOR = app_addr必须在__set_MSP之前执行。因为MSP设置后，若此时发生NMI，CPU会从新VTOR地址读取向量，若VTOR未更新，将访问Bootloader向量表，导致崩溃。我曾在一个项目中因这两行顺序颠倒，导致App启动后10秒必HardFault，调试三天才发现是VTOR时机问题。

3.3 固件头解析：为什么必须自己定义升级包格式

网上多数教程直接用memcpy把整个bin文件写入Flash，这是重大隐患。bin文件不含元信息，Bootloader无法知道：

• 这个固件是给A区还是B区？
• 版本号是多少？是否允许降级？
• CRC32校验值在哪？如何定位？

我们定义极简但完备的固件头（128字节）：

#pragma pack(1) typedef struct { uint32_t magic; // 固定值0x41424344 ("ABCD") uint32_t version; // 版本号，如0x01000000表示v1.0.0 uint32_t target_addr; // 目标写入地址，0x0800C000或0x08004000 uint32_t image_size; // 有效固件大小（不含头） uint32_t crc32; // 整个固件（含头）的CRC32 uint8_t reserved[108]; // 预留扩展 } firmware_header_t; #pragma pack()

升级流程中，Bootloader首先读取前128字节，验证magic和crc32；若通过，再根据target_addr决定写入A区或B区，并用image_size控制写入长度——避免因bin文件末尾填充导致Flash溢出。

实操技巧：CRC32计算必须包含固件头本身。很多开发者只校验App代码段，结果固件头被篡改（如version字段被恶意修改）却无法发现。用crc32.c标准实现，输入缓冲区为firmware_bin整个数组，长度为sizeof(firmware_header_t) + image_size。

4. OTA升级全流程：从串口接收固件到双区切换的每一步实操

4.1 串口接收协议设计：如何让升级过程抗干扰、可恢复

工业现场RS232/RS485通信极易受干扰，单靠UART中断接收bin文件必然丢包。我们采用分块校验+断点续传协议：

• 将固件切分为256字节固定块（最后一块不足256字节按实际大小）；
• 每块发送格式：[SOH][块序号(2字节)][块数据(256字节)][CRC16(2字节)][ETX]；
• Bootloader收到完整块后，计算CRC16，若匹配则写入RAM缓存，并回复ACK；否则回复NAK，请求重发；
• 若连续3次NAK，则返回ERROR并终止升级。

关键设计点：

• SOH（0x01）和ETX（0x04）作为帧头尾，避免数据中出现相同字节导致误解析；
• 块序号从0开始，Bootloader维护last_received_block变量，若收到非期望序号（如应收到#5却收到#7），立即回复NAK；
• RAM缓存大小设为512字节（2块），避免大缓存占用宝贵SRAM。

接收函数核心逻辑：

#define BLOCK_SIZE 256 uint8_t rx_buffer[BLOCK_SIZE]; uint16_t block_index = 0; uint16_t expected_block = 0; void UART_IRQHandler(void) { if(USART_GetITStatus(USART1, USART_IT_RXNE) != RESET) { uint8_t byte = USART_ReceiveData(USART1); switch(state) { case WAIT_SOH: if(byte == 0x01) state = GET_BLOCK_INDEX; break; case GET_BLOCK_INDEX: block_index = byte << 8; state = GET_BLOCK_INDEX_LO; break; case GET_BLOCK_INDEX_LO: block_index |= byte; if(block_index != expected_block) { send_nak(); return; } state = GET_DATA; rx_count = 0; break; case GET_DATA: rx_buffer[rx_count++] = byte; if(rx_count >= BLOCK_SIZE) { state = GET_CRC; crc_pos = 0; } break; case GET_CRC: crc_buf[crc_pos++] = byte; if(crc_pos == 2) { uint16_t calc_crc = calc_crc16(rx_buffer, BLOCK_SIZE); uint16_t recv_crc = (crc_buf[0] << 8) | crc_buf[1]; if(calc_crc == recv_crc) { write_to_flash(block_index, rx_buffer, BLOCK_SIZE); send_ack(); expected_block++; } else { send_nak(); } state = WAIT_SOH; } break; } } }

注意事项：calc_crc16必须使用标准CRC-16/IBM多项式（0x8005），且初始值、最终异或值需与上位机工具一致。我曾因上位机用CRC-16/CCITT而Bootloader用CRC-16/IBM，导致所有块校验失败，排查两天才发现是多项式差异。

4.2 Flash写入与擦除：如何避免“写入一半掉电”导致分区损坏

STM32F103的Flash擦除以页（1KB）为单位，写入以半字（2字节）为单位。但OTA升级需写入整块固件，必须精确控制擦除范围——擦多浪费时间，擦少则写入失败。

B区起始地址0x0800C000，大小64KB，共64页（每页1KB）。写入前需擦除所有相关页：

// 计算需擦除的页范围 uint32_t start_addr = 0x0800C000; uint32_t end_addr = start_addr + image_size; uint32_t page_start = start_addr / 1024; uint32_t page_end = end_addr / 1024; if(end_addr % 1024 != 0) page_end++; // 逐页擦除 for(uint32_t page = page_start; page <= page_end; page++) { FLASH_ErasePage(0x08000000 + page * 1024); }

写入时，必须按半字对齐（16位）写入，且每次写入前检查目标地址是否已擦除（全0xFFFF）：

void flash_write_halfword(uint32_t addr, uint16_t data) { FLASH_Unlock(); FLASH_ClearFlag(FLASH_FLAG_EOP | FLASH_FLAG_PGERR | FLASH_FLAG_WRPRTERR); // 检查是否已擦除 if(*(uint16_t*)addr != 0xFFFF) { // 未擦除，跳过或报错 return; } FLASH_ProgramHalfWord(addr, data); FLASH_Lock(); }

实操心得：F103的Flash编程时间约20μs/半字，但若在写入过程中触发SysTick中断，可能导致Flash控制器状态机紊乱。因此，写入关键区域时务必__disable_irq()，写完再__enable_irq()。某项目曾因未关中断，导致B区第3页写入失败，升级后启动卡死，最终用ST-Link Utility读取Flash发现该页数据全为0x0000。

4.3 双区校验与切换：如何让回滚真正“零延迟”

校验不是简单读取Flash计算CRC，而是分页校验+状态快照：

1. 将A区或B区按页（1KB）分割；
2. 对每页计算CRC32，结果存入RAM数组；
3. 所有页校验通过后，再计算整个区的总CRC32；
4. 若任一页失败，立即标记该区为“损坏”，不执行切换。

切换状态标志位的代码必须包含双重写入验证：

void set_active_partition(uint32_t partition_flag) { // 先擦除状态页 FLASH_Unlock(); FLASH_ErasePage(0x08003FFC); // 写入标志 FLASH_ProgramWord(0x08003FFC, partition_flag); // 验证写入 uint32_t readback = *(uint32_t*)0x08003FFC; if(readback != partition_flag) { // 写入失败，尝试重写 FLASH_ProgramWord(0x08003FFC, partition_flag); } FLASH_Lock(); }

Bootloader启动时的分区选择逻辑：

uint32_t get_active_partition(void) { uint32_t flag = *(uint32_t*)0x08003FFC; // 检查标志有效性 if(flag == ACTIVE_A || flag == ACTIVE_B) { return flag; } else { // 无效标志，启用安全模式：运行A区 return ACTIVE_A; } }

常见问题：某客户现场升级后设备反复重启。抓取Bootloader日志发现，每次启动都读取到flag=0x00000000。用ST-Link读取0x08003FFC地址，发现该字节被意外写为0x00——根源是客户软件在App中误操作了Flash控制寄存器。解决方案：在Bootloader中增加标志位保护，写入前检查FLASH->CR的PER和PG位是否为0，否则拒绝写入。

5. 常见问题与避坑指南：那些官方文档绝不会告诉你的实战陷阱

5.1 J-Link烧录失败：Boot1引脚与启动模式的隐秘关联

F103的启动模式由BOOT0和BOOT1引脚电平决定：

• BOOT0=0, BOOT1=x：从主Flash启动（正常模式）；
• BOOT0=1, BOOT1=0：从系统存储器启动（进入ROM Bootloader）；
• BOOT0=1, BOOT1=1：从SRAM启动（极少用）。

问题现象：用J-Link烧录Bootloader后，设备无法启动，ST-Link Utility显示“Device not found”。

根本原因：BOOT1引脚（PA14）在某些最小系统板上未接地或悬空。当BOOT0=0（正常启动）时，BOOT1若为高电平，芯片会尝试从SRAM启动，但SRAM无代码，直接死机。

解决方案：

• 硬件：在PCB上将BOOT1（PA14）通过10kΩ电阻下拉至GND；
• 软件：烧录前确认J-Link配置中“Reset Strategy”设为“Hardware Reset”，并勾选“Connect under reset”；
• 调试：用万用表测量PA14对地电压，必须≤0.3V。

实操记录：某批次PCB因BOOT1未下拉，100块板中有32块烧录失败。返工时用烙铁点焊下拉电阻，100%解决。这个细节在ST官方Datasheet第32页“Boot configuration”有说明，但极易被忽略。

5.2 HAL库IAP冲突：为什么CubeMX生成的代码会破坏AB分区

CubeMX默认生成的SystemInit()函数中，会调用SetSysClock()配置系统时钟。该函数内部执行：

RCC->CFGR &= (uint32_t)~(RCC_CFGR_SW); RCC->CFGR |= RCC_CFGR_SW_PLL; // 切换到PLL while ((RCC->CFGR & (uint32_t)RCC_CFGR_SWS) != RCC_CFGR_SWS_PLL) {}

问题在于：若Bootloader已配置好时钟（如HSI+PLL=72MHz），App再次执行此流程，会导致PLL重新锁定——在此期间，Flash控制器可能因时钟不稳而写入失败。更严重的是，RCC->CR中的PLLON位被重复操作，可能触发Flash写保护。

规避方案：

• 在App的main()开头，注释掉SystemClock_Config()调用；
• 手动复制Bootloader的时钟配置代码到App中，确保时钟状态继承；
• 或在SystemClock_Config()中添加判断：

if((RCC->CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_PLL) { // 仅当未锁定PLL时才配置 SetSysClock(); }

5.3 中断向量表重映射失效：NVIC_VectTab_FLASH的地址陷阱

NVIC_SetVectorTable(NVIC_VectTab_FLASH, APP_BASE_ADDR)看似简单，但APP_BASE_ADDR必须是页对齐地址（1KB边界）。若App起始地址为0x08004000（对齐），则无问题；但若误设为0x08004010，则SCB->VTOR写入后，CPU仍从0x08004000读取向量表，导致App的中断服务例程无法响应。

验证方法：

• 在App的main()中，添加：

printf("VTOR = 0x%08X\r\n", SCB->VTOR); printf("Vector[0] = 0x%08X\r\n", *(uint32_t*)SCB->VTOR); printf("Vector[1] = 0x%08X\r\n", *(uint32_t*)(SCB->VTOR + 4));

• 正常输出应为：

VTOR = 0x08004000 Vector[0] = 0x20001000 // MSP Vector[1] = 0x08004005 // Reset_Handler（+1因Thumb模式）

若Vector[0]显示0x08000000，则VTOR未生效，检查APP_BASE_ADDR是否页对齐。

5.4 OTA升级后App无法触发中断：SysTick与PendSV的隐藏依赖

某项目升级后，App的HAL_Delay()失效，LED闪烁频率异常。调试发现SysTick_Handler从未执行。

根源：HAL_Init()中调用HAL_NVIC_SetPriority(SysTick_IRQn, ...)，但Bootloader已配置过SysTick，且HAL_NVIC_EnableIRQ(SysTick_IRQn)在Bootloader中执行过。App再次使能时，因优先级寄存器未重置，导致SysTick中断被屏蔽。

解决方案：

• 在App的main()开头，强制重置SysTick：

SysTick->CTRL = 0; // 关闭SysTick SysTick->LOAD = 0; // 清空重装载值 SysTick->VAL = 0; // 清空当前值 HAL_Init(); // 再初始化

• 或更彻底：在Bootloader跳转前，执行SysTick->CTRL = 0，确保App启动时SysTick处于干净状态。

最后分享一个小技巧：在Bootloader中加入“强制回滚”按键。长按USER_KEY 5秒，Bootloader无视状态标志，直接跳转至另一分区。这在客户现场升级失败时，能避免工程师千里奔波——毕竟，最好的OTA方案，是让用户永远感觉不到它的存在。