STM32 BootLoader串口UART升级：量产固件迭代的保底方案

简介：这份STM32 BootLoader固件串口UART升级工程源码，面向嵌入式开发工程师与STM32学习者，用于解决设备运行程序的自动升级与更新问题。工程基于STM32单片机，通过串口接收上位机下发的bootloader固件，在芯片内完成UART数据接收与命令解析，再将固件写入FLASH，随后复位系统并重设新APP向量地址，实现固件更新。内容涵盖HAL库使用、UART初始化与收发解析、FLASH读写、CRC校验以及Bootloader固件加载与更新等关键环节，适合具备一定嵌入式基础、希望掌握IAP升级流程的开发者参考。资源包共109个文件，以72个h头文件与30个c源文件为主体，另含makefile、ld链接脚本、ioc配置、s汇编及jflash烧录配置等，压缩包约833KB，工程结构完整。目前已有1952人学习下载，可帮助读者理解串口升级的完整链路与校验、跳转等排错思路。

1. STM32 BootLoader 串口 UART 升级：为什么它是量产固件迭代的保底方案

做嵌入式量产维护的同行大概都经历过这种场面：设备已经装到现场机柜里，突然发现应用固件有个逻辑漏洞，返厂拆机烧录的成本高得离谱。这时候如果板子上跑着一个能通过串口 UART 接收新固件并写入 Flash 的 BootLoader，一根 USB 转 TTL 线就能把问题解决掉。STM32 BootLoader 固件串口 UART 升级工程源码，说的就是这套东西——芯片上电后先跑一段不参与业务的小程序，它判断是否需要升级，需要就从串口收数据、擦写 Flash、跳转到应用区。

这套方案适合三类人：一是做工业控制、仪器仪表这类设备分散、拆机困难的团队；二是产品还在小批量试产、需要频繁改固件验证的开发者；三是想搞懂 STM32 启动流程和 Flash 分区，但不想一上来就啃复杂协议栈的学习者。它不依赖网络、不依赖操作系统，只要一根串口线，可靠性在电磁环境复杂的现场反而比无线方案更稳。下面从分区设计讲到协议实现，再到实际调试中那些让人抓狂的坑，一步步把可复现的工程搭出来。

2. 先把 Flash 分区和跳转逻辑定死：BootLoader 的地基

2.1 为什么分区表必须在写第一行代码前确定

很多新手拿到源码直接编译烧录，跑不通就改跳转地址，改来改去把自己绕晕。根子在于没有先定分区。STM32 的 Flash 是按页（Page）或扇区（Sector）擦除的，不同型号粒度不同：F1 系列通常是 1KB 或 2KB 一页，F4 系列是 16KB 到 128KB 一个扇区。BootLoader 自己占用的区域必须和应用程序区严格分开，否则升级时擦除操作会把正在运行的 BootLoader 代码也抹掉，直接变砖。

我一般按这个原则划：BootLoader 占最前面一段，大小取 Flash 擦除粒度的整数倍，并且留出至少 20% 余量给后续加功能。应用程序区从 BootLoader 结束地址开始，末尾再留一小块存升级标志和固件校验信息。以某款 128KB Flash、2KB 页大小的 STM32 为例，分区可以这样定：

这个表要写进链接脚本和 BootLoader 代码里，两边地址必须一致。应用程序的链接脚本里 ROM 起始地址要改成 0x08004800，否则编译出来的中断向量表偏移不对，跳转过去直接 HardFault。

2.2 跳转到应用程序的三个必要条件

跳转不是一句函数指针调用就完事。Cortex-M 内核在跳转前要求：第一，关闭所有已使能的中断，尤其是 SysTick 和串口中断，否则应用区还没初始化中断向量，一个挂起的中断就会打到 BootLoader 的向量表上；第二，设置主栈指针 MSP 为应用区向量表的第一个字；第三，设置向量表偏移寄存器 SCB->VTOR 为应用区起始地址。这三步缺一个都可能出现“跳过去跑几秒就死”的玄学现象。

/* 跳转到应用程序区，app_addr 为应用区起始地址 */ typedef void (*pFunction)(void); void jump_to_app(uint32_t app_addr) { uint32_t jump_addr; pFunction app_entry; /* 检查应用区栈顶是否合法：必须在 SRAM 范围内 */ if (((*(uint32_t *)app_addr) & 0x2FFE0000) != 0x20000000) { return; /* 栈顶不合法，说明应用区没有有效固件 */ } /* 关闭全局中断，防止跳转过程中被中断打断 */ __disable_irq(); /* 关闭 SysTick，否则它的中断会持续触发 */ SysTick->CTRL = 0; SysTick->LOAD = 0; SysTick->VAL = 0; /* 清除所有挂起的中断标志 */ for (int i = 0; i < 8; i++) { NVIC->ICER[i] = 0xFFFFFFFF; NVIC->ICPR[i] = 0xFFFFFFFF; } /* 设置主栈指针为应用区向量表首字 */ __set_MSP(*(uint32_t *)app_addr); /* 取应用区复位向量地址（向量表第二字） */ jump_addr = *(uint32_t *)(app_addr + 4); app_entry = (pFunction)jump_addr; /* 设置向量表偏移，让应用区中断能正确响应 */ SCB->VTOR = app_addr; /* 开全局中断并跳转 */ __enable_irq(); app_entry(); }

这段代码里app_addr就是 0x08004800。栈顶检查那一步很关键，如果应用区是空的（全 0xFF），栈顶值就是 0xFFFFFFFF，直接跳过去必死。加上这个判断，BootLoader 在没收到固件时就能安心停在等待状态。SCB->VTOR的设置容易被忽略，不设的话应用区里所有中断都会跑到 BootLoader 的向量表去，现象就是串口收发正常但定时器中断进不去。

2.3 升级标志的存放与掉电保护

升级标志不能只放 RAM 里，因为设备可能升级到一半断电，重启后 BootLoader 必须知道上次升级没完成，需要重新进入升级模式。常见做法是在 Flash 里划一页专门存标志，写入前先擦除，写入后校验。但 Flash 擦写次数有限（一般 1 万次左右），如果每次上电都写标志，寿命很快耗尽。我的做法是：只在收到升级命令时写一次标志，升级成功后擦除标志；上电时读标志，只有标志为特定值才进升级模式，否则直接跳应用区。

标志区还要考虑写入原子性。如果写到一半断电，标志可能处于半写状态。解决办法是存两个互补的值，比如地址 A 存 0x5A5A5A5A，地址 B 存 0xA5A5A5A5，只有两个都匹配才认为标志有效。这样即使写入过程中断电，两个值不会同时正确，BootLoader 就当作无升级请求处理，保证设备还能正常启动。

3. 串口 UART 升级协议怎么设计才不丢包

3.1 帧格式与握手流程

串口升级最怕的是数据丢包导致固件写坏。没有校验的裸传数据，在长线缆或电机干扰环境下几乎必然出错。我一般用一套简单的帧协议：帧头（2 字节）+ 命令（1 字节）+ 长度（2 字节）+ 数据（N 字节）+ CRC16（2 字节）。帧头用 0xAA 0x55，命令区分握手、擦除、写数据、校验、跳转等操作。接收端用状态机逐字节解析，遇到帧头才开始收，长度字段限制单帧最大 1024 字节，防止缓冲区溢出。

握手流程是这样的：上位机先发握手命令，BootLoader 回复芯片型号和 Flash 容量；上位机确认后发擦除命令，BootLoader 擦除应用区并回复就绪；然后上位机分包发送固件数据，每包 BootLoader 写入后回复 ACK；全部发完后上位机发校验命令，BootLoader 计算整包 CRC 并比对；校验通过则写升级成功标志并跳转，失败则回复错误码等待重传。

/* 帧解析状态机，逐字节喂入 */ typedef enum { STATE_HEAD1, STATE_HEAD2, STATE_CMD, STATE_LEN_H, STATE_LEN_L, STATE_DATA, STATE_CRC_H, STATE_CRC_L } parse_state_t; static parse_state_t state = STATE_HEAD1; static uint8_t rx_buf[1024]; static uint16_t rx_len = 0; static uint16_t rx_index = 0; static uint8_t rx_cmd = 0; void uart_byte_input(uint8_t byte) { switch (state) { case STATE_HEAD1: if (byte == 0xAA) state = STATE_HEAD2; break; case STATE_HEAD2: state = (byte == 0x55) ? STATE_CMD : STATE_HEAD1; break; case STATE_CMD: rx_cmd = byte; state = STATE_LEN_H; break; case STATE_LEN_H: rx_len = (uint16_t)byte << 8; state = STATE_LEN_L; break; case STATE_LEN_L: rx_len |= byte; if (rx_len > sizeof(rx_buf)) { /* 长度超限，丢弃重来 */ state = STATE_HEAD1; } else { rx_index = 0; state = (rx_len > 0) ? STATE_DATA : STATE_CRC_H; } break; case STATE_DATA: rx_buf[rx_index++] = byte; if (rx_index >= rx_len) state = STATE_CRC_H; break; case STATE_CRC_H: /* 高字节暂存，实际项目用变量保存 */ state = STATE_CRC_L; break; case STATE_CRC_L: /* 两字节 CRC 收齐后校验，校验通过则处理命令 */ protocol_handle_frame(rx_cmd, rx_buf, rx_len); state = STATE_HEAD1; break; default: state = STATE_HEAD1; break; } }

状态机的好处是不会因为某一帧错误就卡死，收到非法字节自动回到帧头等待。rx_len超过缓冲区大小时直接丢弃，避免溢出。CRC 校验放在最后，只有校验通过才交给命令处理函数，这样上层逻辑不用关心数据完整性。

3.2 分包大小与超时重传参数

分包大小直接影响升级速度和可靠性。包太小，握手和 ACK 开销占比高，升级慢；包太大，一包出错重传代价高，而且 BootLoader 的 RAM 缓冲区要够大。我实测下来，1024 字节一包在 115200 波特率下比较均衡，一包传输约 90ms，加上 ACK 和上位机处理，整体升级 100KB 固件大约 15 到 20 秒。如果波特率提到 460800，可以缩短到 5 秒左右，但前提是线缆质量好、干扰小。

超时重传参数要配合上位机设置。BootLoader 收到一包后必须在规定时间内回复 ACK，否则上位机认为丢包并重传。这个超时我一般设 500ms，因为 Flash 写入一页 2KB 数据在 STM32 上大约 2 到 5ms，加上串口传输时间，500ms 足够宽裕。重传次数设 3 次，连续 3 次失败就终止升级并报错，避免上位机无限等待。

注意：Flash 写入前必须先擦除，且擦除操作是按页进行的。如果一包数据跨越了两个页边界，需要先擦除下一页再写，否则写入会失败。上位机分包时最好按页大小对齐，比如 2KB 页就每包 2KB，这样 BootLoader 处理逻辑最简单。

3.3 写入地址校验与防误擦

BootLoader 收到写数据命令时，必须校验目标地址是否落在应用程序区内。如果上位机因为 bug 发了一个指向 BootLoader 区的地址，而 BootLoader 不加判断直接擦写，设备当场变砖。校验逻辑很简单：地址大于等于应用区起始地址，且地址加数据长度小于等于应用区结束地址。不满足就回复错误码，拒绝写入。

/* 写数据命令处理，addr 为目标地址，data 为数据指针，len 为长度 */ uint8_t handle_write_data(uint32_t addr, uint8_t *data, uint16_t len) { /* 地址范围校验：必须在应用区内 */ if (addr < APP_START_ADDR || (addr + len) > APP_END_ADDR) { return ERR_ADDR_OUT_OF_RANGE; } /* 解锁 Flash */ HAL_FLASH_Unlock(); /* 按页擦除：如果 addr 是页起始地址，先擦除该页 */ if ((addr % FLASH_PAGE_SIZE) == 0) { FLASH_EraseInitTypeDef erase; uint32_t page_error = 0; erase.TypeErase = FLASH_TYPEERASE_PAGES; erase.PageAddress = addr; erase.NbPages = 1; if (HAL_FLASHEx_Erase(&erase, &page_error) != HAL_OK) { HAL_FLASH_Lock(); return ERR_ERASE_FAIL; } } /* 逐字写入，STM32 要求按字（32位）或半字编程 */ for (uint16_t i = 0; i < len; i += 4) { uint32_t word = *(uint32_t *)(data + i); if (HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, addr + i, word) != HAL_OK) { HAL_FLASH_Lock(); return ERR_WRITE_FAIL; } } HAL_FLASH_Lock(); return ERR_NONE; }

这段代码里APP_START_ADDR和APP_END_ADDR就是分区表里的应用程序区范围。擦除判断用addr % FLASH_PAGE_SIZE == 0，意味着上位机每包都从页边界开始发，这样每包只擦一页，逻辑清晰。写入用字编程，因为 STM32 的 Flash 编程粒度通常是 32 位，按字节写会失败。写完必须 Lock，防止误操作。

4. 避坑与排查：那些让 BootLoader 翻车的细节

4.1 跳转后应用区中断不响应

现象：BootLoader 跳转到应用区后，应用区的主循环能跑，串口能收发，但定时器中断、DMA 中断死活不进。原因通常是SCB->VTOR没有设置，或者设置的值不是应用区起始地址。Cortex-M 默认从 0x00000000 取向量表，STM32 映射到 0x08000000，也就是 BootLoader 的向量表。应用区的中断向量在 0x08004800，不告诉内核，它就一直用 BootLoader 的。解决就是在跳转前加SCB->VTOR = app_addr;，并且确保应用区链接脚本里向量表偏移也设对了。

4.2 升级到一半断电后设备无法启动

现象：升级过程中拔掉电源，重新上电后设备没有任何反应，串口也不回复。原因是升级标志已经写入，但应用区固件不完整，BootLoader 上电后进入升级模式等待数据，而上位机没有重新发起升级，设备就卡在等待状态。解决方法是给升级模式加超时：进入升级模式后启动一个定时器，比如 10 秒内没有收到任何有效帧，就清除升级标志并跳转到应用区。即使应用区固件不完整，至少设备还能跑起来，用户有机会重新升级。

4.3 串口接收丢字节导致 CRC 校验失败

现象：上位机发送固件，BootLoader 偶尔回复 CRC 错误，重传几次后成功，但升级时间明显变长。原因通常是串口接收中断优先级太低，被其他中断打断后没有及时取走数据，硬件溢出。解决方法是把串口中断优先级设到最高，或者在中断里只做数据入队，主循环里再解析。如果用的是 HAL 库的HAL_UART_Receive_IT，注意每次接收完要重新调用，否则只收一次就停了。更稳的做法是用 DMA 加空闲中断，DMA 自动搬数据，空闲中断触发时一次性处理一帧。

4.4 Flash 擦除时间过长导致看门狗复位

现象：BootLoader 在擦除应用区时，如果开了独立看门狗且没有及时喂狗，擦除大页（比如 F4 的 128KB 扇区）耗时可能超过看门狗超时，导致复位。解决方法是擦除前先关闭看门狗，或者把看门狗超时设长一些，再或者在擦除循环里插入喂狗操作。但注意，擦除过程中 CPU 会阻塞在 Flash 操作上，喂狗代码可能执行不到，所以最稳妥的还是擦除前关狗，擦除完再开。

4.5 应用程序编译出的 bin 文件包含多余数据

现象：升级完成后应用区能跑，但 Flash 里多写了很多 0xFF 或者随机数据，浪费空间。原因是 Keil 或 IAR 默认生成的 bin 文件可能包含未使用的 Flash 区域填充。解决是在 IDE 的链接选项里勾选“仅生成已使用区域”或者用fromelf工具手动裁剪。另外，bin 文件大小要跟 BootLoader 协议里的固件长度字段一致，上位机发送时按实际大小发，不要发整个 Flash 大小的数据。

5. 进阶技巧：让升级更稳、更快、更省心

5.1 双区备份与回滚

单区升级最大的风险是升级失败后设备变砖。如果 Flash 空间够，可以划两个应用区：A 区和 B 区。当前运行 A 区，升级时写 B 区，写完后把启动标志指向 B 区并复位。如果 B 区启动失败（比如看门狗复位次数超限），BootLoader 自动切回 A 区。这样即使新固件有问题，设备也能回滚到旧版本。代价是 Flash 要够大，而且 BootLoader 逻辑复杂一些，但量产设备上这点成本值得花。

5.2 用 CRC32 替代 CRC16 做整包校验

CRC16 能发现大部分传输错误，但对抗随机错误的能力有限。如果固件包很大（比如几百 KB），建议用 CRC32。STM32 的硬件 CRC 外设支持 CRC32，计算速度快，不占 CPU。上位机也计算 CRC32，两边比对。注意硬件 CRC 的初始值和多项式要跟上位机一致，否则算出来不一样。我一般用标准 CRC32 多项式 0x04C11DB7，初始值 0xFFFFFFFF，结果取反。

5.3 升级速度优化：提高波特率与减少 ACK 等待

115200 波特率下升级 100KB 大约 15 秒，如果产线批量升级，这个时间累积起来很可观。把波特率提到 460800 或 921600，升级时间能缩短到 3 到 5 秒。前提是 BootLoader 的串口时钟配置正确，上位机 USB 转串口芯片支持高波特率。另外，可以把“每包 ACK”改成“每 N 包 ACK”，减少握手开销。但这样丢包重传的粒度变大，一包出错要重传 N 包，需要权衡。我的经验是每 4 包 ACK 一次，兼顾速度和重传代价。

5.4 用脚本自动化升级流程

手动点上位机工具升级容易出错，尤其是产线上几十台设备。我一般写一个 Python 脚本，调用串口库自动完成握手、擦除、发送、校验、跳转全过程。脚本里加日志和重试，失败自动重来。这样产线工人只需要插上线、按一下回车，剩下的交给脚本。

import serial import time import struct def crc16(data): crc = 0xFFFF for b in data: crc ^= b for _ in range(8): if crc & 1: crc = (crc >> 1) ^ 0xA001 else: crc >>= 1 return crc def send_frame(ser, cmd, payload=b''): frame = b'\xAA\x55' + bytes([cmd]) frame += struct.pack('>H', len(payload)) + payload frame += struct.pack('>H', crc16(frame[2:])) ser.write(frame) # 等待 ACK，超时 500ms ser.timeout = 0.5 resp = ser.read(6) if len(resp) < 6 or resp[0] != 0xAA or resp[1] != 0x55: return None return resp[2] # 返回命令码作为状态 # 打开串口，波特率 460800 ser = serial.Serial('COM3', 460800, timeout=1) # 握手 if send_frame(ser, 0x01) == 0x81: print('握手成功') # 擦除 if send_frame(ser, 0x02) == 0x82: print('擦除完成') # 发送固件，每包 1024 字节 with open('app.bin', 'rb') as f: addr = 0x08004800 while True: chunk = f.read(1024) if not chunk: break payload = struct.pack('>I', addr) + chunk if send_frame(ser, 0x03, payload) != 0x83: print('写入失败，地址', hex(addr)) break addr += len(chunk) # 校验并跳转 if send_frame(ser, 0x04) == 0x84: print('升级成功') ser.close()

脚本里crc16函数跟 BootLoader 里的 CRC 算法必须一致，否则校验永远不过。send_frame发送后等 500ms，超时返回 None，上层可以重试。实际使用时把COM3换成实际串口号，app.bin换成编译出的固件文件。这个脚本我用了好几年，产线升级从没出过批量事故。

5.5 一个让我长记性的教训

早期做这套方案时，我图省事，把升级标志和应用程序放在同一个 Flash 页里。结果升级时擦除应用区，把标志也擦掉了，设备重启后 BootLoader 读不到标志，直接跳转到空的应用区，当场死机。后来把标志单独放一页，并且加了双备份校验，再也没出过这个问题。Flash 分区这件事，宁可多留一页，也不要让不同用途的数据共享擦除单元。希望帮到你。

本文还有配套的精品资源，点击获取