STM32 IAP Bootloader实战：UART+XMODEM零基础跑通固件升级

1. 为什么这个“超简单” bootloader 讲解，真能让你当天就跑通 IAP？

你是不是也经历过这样的场景：在 STM32 项目里，客户突然提需求——“固件得支持远程升级，别每次都要拆壳接 ST-Link”；或者自己做的智能鱼缸控制器，刚部署到水族箱里，发现温度采集逻辑有个小 bug，总不能扛着笔记本去现场重烧一遍吧？这时候，IAP（In-Application Programming）就成了刚需。但一搜“bootloader 开发”，满屏是启动流程图、向量表偏移、Flash 分区规划、中断向量重映射……还没动手，人已经麻了。更别说串口烧写失败、XMODEM 校验错、CH340 驱动不识别、XCOM 助手收不到响应这些实打实的拦路虎。

其实，IAP 的核心逻辑非常朴素：让主程序自己当“烧录器”，把新固件从串口（或其他接口）读进来，擦掉 Flash 里旧代码的某一段，再把新代码写进去，最后跳转执行。它不是玄学，而是一套可拆解、可验证、可分步调试的确定性操作。所谓“超简单”，不是跳过原理，而是把复杂度压到最低可行路径上——用最基础的 STM32F103C8（俗称“蓝 pill”），只依赖标准库和串口 UART，不碰 USB、不搞 OTA 云平台、不加加密签名，纯手工实现一个能通过 XMODEM 协议接收固件、校验、擦写、跳转的最小闭环。我试过，从零开始，硬件接线+代码编写+串口调试，全程不超过 3 小时。关键在于：绕开所有“看起来高级但实际增加失败概率”的环节，直击 IAP 最本质的三个动作：通信、擦写、跳转。这篇文章就是为你写的——如果你会用 Keil5 写 GPIO 点灯、会用串口调试助手发字符串、知道 STM32 的 Flash 起始地址是 0x08000000，那你就能跟着做出来。后面我会拆解每一个坑怎么填，比如为什么串口波特率必须设成 115200 而不是 9600，为什么 XMODEM 的 128 字节包长不能改，为什么跳转前必须关总中断、清空指令缓存、重置 MSP 堆栈指针。这些不是教科书里的理论，而是我在车载以太网模块、数字温湿度计、四开关 Buck-Boost 电源项目里，反复踩过、验证过、写进 SOP 的实操铁律。

2. 整体设计思路：为什么放弃“完美方案”，选择这条最笨但最稳的路？

2.1 拒绝“一步到位”，先做最小可运行闭环

很多教程一上来就画 Flash 分区图：Bootloader 区 16KB，App 区 64KB，参数区 4KB……听起来很专业，但实际落地时，光是计算每个区的起始地址和大小，就容易算错。更麻烦的是，一旦分区出错，轻则 App 启动失败黑屏，重则整个芯片锁死，得用 ST-Link 强制解锁。我的做法是：先不做任何分区，让 Bootloader 和 App 共享同一块 Flash，但用绝对地址硬编码区分。具体来说，Bootloader 固定放在 0x08000000 开始的 8KB（0x0000–0x1FFF），App 固定放在 0x08002000 开始的剩余空间（0x2000–0x1FFFF）。这样做的好处是：编译时不用改分散加载文件（scatter file），Keil 里直接设置 ROM 地址就行；调试时，只要 Bootloader 能跳到 0x08002000，哪怕 App 是个空循环，也能证明跳转成功。等这个闭环跑通了，再加分区、加 CRC 校验、加双备份，才是水到渠成的事。我见过太多人卡在“分区没配对”这一步，折腾两天无果，最后发现根本不是代码问题，而是 scatter 文件里一个地址多写了两个零。

2.2 串口选型：为什么只用 UART1 + CH340，坚决不用 USB CDC 或 ESP32 透传？

网络热词里一堆“USB 转串口”、“友善串口助手”、“Ubuntu CH340 驱动”，说明串口是 IAP 最接地气的通道。但 UART 有好几路，为什么锁定 UART1？因为 STM32F103C8 的 UART1 默认挂在 APB2 总线上，时钟源是 HCLK（72MHz），波特率精度最高，抗干扰能力最强。UART2/3 在 APB1 上（36MHz），同样波特率下误差更大，尤其在 115200 这种高速率下，XMODEM 的 128 字节包很容易因时序抖动导致校验失败。至于 CH340，不是因为它便宜，而是它的驱动在 Windows/macOS/Linux 上兼容性最好，几乎不用手动装驱动（Win10/11 自带，macOS Catalina+ 内置，Ubuntu 20.04+ 自带），避免了“串口调试助手连不上设备”这种开局即死的问题。反观 USB CDC，虽然速率高，但需要额外写 USB 协议栈，还要处理 Windows 的 INF 驱动签名问题；ESP32 透传看似方便，但增加了无线链路不稳定、AT 指令解析错误、TCP 重传超时等新变量。IAP 的第一目标是“可靠”，不是“炫技”。所以，硬件连接就三根线：CH340 的 TXD 接 STM32 的 PA9（UART1_TX），RXD 接 PA10（UART1_RX），GND 共地。连个 10k 上拉电阻都不用，干净利落。

2.3 协议选择：XMODEM 是“过时”还是“恰到好处”？

看到“XMODEM”这个词，很多人第一反应是“这玩意儿不是 80 年代的老古董吗？现在都用 YMODEM、ZMODEM 了！”但恰恰是它的“古老”，成了 IAP 的优势。XMODEM 最简版本只有两种包：SOH（Start of Header）开头的 128 字节数据包，和 ACK/NACK 控制包。协议状态机极其简单：发一个包 → 等 ACK → 收到 ACK 继续发下一个 → 收到 NACK 重发当前包 → 连续 10 次 NACK 则终止。没有滑动窗口、没有流量控制、没有压缩算法，代码量不到 200 行就能实现。更重要的是，所有串口调试助手（XCOM、友善、SSCOM）都原生支持 XMODEM 发送，不用额外装插件或写脚本。相比之下，YMODEM 虽然支持 1024 字节大包和文件名传输，但状态机复杂，一个字节解析错就全盘崩溃；ZMODEM 更是连 CRC 校验方式都有好几种变体，调试起来像解谜。我做过对比测试：在 115200 波特率下，XMODEM 传输 64KB 固件，成功率 99.8%（失败基本是线材接触不良）；YMODEM 同样条件下，失败率约 15%，原因多是助手软件对“扩展头”的解析不一致。所以，“过时”在这里等于“确定性高”、“兼容性广”、“调试成本低”。

2.4 启动流程精简：砍掉所有非必要环节，只留“跳转”这一件事

Bootloader 启动流程常被讲得很玄乎：上电复位 → 执行 SystemInit → 初始化时钟 → 配置中断向量表 → 检查按键/引脚状态 → 加载 App 向量表 → 设置 MSP → 跳转。但其中，SystemInit 和时钟初始化，App 里也会做，重复执行反而可能冲突；中断向量表重映射，如果 App 不用外部中断，完全可以省略；按键检测，初期调试时用串口命令触发更可控。我的 Bootloader 启动代码只有 4 步：

1. 关总中断（__disable_irq()），防止跳转过程中被意外中断打断；
2. 清空指令缓存（SCB_InvalidateICache()），确保 CPU 从新地址取最新指令；
3. 设置主堆栈指针 MSP 为 App 的初始 SP 值（从 App 的第一个字读取，即 0x08002000 处的值）；
4. 从 App 的第二个字读取复位向量地址（0x08002004），强制跳转（((void (*)(void))(*(__IO uint32_t*)0x08002004))();）。 这四行代码，我贴在 Keil 工程里，编译后 hex 文件大小仅 1.2KB，烧录到 0x08000000，接上串口，按复位键，LED 灯立刻按 App 逻辑闪烁——这就是 IAP 成功的第一声号角。所有其他功能，都是在这个“能跳转”的基础上，一层层叠加上去的。

3. 核心细节解析与实操要点：从寄存器配置到 XMODEM 字节流，一个都不能错

3.1 UART1 初始化：为什么波特率必须是 115200，且 DIV 值要手算？

UART1 的波特率生成公式是：DIV = (DIV_Mantissa << 4) | DIV_Fraction，其中DIV_Mantissa = (USARTDIV) / 16，DIV_Fraction = ((USARTDIV) - Mantissa) * 16，而USARTDIV = PCLK / (16 * BaudRate)。STM32F103C8 的 PCLK2（APB2）是 72MHz，如果设波特率为 115200，则USARTDIV = 72000000 / (16 * 115200) = 39.0625。于是Mantissa = 39，Fraction = 0.0625 * 16 = 1，最终DIV = (39 << 4) | 1 = 0x271。这个值必须精确，否则 XMODEM 的 128 字节包在高速传输时，第 100 个字节左右就会开始出现乱码。我试过用 Keil 的 USART 初始化向导自动生成，结果它用了近似值 0x270，导致传输 32KB 固件时，在 28KB 处卡死，反复 NACK。解决方法是：在USART_InitTypeDef结构体里，手动赋值USART_InitStruct->USART_BRR = 0x271，而不是依赖USART_Init()函数的自动计算。另外，必须开启USART_IT_RXNE（接收中断）和USART_IT_TC（发送完成中断），但关闭USART_IT_IDLE（空闲中断），因为 XMODEM 协议不依赖空闲帧判断包结束，用固定长度 128 字节更可靠。接收缓冲区大小设为 128，发送缓冲区设为 1，因为 XMODEM 是半双工，发完一个 ACK 就等接收，不需要大缓冲。

3.2 Flash 擦除与写入：为什么必须按“扇区”擦除，且写入前要校验？

STM32F103 的 Flash 是按扇区（Sector）擦除的，最小擦除单位是 1KB（Sectors 0–3）或 2KB（Sectors 4–7）。App 区（0x08002000–0x0801FFFF）跨越 Sector 3（0x08002000–0x08002FFF，1KB）和 Sector 4（0x08003000–0x08004FFF，2KB）等多个扇区。如果只擦 Sector 3，而 App 固件大于 1KB，写入时就会遇到“写保护”错误。因此，擦除逻辑必须是：计算固件大小，向上取整到最近的扇区边界，然后擦除所有覆盖的扇区。例如，固件大小为 0x3A50（14928 字节），起始地址 0x08002000，那么它覆盖的扇区是 Sector 3（0x08002000–0x08002FFF）、Sector 4（0x08003000–0x08004FFF）、Sector 5（0x08005000–0x08006FFF），共 3 个扇区，必须全部擦除。擦除前，必须调用FLASH_Unlock()解锁，擦除后调用FLASH_Lock()上锁，这是硬件安全机制。写入时，每次只能写 16 位（2 字节），且目标地址必须是偶数地址（对齐）。更关键的是，写入后必须立即读回校验。我吃过亏：一次写入 0x08002000，没校验，结果发现 Flash 编程电压不稳，写进去的值是 0xFFFF，但程序没报错，直到跳转后 App 崩溃才暴露。现在我的写入函数是原子操作：FLASH_ProgramHalfWord(addr, data); if (HAL_FLASH_ReadHalfWord(addr) != data) { return ERROR; }，确保每 2 字节都 100% 正确。

3.3 XMODEM 协议实现：SOH 包的 132 字节结构，如何逐字节解析？

一个标准 XMODEM SOH 包共 132 字节，结构如下：

• 字节 0：0x01（SOH 标志）
• 字节 1：包序号（1–128，循环）
• 字节 2：包序号取反（用于校验）
• 字节 3–130：128 字节有效数据
• 字节 131：校验和（1 字节，所有数据字节之和的低 8 位）

接收端的解析逻辑必须严格按此顺序：

1. 等待 SOH（0x01），超时 3 秒则返回错误；
2. 读取包序号seq和取反~seq，检查是否匹配，不匹配则发 NACK；
3. 循环读取 128 字节到缓冲区；
4. 读取校验和chk，并计算缓冲区 128 字节之和sum；
5. 如果sum & 0xFF == chk，则发 ACK，进入下一包；否则发 NACK，等待重发。

这里有两个致命细节：第一，包序号从 1 开始，不是 0，很多新手误以为从 0 开始，导致第二包就校验失败；第二，校验和是 128 字节数据之和，不包括 SOH、seq、~seq 这 3 个字节，但很多资料没写清楚，导致计算范围错。我用逻辑分析仪抓过真实 XCOM 发送的波形，确认了这一点。另外，发送 ACK 时，必须用USART_SendData(USART1, 0x06)，而不是printf("ACK")，因为printf会加\r\n，破坏协议。同样，NACK 是0x15，不是字符串 "NACK"。

3.4 跳转前的“临门一脚”：为什么 MSP 必须重置，且必须关中断？

跳转到 App 前，设置 MSP 是最关键的一步。App 的初始 SP 值，存储在 Flash 的第一个字（0x08002000），这是 Cortex-M3 的规定：复位向量表的首地址存放初始 MSP。如果直接跳转而不设置 MSP，CPU 会继续用 Bootloader 的栈，而 Bootloader 的栈空间（通常在 SRAM 里）可能已被覆盖或释放，导致 App 一执行函数就栈溢出，死机。所以，代码必须是：

uint32_t app_sp = *(uint32_t*)0x08002000; // 读取 App 的初始 SP __set_MSP(app_sp); // 强制设置主堆栈指针 uint32_t app_pc = *(uint32_t*)0x08002004; // 读取复位向量地址 ((void (*)(void))app_pc)(); // 强制跳转

此外，__disable_irq()必须在设置 MSP 之前执行。因为如果跳转瞬间来了个 SysTick 中断，中断服务程序（ISR）会尝试压栈，但此时 MSP 还是 Bootloader 的，而 ISR 代码却在 App 区，地址空间错乱，必然 HardFault。我用 ST-Link 抓过 HardFault 的 fault status register，确认是IBUSERR（指令总线错误），根源就是没关中断。还有一个隐藏陷阱：跳转后，Bootloader 的全局变量（如 UART 接收缓冲区）还在内存里，但 App 可能用同一片 RAM，所以跳转前，最好把所有 Bootloader 的全局变量清零，避免 App 读到脏数据。

4. 实操过程与核心环节实现：从 Keil 工程搭建到 XCOM 烧写，手把手走一遍

4.1 Keil5 工程搭建：两套独立工程，一套 Bootloader，一套 App

第一步，新建两个 Keil5 工程，分别叫Bootloader_Project和App_Project。不要试图在一个工程里用条件编译切换，那样链接时容易混乱。Bootloader_Project的设置：

• Target 页：Xtal = 8MHz（外部晶振），Use MicroLIB（减小代码体积），IRAM1 起始地址 0x20000000，大小 0x5000（20KB）；
• Output 页：勾选 Create HEX File，Select Folder for Objects 设为Objects_Boot；
• User 页：在 After Build/Rebuild 里添加命令：fromelf --i32combined --output ./Objects_Boot/bootloader.hex ./Objects_Boot/bootloader.axf，生成标准 hex 文件；
• C/C++ 页：Define 里添加BOOTLOADER宏，用于代码中条件编译；
• Linker 页：最关键！取消 Use Memory Layout from Target Dialog，勾选 Use Settings from Scatter File，然后点击 Manage Project Items，新建一个bootloader.sct文件，内容为：

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

这个 scatter 文件强制 Bootloader 占用 0x08000000–0x08001FFF（8KB），为 App 留出空间。

App_Project的设置类似，但 scatter 文件改为：

LR_IROM1 0x08002000 0x0001E000 { ; App 从 0x08002000 开始，最大 120KB ER_IROM1 0x08002000 0x0001E000 { *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } RW_IRAM1 0x20000000 UNINIT 0x00005000 { .ANY (+RW +ZI) } }

编译后，App_Project生成app.hex，大小必须小于 120KB，否则会溢出。

4.2 Bootloader 主程序框架：状态机驱动，三分钟写完核心逻辑

Bootloader 的主循环是一个简单的状态机：

typedef enum { WAIT_CMD, XMODEM_RECEIVE, FLASH_WRITE, JUMP_TO_APP } BootState; BootState state = WAIT_CMD; uint8_t rx_buffer[128]; uint32_t flash_addr = 0x08002000; uint32_t bytes_received = 0; while(1) { switch(state) { case WAIT_CMD: if (uart_rx_ready()) { char cmd = uart_get_char(); if (cmd == 'U') { // 输入 U 进入升级模式 state = XMODEM_RECEIVE; bytes_received = 0; flash_addr = 0x08002000; uart_send_str("XMODEM Ready\r\n"); } else if (cmd == 'G') { // 输入 G 直接跳转 jump_to_app(); } } break; case XMODEM_RECEIVE: if (xmodem_receive_packet(rx_buffer, &flash_addr) == SUCCESS) { bytes_received += 128; if (bytes_received >= APP_MAX_SIZE) { state = FLASH_WRITE; } } else { uart_send_char(0x15); // NACK } break; case FLASH_WRITE: if (flash_write_buffer(rx_buffer, flash_addr - 128, 128) == SUCCESS) { state = JUMP_TO_APP; uart_send_str("Upgrade OK\r\n"); } break; case JUMP_TO_APP: jump_to_app(); break; } }

这个框架里，xmodem_receive_packet()是核心函数，它内部实现了前述的 SOH 包解析逻辑；flash_write_buffer()负责按扇区擦除、分 2 字节写入、逐字校验。整个逻辑不到 100 行，清晰易懂。调试时，可以在WAIT_CMD状态下用串口助手发U，看到XMODEM Ready回复，就证明 Bootloader 已就绪。

4.3 XCOM 串口助手配置：三步设置，避免 90% 的烧写失败

XCOM（或任何支持 XMODEM 的助手）的配置是成败关键。很多人烧写失败，不是代码问题，而是助手没配对。正确步骤：

1. 串口设置：选择正确的 COM 口（设备管理器里看 CH340 对应的号），波特率 115200，数据位 8，停止位 1，无校验，无流控。务必确认“RTS/CTS”和“DTR/DSR”两个流控选项都是Uncheck状态，否则 XMODEM 握手会失败。
2. XMODEM 设置：点击“发送文件”按钮，在弹窗里选择app.hex文件，Protocol 下拉框必须选 XMODEM-CRC（不是 XMODEM-Checksum，CRC 更可靠）；Transfer Mode 选 “Binary”；Timeout 设为 3000ms（3秒）；Retry Count 设为 10。
3. 触发时机：在 XCOM 点击“发送”后，立刻在 STM32 上按复位键（或断电重启），让 Bootloader 进入WAIT_CMD状态，并在 1 秒内输入U。如果 Bootloader 没收到U，它会一直等，XCOM 就超时失败。我习惯在 XCOM 点发送前，先把 STM32 断电，点发送，再立刻上电，这样时间最精准。

4.4 实操现场记录：一次完整的升级过程与耗时统计

我用一块真实的 STM32F103C8T6 开发板（蓝 pill），CH340 模块，XCOM v3.5，完整走了一遍：

• 硬件连接：CH340 的 TXD → PA9，RXD → PA10，GND → GND，VCC 不接（开发板自己供电）；
• 软件准备：Keil 编译bootloader.hex（1.2KB），烧录到 0x08000000（用 ST-Link 或串口 ISP 工具）；编译app.hex（一个 LED 闪烁程序，3.8KB）；
• 升级过程：
  1. 上电，串口助手发U，收到XMODEM Ready；
  2. XCOM 点发送app.hex，3 秒内按复位键；
  3. XCOM 显示进度条，从 0% 到 100%，耗时 4.2 秒（115200 波特率下，理论最大传输速率约 11.5KB/s，3.8KB 应该 3.3 秒，多出的 0.9 秒是重传和握手开销）；
  4. 完成后，XCOM 显示Transfer completed，开发板串口输出Upgrade OK；
  5. 按复位键，LED 开始以 App 设定的频率闪烁，证明跳转成功。 整个过程，从接线到验证，耗时 18 分钟。其中，7 分钟在 Keil 里配置 scatter 文件和编译选项，5 分钟在 XCOM 里试错配置（第一次忘了关流控，超时失败），剩下全是执行。这个速度，足够应付产线快速迭代和现场紧急修复。

5. 常见问题与排查技巧实录：那些官方文档不会告诉你的“血泪教训”

5.1 串口烧写失败：90% 的问题出在这三个地方

问题现象	根本原因	排查技巧	解决方案
XCOM 显示 “Waiting for XMODEM…” 一直不动	Bootloader 没进入 XMODEM 状态	用示波器测 PA9，看是否有数据波形；或用串口助手发U，看是否有XMODEM Ready回复	检查 Bootloader 是否已烧录；确认复位后是否执行到WAIT_CMD；用逻辑分析仪抓 UART1 波形，确认 Bootloader 是否在发字符
XCOM 显示 “NACK received, retrying…” 循环 10 次后失败	XMODEM 包校验失败	抓取 XCOM 发送的原始字节流，对比 SOH 包结构；用万用表测 CH340 的 TXD/RXD 电压，确认电平是 3.3V 而非 5V	检查USART_BRR是否为 0x271；确认 CH340 模块是否为 3.3V 电平（有些山寨模块是 5V，需加电平转换）；更换 USB 线，排除接触不良
烧写完成后，按复位键，LED 不亮或乱闪	Flash 写入失败或跳转地址错误	用 ST-Link Utility 读取 0x08002000–0x08002010，看前 8 字节是否为 App 的 SP 和 PC 值；用 Keil 的 Memory Browser 查看 RAM 里 Bootloader 的全局变量是否被覆盖	在flash_write_buffer()里加校验打印；确认jump_to_app()函数里__set_MSP()和__disable_irq()的顺序；检查 App 的 scatter 文件，确保RESET段在 0x08002000

提示：如果怀疑 Flash 写入问题，最暴力的验证法是：用 ST-Link 读出app.hex的前 16 字节（即 SP 和 PC），再读出 Flash 0x08002000–0x0800200F，逐字节比对。不一致，说明写入环节出错。

5.2 串口调试助手收不到响应：驱动、权限、线材的三重陷阱

“串口调试助手连不上设备”是高频问题，根源往往不在代码：

• Windows 驱动：CH340 在 Win10/11 上通常免驱，但如果系统更新过，可能驱动被禁用。打开“设备管理器”→“端口（COM 和 LPT）”，看是否有黄色感叹号。右键“更新驱动程序”→“浏览我的计算机”→“让我从列表中选”→勾选“显示兼容硬件”，厂商选“Microsoft”，设备选“USB Serial Port”，强制安装。
• macOS 权限：macOS Catalina+ 默认禁止未签名驱动。打开“系统偏好设置”→“安全性与隐私”→“通用”，在底部点“仍要允许”，选择 CH340 驱动。或者终端执行sudo spctl --master-disable（临时关闭 Gatekeeper）。
• Ubuntu 权限：Ubuntu 用户默认无串口访问权。执行sudo usermod -a -G dialout $USER，然后重启终端或注销重登。验证：ls -l /dev/ttyUSB*，看组权限是否为dialout。
• 线材陷阱：很多廉价 USB 转串口线，只连了 TXD/RXD/GND，没连 DTR/RTS。XMODEM 不需要它们，但有些助手软件（如旧版 XCOM）会尝试控制 DTR，导致握手失败。换一根确认有四芯（TXD/RXD/GND/VCC）的线，或直接拔掉 VCC（防倒灌）。

5.3 Bootloader 启动后黑屏：不是代码错了，是“启动模式”没切对

STM32 的启动模式由 BOOT0 和 BOOT1 引脚决定。F103 默认是“主闪存存储器”（BOOT0=0, BOOT1=x），但如果你用 ST-Link 烧录 Bootloader 时，不小心把 BOOT0 拉高了，芯片就会从系统存储器（System Memory）启动，运行内置的 bootloader，而不是你写的。现象是：上电后，串口没任何输出，LED 也不亮。解决方法：

• 查开发板原理图，确认 BOOT0 引脚（通常是 PB8 或者一个跳线帽）；
• 确保 BOOT0 接地（0），BOOT1 悬空或接 VDD（x）；
• 如果开发板有 BOOT0 跳线，把它从“1”拨到“0”；
• 用万用表测 BOOT0 引脚对地电压，必须是 0V。

注意：有些国产开发板（如“STM32 鱼缸”专用板）为了简化，把 BOOT0 硬接地，无法更改，这种板子最省心。

5.4 IAP 升级后 App 崩溃：HardFault 的终极排查法

App 跳转后立即 HardFault，是最难 debug 的问题。官方文档只会说“检查 MSP 和 PC”，但实际原因千奇百怪：

• SysTick 未重置：Bootloader 里开了 SysTick，App 里又初始化一次，导致定时器冲突。解决方案：跳转前执行SysTick->CTRL = 0; SysTick->LOAD = 0; SysTick->VAL = 0;彻底关闭。
• NVIC 中断向量未重映射：如果 App 用了外部中断（如 EXTI0），而 Bootloader 没重映射向量表，中断会跳到 Bootloader 的 ISR 地址，执行非法指令。解决方案：在 App 的main()开头，加SCB->VTOR = FLASH_BASE | 0x2000;（假设 App 向量表在 0x08002000）。
• SRAM 冲突：Bootloader 和 App 的.data段都链接到 0x20000000，App 启动时会把 Flash 里的初始化数据拷贝到 SRAM，覆盖 Bootloader 的变量。解决方案：在 App 的 scatter 文件里，把RW_IRAM1的起始地址设为0x20005000，避开 Bootloader 的 RAM 区域。

我自己总结的 HardFault 排查三步法：

1. 用 ST-Link 连接，在 Keil 里全速运行，停在 HardFault_Handler；
2. 查看SCB->CFSR寄存器，低 16 位是 Usage Fault，高 16 位是 Bus Fault/ MemManage；
3. 根据 CFSR 值查手册，定位是IBUSERR（指令总线）、PRECISERR（精确数据总线错误）还是UNALIGNED（未对齐访问），再针对性检查 MSP、PC、内存映射。

6. 后续可扩展方向：从“能用”到“好用”，一条清晰的升级路径

当你已经能用 XMODEM 稳定升级固件，下一步就可以考虑增强可靠性与用户体验，但切记：每次只加一个功能，验证后再加下一个。我推荐的升级路径是：

• 第一阶段：加 CRC32 校验。在 XMODEM 传输完成后，用crc32(app_start_addr, app_size)计算整个 App 区的 CRC，与app.hex里预计算的 CRC 比对。这能 100% 防止 Flash 写入错误导致的静默失败。代码不到 20 行，网上有现成的 CRC32 表驱动实现。
• 第二阶段：加双备份机制。把