企业官网建设流程全解析

1. 为什么AB分区OTA不是“高级功能”，而是STM32F103必须补上的基础课

我第一次在客户现场看到他们用U盘拷贝固件、手动短接BOOT0引脚、再用ST-Link烧写新程序时，心里就咯噔一下——这哪是工业设备升级，分明是十年前的单片机开发流程。更糟的是，那次升级后设备直接变砖，因为客户误操作导致Flash擦除中断，App区被清空，而Bootloader又没做校验跳转保护，系统卡死在启动失败循环里。后来查日志才发现，他们连最基础的CRC校验都没加，更别说双分区容错机制了。这件事让我意识到：对STM32F103这类资源受限但广泛部署在终端设备上的MCU来说，AB分区OTA根本不是锦上添花的“炫技功能”，而是产品可靠性的生死线。

你可能已经注意到，网上搜“STM32F103 OTA”出来的教程，90%都停留在“串口IAP+单区覆盖升级”的层面。它们确实能跑通，但一旦升级中途断电、通信异常或固件校验失败，设备就再也起不来。而AB分区的核心价值，恰恰在于把“升级失败”这个不可控风险，转化成一个可预测、可回滚、可自动恢复的确定性过程。它不依赖外部工具，不增加硬件成本，只靠合理规划Flash布局和精巧的Bootloader逻辑就能实现——这才是真正适配F103这种64KB Flash、20KB RAM资源的务实方案。

关键词里反复出现的“AB分区”“Bootloader”“UART IAP”，其实指向一个非常具体的工程约束：我们不是在设计一个通用OS级升级框架，而是在一块只有128KB Flash（常见型号如STM32F103C8T6）、72MHz主频、无外部存储的芯片上，用纯C语言和裸机驱动，构建一套能在-40℃~85℃工业环境下稳定运行十年的固件更新机制。这意味着每一个字节的Flash分配都要算清楚，每一次Flash擦写都要考虑寿命（F103的Flash擦写寿命典型值是10K次），每一段跳转代码都必须手写汇编确保栈指针和向量表重映射绝对正确。这不是调库写Demo，这是在资源悬崖边上走钢丝。

所以这篇教程的出发点很明确：不讲虚的架构图，不堆砌抽象概念，只复现一个真实可量产的AB分区OTA最小可行系统。它基于标准外设库V3.5.0（不是HAL库，因为V3.50对F103支持最成熟，且Bootloader对底层寄存器操作要求极高，HAL的抽象层反而增加不确定性），使用UART1作为升级通道（避开USART3在部分封装上的引脚冲突问题），完全兼容J-Link和ST-Link两种调试器，且所有代码均可直接编译进Keil MDK-ARM v5.29环境。接下来每一环节，我都将告诉你“为什么必须这样写”，而不是“照着抄就行”。

1.1 AB分区的本质：不是“两个区”，而是“一次原子切换”

很多人把AB分区理解成“A区放旧固件，B区放新固件，升级时往B区写，写完跳B区运行”。这描述看似正确，实则埋下了第一个大坑——它忽略了Flash擦写操作的非原子性。F103的Flash以页为单位擦除（1KB/页），而固件大小往往跨多页。如果升级过程中断电，B区可能只擦了一半、写了一半，此时若强制跳转，CPU会从非法指令地址开始执行，结果就是HardFault。

真正的AB分区逻辑，核心在于状态标记的原子更新。我们不依赖“B区数据完整”来判断是否可跳转，而是用一个独立、极小、高可靠性的状态标志位（通常放在Option Bytes或最后一页Flash中），这个标志位只记录三个状态：RUNNING_A、UPGRADING_B、RUNNING_B。关键在于：这个标志位的更新必须是单字节写入（F103支持单字节编程），且写入前先擦除所在页（但页擦除本身有风险，所以实际工程中我们会把它放在Option Bytes区域，该区域擦除次数少、可靠性高）。

我实测过，在F103上，Option Bytes的擦除/编程操作耗时约20ms，远低于一页Flash的100ms+，且其耐久性达100K次以上。更重要的是，Option Bytes的写入失败率极低——因为它的控制寄存器（FLASH_OPTCR）有专门的错误检测位（BSY、PGERR、WRPRTERR），Bootloader可以在写入后立即读取这些位确认操作成功。相比之下，把状态标志放在普通Flash页里，一旦该页因老化出现坏块，整个升级机制就瘫痪了。

所以，本教程的AB分区实现，状态标志位固定使用Option Bytes的USER字节（地址0x1FFFF800 + 0x14，即第20个字节）。这个选择不是随意的，而是基于F103 Reference Manual RM0008第3.5.3节的明确规定：USER字节用于用户自定义配置，且在系统复位后由Bootloader自动加载到RCC寄存器，不影响正常启动流程。这意味着我们无需在App中额外初始化，Bootloader读取它即可，干净利落。

1.2 为什么放弃CAN/USB/SD卡，死磕UART IAP？

搜索热词里出现了“CAN STM32F103 SJW同步跳跃宽度”“ESP32 OTA”甚至“腾讯连连 Arduino OTA”，这说明很多人在对比不同升级通道。但回到F103的实际应用场景：它常被用在智能电表、工业传感器、楼宇控制器里，这些设备的物理接口往往只有RS485（本质是UART扩展）或隔离UART。CAN虽然抗干扰强，但需要额外收发器（如TJA1050），成本增加0.5元，且协议栈复杂，Bootloader代码体积暴涨；USB需要OTG PHY和更复杂的枚举流程，F103C8T6根本不带USB；SD卡则需要SPI驱动+文件系统（FatFS），至少增加8KB Flash占用，对64KB总容量来说是奢侈。

UART IAP的优势在于极致简洁：硬件只需两根线（TX/RX）+ GND，软件只需配置一个USART外设+环形缓冲区。我统计过，一个健壮的UART IAP Bootloader（含CRC校验、超时重传、帧头帧尾校验）代码量仅3.2KB，而同等功能的CAN Bootloader要5.8KB，USB的则超过12KB。这对F103意味着什么？——省下的Flash空间，可以多存一个完整的备份App镜像，或者加入更严密的加密验证逻辑。

更重要的是，UART的物理层决定了它的“天然容错性”。当升级包传输出错时，UART不会像CAN那样触发错误帧并中断总线，也不会像USB那样进入挂起状态。它只是静默丢弃错误字节，接收端通过帧头（0xAA55）和长度校验就能识别并丢弃整帧，然后等待下一帧。这种“软失败”机制，让Bootloader的错误处理逻辑变得极其简单：超时未收到有效帧，就返回App区继续运行；收到无效帧，就清空缓冲区重试。没有复杂的错误计数器、总线关闭恢复等状态机，代码可读性和可靠性双双提升。

当然，UART也有短板：速率上限（F103 UART最高4.5Mbps，但实际稳定在115200bps）、无硬件流控（需软件XON/XOFF）、易受共模干扰。本教程的解决方案是：在Bootloader中强制启用DMA接收（避免中断丢失字节），并在App升级前发送握手命令AT+UPGRADE，要求App回复OK后才开启升级模式。这个简单的握手，就把“意外触发升级”的概率降到了几乎为零——因为App只要正常运行，就一定会响应AT指令；只有当App崩溃或未初始化USART时，Bootloader才会超时进入升级等待，此时用户可通过短按按键强制进入。

2. Flash布局的毫米级计算：如何在128KB里塞下Bootloader、A/B App和元数据

STM32F103的Flash地址空间从0x08000000开始，最大128KB（0x08000000 ~ 0x0801FFFF）。但现实是，你永远不能把整个128KB都当成可用空间。F103的Flash被划分为多个扇区（Sector），每个扇区擦除是独立的，而Bootloader必须能单独擦除App区而不影响自身。因此，Flash布局不是画个饼那么简单，而是要精确到字节的毫米级工程。

2.1 F103 Flash扇区结构与擦除代价分析

F103系列（以中密度F103C8为例）的Flash扇区划分如下：

• 扇区0：0x08000000 - 0x08003FFF（16KB）
• 扇区1：0x08004000 - 0x08007FFF（16KB）
• 扇区2：0x08008000 - 0x0800BFFF（16KB）
• 扇区3：0x0800C000 - 0x0800FFFF（16KB）
• 扇区4：0x08010000 - 0x0801FFFF（64KB）

注意：扇区4是唯一一个64KB的大扇区，而前4个都是16KB。这意味着，如果你把Bootloader放在扇区0（16KB），那么A/B App各占一个16KB扇区（扇区1和扇区2），剩下扇区3（16KB）和扇区4（64KB）就浪费了——因为App固件通常大于16KB（V3.50库+业务逻辑轻松破30KB），必须跨扇区，而跨扇区擦除会同时擦掉Bootloader或另一个App区，彻底破坏AB分区逻辑。

我的实测结论是：必须把Bootloader放在扇区4的末尾。原因有三：

1. 扇区4足够大（64KB），足以容纳Bootloader（3.2KB）+ 元数据区（256字节）+ 预留升级缓冲区（4KB）；
2. 扇区4的地址最高（0x08010000 ~ 0x0801FFFF），擦除它不会影响低地址的A/B App区；
3. F103的启动流程规定：复位后从0x08000000取MSP，从0x08000004取Reset_Handler。只要Bootloader的向量表放在0x08000000，它就能先运行，再由它决定跳转到A区还是B区。

因此，最终Flash布局定为：

• Bootloader区：0x0801C000 - 0x0801FFFF（16KB，实际使用3.2KB，留足冗余）
• A App区：0x08000000 - 0x0800BFFF（48KB，覆盖扇区0~2）
• B App区：0x0800C000 - 0x0801BFFF（64KB，覆盖扇区3+扇区4的前半部分）
• 元数据区：0x0801BFE0 - 0x0801BFFF（32字节，存放CRC32、版本号、状态标志）

这个布局的关键洞察在于：A区和B区大小不对称（48KB vs 64KB），但这是刻意为之。因为A区是“主运行区”，必须保证最小App能放下；B区是“升级暂存区”，需要容纳新固件+校验数据。实测表明，一个带FreeRTOS+LwIP+OTA功能的F103固件，压缩后约42KB，解压后58KB，64KB的B区刚好够用，且留有6KB余量用于未来功能扩展。

2.2 向量表偏移：Bootloader跳转App的“灵魂操作”

F103的中断向量表默认在Flash起始地址0x08000000。当Bootloader运行时，它自己的向量表就在0x0801C000。但一旦跳转到App，CPU必须从App的向量表取中断入口，否则任何中断（如SysTick、USART）都会触发HardFault。

标准做法是：在App的startup_stm32f10x_md.s文件中，修改VECT_TAB_OFFSET宏：

; 原始代码（指向0x08000000） ; .equ VECT_TAB_OFFSET, 0x0 ; 修改为（A区App） .equ VECT_TAB_OFFSET, 0x0 ; B区App则改为 .equ VECT_TAB_OFFSET, 0xC000

但这有个致命缺陷：同一个App固件，无法同时适配A/B区。每次编译都要手动改宏，极易出错。

我的解决方案是：在Bootloader跳转前，动态重映射向量表。具体步骤：

1. 在Bootloader中，读取目标App区首地址（如A区0x08000000）的前4字节（MSP初始值）和第4字节（Reset_Handler地址）；
2. 调用SCB->VTOR = 0x08000000;将向量表基址设为App区起始；
3. 关闭所有中断（__disable_irq()），防止跳转瞬间中断抢占；
4. 设置主堆栈指针__set_MSP(*((uint32_t*)app_addr));；
5. 获取复位函数指针typedef void (*pFunction)(void); pFunction Jump_To_Application; Jump_To_Application = (pFunction)(*(uint32_t*)(app_addr + 4));；
6. 执行Jump_To_Application();。

这个方案的优势在于：App固件完全不用修改，编译时VECT_TAB_OFFSET保持为0，其向量表始终放在自身Flash起始处。Bootloader负责在跳转前完成重映射，干净利落。我测试了1000次冷启动，无一次向量表错位导致的HardFault。

提示：动态重映射必须在跳转前完成，且SCB->VTOR写入后需插入__DSB()指令确保写入完成。F103的VTOR寄存器位于System Control Block，地址0xE000ED08，写入后CPU会自动从新地址取向量，无需额外操作。

2.3 元数据区的防呆设计：32字节里藏了5重保险

元数据区（0x0801BFE0 - 0x0801BFFF）虽小，却是AB分区的“大脑”。它存储：

• uint32_t a_crc32;// A区App CRC32校验值
• uint32_t b_crc32;// B区App CRC32校验值
• uint8_t status;// 状态标志：0x00=RUNNING_A, 0x01=RUNNING_B, 0x02=UPGRADING_B
• uint8_t version[16];// A/B区版本字符串，如"v1.2.3"
• uint32_t timestamp;// 最后升级时间戳（秒级）

但仅仅存这些还不够。F103的Flash写入有“只能写0，不能写1”的特性（即擦除后全1，编程时只能把1变0）。这意味着，如果元数据区某字节原本是0xFF，写入0x00没问题；但如果想从0x00改回0xFF，就必须先擦除整个页——而我们把元数据区放在扇区4末尾，擦除它会抹掉Bootloader！

因此，元数据更新采用“滚动写入”策略：不是覆盖旧值，而是写入新值到下一个地址，并用一个“当前有效索引”指针指向最新数据。本教程使用3个副本（地址0x0801BFE0, 0x0801BFE8, 0x0801BFF0），每次更新写入下一个地址，写完后更新索引字节（0x0801BFFF）。这样，即使某次写入因断电中断，最多损失一次更新，总有2个副本可用。

更进一步，CRC32校验不仅校验App区，也校验元数据区自身。Bootloader启动时，会依次读取3个元数据副本，对每个副本计算CRC32（使用标准IEEE 802.3多项式0xEDB88320），只有CRC匹配且状态合法的副本才被采纳。实测表明，这种三副本+CRC的组合，将元数据损坏导致的升级失败率从单副本的12%降至0.03%以下。

3. Bootloader的临界区防护：UART DMA接收与Flash擦写的无缝协同

Bootloader最危险的时刻，不是升级开始，而是升级进行到一半时突然断电。此时B区Flash可能处于“半擦除、半写入”状态，元数据区可能刚写了一半。一个鲁棒的Bootloader，必须在这类极端情况下仍能恢复运行。这要求对UART接收和Flash操作这两个临界区，进行毫秒级的协同防护。

3.1 UART DMA接收的“永不丢帧”设计

F103的USART1有DMA控制器，但默认配置下，DMA接收缓冲区满后会触发TC（Transfer Complete）中断，此时若中断服务程序（ISR）处理不及时，新数据会覆盖旧数据，导致帧丢失。我们的方案是：使用双缓冲+循环DMA模式。

具体配置：

• 开启USART1的RX DMA请求；
• 分配两个1024字节的缓冲区rx_buf_a[1024]和rx_buf_b[1024]；
• 初始化DMA时，设置DMA_InitTypeDef.DMA_MemoryBaseAddr = (uint32_t)rx_buf_a;，DMA_InitTypeDef.DMA_BufferSize = 1024;，DMA_InitTypeDef.DMA_Mode = DMA_Mode_Circular;；
• 启用DMA的HT（Half Transfer）和TC中断；
• 在HT中断中，标记rx_buf_a的前512字节已满，可解析；
• 在TC中断中，标记rx_buf_a的后512字节已满，同时切换DMA内存地址到rx_buf_b；
• 主循环中，轮询两个缓冲区的“已满标记”，对有效数据调用帧解析函数。

这个设计的妙处在于：DMA永远在写，CPU永远在读，两者完全异步。即使CPU在处理一个复杂帧（如解密+校验），DMA也在后台填充另一个缓冲区，绝不会丢数据。我实测在115200bps下连续发送10MB升级包，丢帧率为0。

帧解析函数parse_frame()采用状态机，只识别标准升级帧格式：

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

其中LEN为PAYLOAD长度，CMD为命令码（0x01=开始升级，0x02=发送数据块，0x03=升级完成）。每帧解析前，先校验SOH/ETX，再校验CRC，任一失败则丢弃整帧，继续等待下一帧。这种“宁缺毋滥”的策略，比尝试修复错误帧更可靠。

3.2 Flash擦写的“断电安全”协议

F103的Flash擦除是阻塞操作，期间CPU不能访问Flash（否则触发HardFault）。这意味着，如果在擦除B区扇区时断电，B区将处于全0xFF状态（擦除后值），此时若Bootloader读取状态标志为UPGRADING_B，就会尝试跳转到0x0800C000，而那里全是0xFF，CPU执行0xFFFFFFFF指令必然HardFault。

解决方案是：擦除前先写入“擦除中”状态，擦除完成后立即写入“擦除完成”状态。具体流程：

1. Bootloader读取元数据，确认要升级B区；
2. 将状态标志设为ERASING_B（0x03），写入Option Bytes USER字节；
3. 调用FLASH_Unlock()解锁Flash；
4. 调用FLASH_ErasePage(0x0800C000)擦除B区首页；
5. 擦除成功后，立即将状态改为ERASED_B（0x04）；
6. 开始接收并写入新固件。

这样，断电后重启时，Bootloader首先检查状态：

• 若为ERASING_B或ERASED_B，说明B区不可用，强制回退到A区运行；
• 若为UPGRADING_B，说明正在写入，但B区可能不完整，同样回退；
• 只有RUNNING_B且B区CRC校验通过，才跳转B区。

这个协议的关键是：状态变更和Flash操作必须严格串行，且状态写入（Option Bytes）必须在Flash操作之前和之后各一次。我编写了一个flash_safe_erase(uint32_t page_addr)函数，内部封装了全部逻辑，调用者只需传入页地址，无需关心状态管理。

3.3 升级包的分块校验：为什么不能等整个包收完再校验

一个典型的F103升级包大小在40KB~60KB之间。如果等到整个包接收完毕再计算CRC32，需要64KB RAM缓冲区（远超F103的20KB RAM），显然不可行。我们的方案是：边接收边校验，每1KB数据块独立校验。

升级帧中，PAYLOAD被分割为1024字节的块，每个块附带自己的CRC16校验值。Bootloader每收到一个块，立即用crc16_ccitt()算法计算其CRC16，与帧中携带的CRC16比对。只有匹配，才将该块写入B区Flash；不匹配，则请求重发该块（发送NAK响应）。

这样做有三大好处：

1. RAM占用恒定：只需1KB缓冲区+2字节CRC，总RAM消耗<1.5KB；
2. 错误定位精准：某个块CRC失败，只需重传该块，而非整个固件；
3. Flash写入可控：每块写入前，先擦除对应页（B区按页组织），写入后立即校验该页内容，确保物理写入正确。

我实测发现，F103的Flash编程速度约为1.2KB/s（115200bps UART下），而1KB块的传输+校验+写入耗时约1.1s，完全匹配。如果追求更高速度，可将块大小提升至2KB，但需确保RAM缓冲区足够（F103C8T6的SRAM是20KB，2KB块仍绰绰有余）。

4. 从零构建的Keil工程：V3.50库、启动文件与链接脚本的硬核配置

网上很多教程只给源码，却不告诉你如何在Keil中正确配置。我见过太多人卡在“Bootloader跳转后App不运行”上，最后发现是链接脚本里的ROM区域没对齐，或者启动文件里的堆栈大小设错了。这一节，我带你从Keil新建工程开始，一步步配置，确保每个字节都精准落位。

4.1 Bootloader工程的Keil配置四要素

新建一个Keil工程，命名为Bootloader_F103，关键配置如下：

1. Device选择：
Target选项卡 → Device → STM32F103C8（或你的具体型号）→ OK。
为什么必须选具体型号？因为Keil会自动加载对应的startup文件和Flash算法，选错会导致调试器无法连接。

2. Output设置：
Output选项卡 → Select Folder for Objects → 设为.\Objects\；
Create HEX File → 勾选；
Browse Information → 勾选（方便后续调试查看符号）。

3. Listing设置：
Listing选项卡 → Assembly Code → 勾选；
Cross Reference → 勾选；
生成的.lst文件能帮你确认向量表是否在正确地址。

4. C/C++设置：
Define → 添加USE_STDPERIPH_DRIVER, STM32F10X_MD；
Include Paths → 添加.\Libraries\STM32F10x_StdPeriph_Driver\inc,.\Core\inc；
Optimization → Level 3（-O3），但勾选Optimize for Time；
注意：Bootloader代码量小，O3能显著减小体积，且无浮点运算，不会引入副作用。

4.2 启动文件startup_stm32f10x_md.s的定制化修改

标准启动文件startup_stm32f10x_md.s默认将向量表放在0x08000000。我们需要让它适配Bootloader的16KB空间。打开该文件，找到：

; Reset Handler Reset_Handler PROC EXPORT Reset_Handler [WEAK] IMPORT SystemInit IMPORT __main LDR R0, =SystemInit BLX R0 LDR R0, =__main BX R0 ENDP

在Reset_Handler之前，添加Bootloader专属的向量表重定向：

; Bootloader Vector Table (placed at 0x0801C000) AREA RESET, DATA, READONLY EXPORT __Vectors __Vectors DCD 0x20002000 ; Initial Stack Pointer (0x20002000 is top of 8KB SRAM) DCD Reset_Handler ; Reset Handler DCD NMI_Handler ; NMI Handler ... ; 其余中断向量，共60个，保持原样

关键是第一行DCD 0x20002000——F103C8T6的SRAM是20KB（0x20000000 ~ 0x20004FFF），我们把初始栈顶设在0x20002000，留出8KB给Bootloader的全局变量和DMA缓冲区。这个地址必须与Keil的Target选项卡中IRAM起始地址（0x20000000）和大小（0x00005000）匹配。

4.3 链接脚本stm32_flash.ld的毫米级地址规划

创建stm32_flash.ld文件，内容如下：

/* Flash memory layout */ MEMORY { ROM (rx) : ORIGIN = 0x0801C000, LENGTH = 0x4000 /* 16KB for Bootloader */ RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x5000 /* 20KB SRAM */ } SECTIONS { .text : { *(.vectors) /* 向量表必须在最前 */ *(.text) /* 代码段 */ *(.rodata) /* 只读数据 */ } > ROM .data : { *(.data) /* 初始化数据 */ . = ALIGN(4); _sidata = LOADADDR(.data); _sdata = .; *(.data*) _edata = .; } > RAM AT > ROM .bss : { . = ALIGN(4); _sbss = .; *(.bss) *(COMMON) _ebss = .; } > RAM .stack (NOLOAD) : { . = ALIGN(4); _sstack = .; . += 0x800; /* 2KB栈空间 */ _estack = .; } > RAM }

这个脚本的精髓在于：

• ROM区域从0x0801C000开始，长度0x4000（16KB），确保Bootloader代码不越界；
• .vectors段强制放在.text最前面，保证向量表在0x0801C000；
• .data段加载到ROM，运行时复制到RAM，符合F103的常规做法；
• 栈空间显式分配0x800（2KB），避免动态分配导致溢出。

在Keil的Target选项卡中，取消勾选Use Memory Layout from Target Dialog，勾选Use Custom Linker Script，并指向stm32_flash.ld。编译后，查看map文件，确认__Vectors地址确实是0x0801c000，且Reset_Handler紧随其后。

4.4 App工程的反向配置：如何让App“忘记”自己是App

App工程的配置，恰恰要与Bootloader“对着干”。新建App_F103工程，关键差异点：

1. Device和Library：
Device选同型号；
Define添加USE_STDPERIPH_DRIVER, STM32F10X_MD, APP_MODE；
Include Paths添加.\Libraries\STM32F10x_StdPeriph_Driver\inc,.\App\inc；

2. 启动文件：
使用标准startup_stm32f10x_md.s，不做任何修改。向量表仍在0x08000000，但Bootloader会动态重映射，App无需关心。

3. 链接脚本app_flash.ld：

MEMORY { ROM (rx) : ORIGIN = 0x08000000, LENGTH = 0xC000 /* 48KB for A区 */ RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x5000 }

注意：ROM起始地址是0x08000000，长度0xC000（48KB），与A区完全匹配。B区App则用另一个链接脚本，ORIGIN = 0x0800C000。

4. 主函数入口：
在main.c开头，添加：

#ifdef APP_MODE // 告诉Bootloader：我是App，不要覆盖我的向量表 __attribute__((section(".is_app"))) const uint32_t app_marker = 0xDEADBEEF; #endif

这个app_marker放在一个独立段.is_app中，Bootloader启动时会扫描整个Flash，寻找0xDEADBEEF，一旦找到，就确认该区有有效App，避免误判空白区为有效固件。

5. 实战排错：那些让你熬夜到凌晨三点的“幽灵Bug”与终极解法

即使严格按照上述步骤配置，你仍可能遇到几个经典“幽灵Bug”。它们不报错，不崩溃，却让OTA功能时好时坏，排查起来如同大海捞针。以下是我在23个F103项目中踩过的坑，以及最直接的解决方法。

5.1 Bug现象：Bootloader能进，但跳转后App的LED不闪烁，串口无输出

表象：用J-Link下载Bootloader，复位后LED亮（Bootloader运行），按下升级键进入升级模式，发送固件后显示“升级成功”，复位，LED灭，串口无任何输出。

根因定位：
第一步，用J-Link Commander连接，执行mem32 0x08000000 10，查看A区前10个字（40字节）：

0x08000000: 20002000 08000141 08000149 ...

如果第一个字是0x20002000（MSP），第二个字是0x08000141（Reset_Handler地址），说明App固件已正确写入。
第二步，执行loadbin app.bin 0x08000000，强制用J-Link烧写App，复位——如果此时LED亮了，说明问题出在Bootloader跳转逻辑，而非App本身。

终极解法：
检查Bootloader中的跳转代码，重点看__set_MSP()和Jump_To_Application()的调用顺序。常见错误是：

// 错误写法：先跳转，再设MSP（此时MSP还是Bootloader的） Jump_To_Application(); __set_MSP(*((uint32_t*)app_addr));

正确顺序必须是：

// 正确写法：先设MSP，再跳转 __set_MSP(*((uint32_t*)app_addr)); __disable_irq(); SCB->VTOR = app_addr; // 动态重映射向量表 __DSB(); Jump_To_Application();

此外，确认App的SystemInit()中没有调用RCC_DeInit()——这会关闭所有时钟，导致LED GPIO无时钟，自然不亮。应在SystemInit()后立即调用RCC_Configuration()重新使能GPIO时钟。

5.2 Bug现象：升级过程中，串口接收偶尔丢帧，导致升级包校验失败

表象：同一份固件，有时升级成功，有时在第32768字节处