简介面向STM32F4嵌入式开发者这套资源围绕串口与RS485两种物理链路的OTA升级实现解决设备固件远程更新与维护的典型需求。包内包含自制Bootloader与App两个独立完整工程覆盖引导程序跳转、固件分包传输、完整性校验、Flash擦除与写入的完整流程可直观学习在线升级协议的设计思路适合有单片机基础并希望深入掌握Bootloader编写及升级机制的工程师。资源共277个文件以C源文件和头文件为主同时提供Keil工程文件、编译生成的bin与hex固件、axf和map等辅助文件便于直接编译烧录并能结合map文件排查链接与地址问题压缩包约2.86MB结构紧凑清晰。目前已有2540人学习下载与作者博客的配套说明结合使用可快速搭建一套可实际运行的串口或RS485升级方案显著缩短二次开发周期。1. STM32F4的串口OTA升级为什么你得先搞懂Bootloader的边界做嵌入式开发的人迟早会遇到一个尴尬场景产品已经量产贴片现场设备跑着跑着需要更新固件你总不能拎着J-Link挨个拆机壳。STM32F4的串口OTA升级本质上是把Flash划分成Bootloader区和App区让芯片上电先跑Bootloader再决定是跳转到App还是进入升级流程。这篇笔记要拆的是方式1——通过串口或者RS485把固件bin文件推给设备Bootloader收到后写入App区最终完成跳转。适合手里有F4板子、想把OTA这套流程从零搭起来的人。你会发现真正麻烦的不是协议本身而是Flash分区、中断向量重映射、校验策略这些细节哪一步没想清楚升级现场就会教你做人。2. 分区与启动流程先把Flash地理格局画清楚2.1 Bootloader区和App区的地址怎么分才不打架STM32F4系列内部Flash从0x08000000开始容量从512KB到1MB不等。把Bootloader放在最前面是最稳妥的方案因为芯片上电后固定从0x08000000取向量表。我习惯给Bootloader分配32KBApp区紧随其后。以512KB Flash的F407为例Bootloader占用0x08000000到0x08007FFFApp区从0x08008000开始。为什么要留32KB而不是16KB因为Bootloader除了串口收发还要做Flash擦写、校验、超时管理代码量很容易膨胀到20KB以上16KB会写得很憋屈。App区末尾再留一块区域存升级标志这个标志位决定Bootloader是直接跳转还是等固件。#define BOOTLOADER_START_ADDR 0x08000000 #define BOOTLOADER_SIZE 0x8000 /* 32KB */ #define APP_START_ADDR 0x08008000 #define APP_MAX_SIZE 0x78000 /* 480KB留给标志位 */ #define UPGRADE_FLAG_ADDR 0x0807F800 /* App区末尾的2KB区域 */这一段代码里最关键的是UPGRADE_FLAG_ADDR的选取。很多人直接把升级标志放在App区开头结果App自己跑起来之后不小心覆盖了标志位下次重启Bootloader判断错误。我一般把标志位放在App区末尾的独立2KB扇区这样App的代码数据几乎不可能误写到这里。F4的Flash扇区大小不是均匀的后几个扇区往往是128KB甚至更大选地址前务必查一下具体型号的扇区划分表别想当然。2.2 上电后的判断逻辑跳转、升级、还是等待超时Bootloader的启动流程是固定的三选一检测到升级标志且校验通过进入接收固件流程没有标志就校验App区首地址的栈指针是否合法合法则直接跳转如果App不存在或者App区是空的就停在Bootloader里等串口数据。这个决策不能简单用if-else堆因为跳转前先要把系统时钟、外设中断都恢复默认状态。很多人跳转App后程序跑飞Debug大半天发现是Bootloader里开了某个外设中断没有关掉App初始化时中断一来就死循环。int main(void) { HAL_Init(); SystemClock_Config(); if (CheckUpgradeFlag() FLAG_SET) { ReceiveFirmwareAndWriteToFlash(); } else if (CheckAppValid(APP_START_ADDR)) { JumpToApp(); } else { /* 无App且无升级请求等待串口指令 */ WaitForUpgradeCommand(); } while (1) { } }CheckAppValid这个函数是决定跳转安全性的关键它读取App区起始地址的前8个字节——前4字节是初始栈顶指针MSP后4字节是复位中断向量。判断MSP是否落在SRAM地址范围内同时检查复位向量是否落在Flash的App区范围内两个条件都满足才允许跳转。这里有个血泪教训别只检查MSP不检查PC向量否则Flash被擦空之后复位向量是0xFFFFFFFF跳过去直接HardFault。3. 串口/RS485传输协议帧格式、重传机制与握手时序3.1 自定义协议还是XMODEM什么场景选什么传输层协议的选择是升级方案里最值得花时间琢磨的地方。YMODEM的优点是实现简单、每包128字节带CRC16校验网上代码一大把缺点是只能点对点没有广播和应答超时重传控制485总线上多个设备需要逐个寻址升级时YMODEM就捉襟见肘了。自定义帧协议的代价是你要自己处理粘包、半包、校验、超时重传但好处是可以塞设备地址、帧号、命令类型调试和生产阶段在总线上挂个串口助手就能看明白谁在跟谁说话。这块要实现的是自定义协议方案帧格式设计成帧头2字节固定0xAA55、设备地址1字节、命令字1字节、数据长度2字节、数据段、CRC32校验4字节。typedef struct __attribute__((packed)) { uint16_t head; /* 0xAA55 */ uint8_t dev_addr; /* 设备地址485总线用 */ uint8_t cmd; /* 命令字 */ uint16_t len; /* 数据段长度 */ uint8_t data[1024]; /* 固件数据块 */ uint32_t crc; /* 数据段CRC32 */ } UpgradeFrame_t;帧头、地址、命令字都固定长度这样接收端可以用状态机逐字节解析。dev_addr字段只在RS485组网时有用串口点对点可以直接填0。数据段最大1024字节合并了F4的Flash页大小——F4的页大小一般是16KB或128KB的倍数但不对齐到页也能写所以1024这个值更多是协议缓冲区与串口速率之间的折中。帧太长单包出错重传代价大太短传输效率低。3.2 升级握手的时序谁先开口超时多久才不算误判握手时序定成上位机先发0xAA55 0x00 0x01 0x00 0x00 0x00 0x00 0x00的查询帧Bootloader收到后回应用户程序版本号。这个设计的核心价值是防止误升级——上位机连上就发固件万一设备正在跑业务程序根本不该响应。先握手确认设备处于Bootloader模式再开始传输。超时参数定的是Bootloader收到查询帧后2秒内必须应答上位机收到应答后5秒内开始发第一包数据。#define HANDSHAKE_TIMEOUT_MS 2000 #define FRAME_TIMEOUT_MS 500 #define MAX_RETRY_COUNT 3 switch (current_state) { case STATE_WAIT_QUERY: if (ParseQueryFrame()) { SendVersionInfo(); current_state STATE_WAIT_DATA; } break; case STATE_WAIT_DATA: if (ReceiveFrame(frame) OK) { current_state ProcessDataFrame(frame); } else if (CheckTimeout(FRAME_TIMEOUT_MS)) { current_state STATE_WAIT_QUERY; } break; }FRAME_TIMEOUT_MS设成500毫秒与波特率的配合是115200波特率下传一包1024字节大约耗时90毫秒加上串口处理延时500毫秒足够宽裕。这个超时是两用的——既检测上位机掉线也防止Bootloader卡死在等待状态。如果上位机发了一半停住Timeout之后Bootloader自动回到查询状态重新等待握手这个设计让升级中断后的恢复变得非常干净。4. 接收固件与写Flash擦除策略、页对齐与掉电保护4.1 先整片擦除还是边收边擦空间与风险的取舍写Flash之前必须先擦除。F4的Flash擦除粒度是扇区不是页。Bootloader和App的分区里App区往往跨越多个扇区。这里有个关键决策点升级开始时一次性把App区全部擦干净好处是写入逻辑简单、不怕残留旧代码干扰坏处是擦除期间断电设备就变砖了App区空空如也。边收边擦则是收到哪一页的数据就先擦哪一页缺点是如果固件传输中途中断Flash里可能是半新半旧的混合代码下次启动连CheckAppValid都过不了。我实测下来更倾向先整片擦除的方案理由很朴素——Bootloader本身还在设备顶多停在等待升级状态重新发一次固件就恢复了。static void EraseAppArea(void) { FLASH_EraseInitTypeDef erase {0}; uint32_t page_error 0; uint32_t start_sector GetSectorFromAddr(APP_START_ADDR); uint32_t end_sector GetSectorFromAddr(APP_START_ADDR APP_MAX_SIZE); erase.TypeErase FLASH_TYPEERASE_SECTORS; erase.Sector start_sector; erase.NbSectors end_sector - start_sector 1; erase.VoltageRange FLASH_VOLTAGE_RANGE_3; HAL_FLASH_Unlock(); if (HAL_FLASHEx_Erase(erase, page_error) ! HAL_OK) { ErrorHandler(); } HAL_FLASH_Lock(); }GetSectorFromAddr是根据Flash起始地址计算扇区编号F4每个型号的扇区大小表不同这个函数需要自己维护一份映射表。擦除操作必须在HAL_FLASH_Unlock()之后执行写完再Lock。这里补充一个容易被忽略的点HAL_FLASHEx_Erase执行期间CPU是阻塞的不能用中断方式打断这段时间系统不响应任何串口数据。如果正在传输固件的过程中执行擦除上位机那边要设计好等待逻辑否则串口缓冲区溢出数据就漏了。4.2 写入函数的调用时机与参数边界Flash写入按字节还是按字取决于你调用的HAL函数。F4支持8位、16位、32位三种粒度写入但32位写入最快且Flash编程规约要求写32位数据时地址必须4字节对齐。协议帧的数据段长度不是固定倍数最后一包数据如果不是4的倍数补0处理。这也是为什么前面帧格式里data字段大小是1024——1024天然对齐但最后一包肯定不满要特判。static void WriteFirmwareBlock(uint32_t dst_addr, uint8_t *data, uint16_t len) { uint32_t aligned_len (len 3) ~3; uint8_t padded[1024] {0}; memcpy(padded, data, len); HAL_FLASH_Unlock(); for (uint32_t i 0; i aligned_len; i 4) { uint32_t word *(uint32_t *)(padded i); if (HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, dst_addr i, word) ! HAL_OK) { ErrorHandler(); } } HAL_FLASH_Lock(); }这段代码的逻辑是先把收到的数据块复制到本地padded缓冲区高位补0然后按4字节为单位循环写入。aligned_len的计算方式是(len 3) ~3这是向上取整到4的倍数的位运算写法。实际开发中写入一帧之后返回一个ACK给上位机上位机收到ACK之后才发下一帧——这个机制保证了流控。有些上位机实现者把write函数放在中断里处理中断里调HAL_FLASH_ProgramFlash写入期间中断被硬件阻塞来回嵌套很容易出问题。我踩过这个坑之后强制要求所有Flash操作必须放在主循环里做中断只负责把数据搬进RAM缓冲区。4.3 掉电保护与断点续传这块需不需要做固件传输到一半断电重新上电后Bootloader发现升级标志还在继续等待固件上位机重新下发整个固件。因为之前已经整片擦除过所以重复传输没有数据残留的问题。但有个细节如果断电发生在最后一帧刚写完、标志位还没清除的瞬间下次启动会重复进入升级流程但固件其实已经完整了。解决办法是在写完整个固件后先读出App区前的8个字节做一次验证验证通过再清标志位否则保留标志并等待重新传输。int VerifyAppHeader(void) { uint32_t msp *(volatile uint32_t *)APP_START_ADDR; uint32_t reset_vector *(volatile uint32_t *)(APP_START_ADDR 4); if ((msp 0x2FFFF000) ! 0x20000000) return 0; if ((reset_vector 0xFFF00000) ! 0x08000000) return 0; return 1; }VerifyAppHeader检查栈顶指针必须落在SRAM区域内0x20000000起始复位向量必须落在Flash区域内0x08000000起始。这两个条件看似简单却能拦住绝大多数无效固件。我见过有人往App区写了一段纯数据流刷完就变砖正是因为跳转前没有做这类合法性校验。写App之前先想清楚怎么证明它是个能跑的固件。5. 避坑指南STM32F4 OTA升级最常见的五个翻车现场5.1 跳转App后死机中断向量表没改现象Bootloader正常跳转App的main函数进了但一开中断就HardFault。原因App侧编译时链接脚本里指定的Flash起始地址还是默认的0x08000000中断向量表也留在原地。Bootloader跳转后CPU从App的main开始跑一旦外设触发中断CPU去0x08000000取中断向量取到的是Bootloader的向量表对应外设中断处理函数可能根本不存在直接崩溃。解决在App的main函数最开始执行SCB-VTOR APP_START_ADDR;把中断向量表重映射到App区。同时修改链接脚本的FLASH起始地址为0x08008000。void main(void) { SCB-VTOR APP_START_ADDR; /* 后续其他初始化 */ }5.2 波特率越高越容易传输失败布线背锅现象115200波特率测试正常换460800就频繁超时重传帧内容随机错位。原因OTA升级用的串口线如果是杜邦线飞线高速下信号边沿变差再加上Bootloader和App两边对波特率误差的容忍度不同。F4的串口时钟来自APB总线如果分频系数不是整数实际波特率跟理论值有偏差高速时偏差积累到一定程度就解码错误。解决现场用485组网时把波特率压到57600或者38400线缆短、干扰小的台架测试可以用115200。跑量产品128000以上的波特率要慎重除非你确认晶振精度在±20ppm以内。5.3 CRC本地计算和Bootloader算出来的不一致类型转换的锅现象用上位机工具计算固件的CRC32跟Bootloader里HAL_CRC_Calculate的结果对不上。原因HAL库的CRC外设默认多项式是0x04C11DB7输入和输出的字节序处理跟你在PC上用的zlib crc32不一致。CRC外设还带CRC_INITVALUE复位寄存器计算前不重置会累加上一次的结果。解决要么统一用软件CRC32实现在PC端和MCU端跑同一份代码要么用硬件CRC外设时仔细核对HAL库的配置注意HAL_CRC_Init里的InputDataFormat和PolynomialSize两个参数。5.4 升级中途485总线被占用收发切换的时序现象上位机发完一帧数据Bootloader迟迟不回ACK手动复位后升级又正常了。原因485芯片的方向控制脚切换需要时间。Bootloader收到完整帧后立刻把RS485的DE引脚拉低但此时发送缓冲区可能还没完全发完反向冲击导致数据被打坏。解决DE引脚切换前等待UART_FLAG_TC置位确保发送移位寄存器完全排空。while (__HAL_UART_GET_FLAG(huart, UART_FLAG_TC) RESET); HAL_GPIO_WritePin(RS485_DE_PORT, RS485_DE_PIN, GPIO_PIN_RESET);5.5 App擦除后立刻断电Bootloader也不跑了现象升级一开始擦除App区瞬间断电重新上电后Bootloader卡死或者行为异常。原因这不是App变砖的问题而是擦除过程中Bootloader代码所在扇区也被波及。如果Bootloader和App的分区边界刚好落在扇区分界线上擦除操作由于扇区编号计算错误把Bootloader区域的扇区也纳入擦除范围Bootloader自然尸骨无存。解决擦除前打印或记录下来实际要擦的扇区范围确认起始扇区不落在Bootloader区域。另外生产时保留SWD调试接口万一Bootloader被擦还能用J-Link恢复。6. 验证这一整套方案从空片到可运行的完整链路一个更稳妥的验证路径是用QEMU模拟但F4的QEMU支持不完善。最可靠的方法是找一块F4开发板把Bootloader通过ST-Link烧进去然后走一遍完整的升级流程。我会在Bootloader里加一个版本号宏定义通过串口助手主动查询版本信息确认设备确实进入了Bootloader模式而不是误跑App。然后再开始传固件传完观察跳转之后LED的闪烁频率是否变化。升级完成之后还要做两个额外验证。第一个是断电重启断电、上电确认设备能自动进入App而不需要重新烧录。第二个是异常恢复把App区首地址写0模拟固件损坏确认Bootloader不会尝试跳转而会进入等待升级状态。/* 通过串口发送版本查询指令 0xAA 55 00 01 00 00 00 00 00 */ #define APP_VERSION 0x02 void JumpToApp(void) { typedef void (*AppEntry)(void); uint32_t app_msp *(volatile uint32_t *)APP_START_ADDR; AppEntry jump (AppEntry)(*(volatile uint32_t *)(APP_START_ADDR 4)); __disable_irq(); SCB-VTOR APP_START_ADDR; __set_MSP(app_msp); jump(); }这段跳转代码里的顺序很重要先禁用全局中断再重映射向量表最后设置MSP并跳转。__disable_irq()在跳转后App侧需要重新使能中断所以App的main函数第一行建议补一句__enable_irq()否则中断一直关着外设全都不工作。我从那以后每次搭OTA方案都强制走一遍这个验证流程空片烧Bootloader、查询版本、传固件、重启进App、再模拟一次固件损坏恢复。整个流程跑透心里才有底。串口OTA升级这件事方案本身不难难的是把每个环节的异常都想到。希望这篇笔记能帮你少踩几个坑。本文还有配套的精品资源点击获取