★ FEATURED ARTICLE 简介本资源是一套完整的STM32 Bootloader串口升级工程源码面向嵌入式开发初学者与中级工程师解决MCU固件远程更新与安全升级的核心需求特别适用于工业设备OTA维护、产品现场升级等实际场景。压缩包含109个文件以72个头文件.h和30个源文件.c为主体涵盖HAL库驱动UART/FLASH/TIM/I2C/RCC等、Bootloader主流程、CRC校验模块及底层启动跳转逻辑另含.mxproject工程配置、.ld链接脚本、.ioc引脚定义等关键构建文件总大小833KB结构规范、模块解耦清晰。已有1952人学习下载可直接编译运行于STM32L4系列芯片提供从串口接收、命令解析、Flash擦写、校验验证到复位跳转的全链路实现附带SEGGER RTT调试支持与J-Flash烧录配置是深入理解嵌入式Bootloader机制与实践固件升级流程的优质参考工程。1. 串口升级不是“发个hex就完事”这个STM32 BootLoader工程把固件更新从玄学操作变成可调试、可验证、可量产的确定性流程某客户现场反馈新设备上电后黑屏用ST-Link一连程序跑在BootLoader里死循环——不是APP没跳转而是APP校验失败被拦在门外。翻日志发现串口传过去的bin文件末尾多了两个0x00字节CRC全错。这种问题在产线烧录、售后升级、远程维护中反复出现根源从来不是“BootLoader写得不对”而是缺少完整的升级状态机、无校验回滚机制、无分块确认逻辑、无擦写保护边界检查。这个开源的STM32 BootLoader串口升级工程恰恰补上了这四块关键拼图它基于标准UART支持115200波特率完整实现“接收→校验→擦除→写入→跳转”闭环内置CRC32校验Flash页擦写保护APP头结构解析超时重传握手且所有关键路径都留有调试钩子如BOOT_LOG宏开关。适合嵌入式初学者理解固件升级本质更适合作为工业设备、IoT终端、医疗仪器等对升级可靠性要求严苛场景的量产级底座——你不用从零造轮子但必须亲手跑通、改透、压测过才能把它放进你的BOM清单。2. 工程结构与技术栈从目录树到芯片级依赖看清它为什么能稳定跑在STM32F103C8T6上这个工程不是一堆.c文件堆出来的Demo而是一个按嵌入式固件分层思想组织的轻量级系统。它不依赖HAL库避免HAL_Delay阻塞UART接收也不用CMSIS-RTOS启动阶段禁用中断无需任务调度核心是纯寄存器操作 手动状态机 静态内存分配。整个工程编译后ROM占用8KBRAM仅需256字节用于接收缓冲区完美适配主流Cortex-M3芯片如STM32F103系列。下面拆解它的物理结构和关键技术选型依据。2.1 目录结构与文件职责每个文件都承担明确的不可替代角色STM32_BootLoader_UART/ ├── Core/ # BootLoader核心逻辑 │ ├── bootloader.c # 主状态机接收、校验、擦写、跳转四大阶段调度 │ ├── flash_if.c # Flash底层操作封装页擦除、半字写入、读取校验 │ └── crc32.c # CRC32-IEEE算法实现查表法兼顾速度与ROM ├── Drivers/ │ ├── stm32f1xx_hal_uart.c # 精简版UART驱动仅初始化非阻塞收发 │ └── system_stm32f1xx.c # 系统时钟配置72MHz HSE主频SysTick1ms ├── Inc/ │ ├── bootloader.h # 升级协议定义、APP起始地址、跳转函数声明 │ ├── flash_if.h # Flash操作API声明erase_page, write_halfword │ └── crc32.h # CRC计算接口crc32_calc, crc32_init ├── Src/ │ └── main.c # BootLoader入口时钟/UART/Flash初始化进入main_loop() ├── Startup/ │ └── startup_stm32f103xb.s # 启动文件向量表重映射至0x08000000 ├── Linker/ │ └── STM32F103CB_FLASH.ld # 链接脚本BootLoader占0x08000000~0x08003FFF16KBAPP从0x08004000起 └── Tools/ └── bin2hex.py # 辅助脚本将APP.bin转为带校验头的升级包含CRC长度版本号提示Linker/STM32F103CB_FLASH.ld是整个工程的“地基”。它强制将BootLoader代码段.text链接到Flash前16KB0x08000000–0x08003FFF并把中断向量表.isr_vector也放在这里同时通过VECT_TAB_OFFSET 0x4000告诉CPUAPP的向量表在0x08004000处。这个偏移值必须与APP工程的链接脚本严格一致否则APP跳转后中断会飞。2.2 关键技术选型逻辑为什么不用HAL为什么选CRC32为什么禁止DMA放弃HAL库HAL_UART_Receive_IT()内部使用全局变量管理接收状态在BootLoader这种单一线程、中断密集场景下易被覆盖。本工程采用寄存器级UART接收中断环形缓冲区ring buffer每次RXNE置位只读1字节进buffer由主循环轮询处理彻底规避状态竞争。CRC32而非MD5/SHA升级包通常512KBCRC32查表法计算耗时10ms72MHz主频而SHA256需数秒且ROM开销大。更重要的是CRC32可增量计算——每收到一个数据包立即更新校验值无需缓存全部bin再算极大降低RAM压力。禁用DMADMA虽快但BootLoader运行时若APP正在执行如跳转前未关总中断DMA可能误写APP区域。本工程坚持CPU全程掌控数据流接收靠中断buffer写Flash靠CPU逐半字16bit操作确保每一步都可打断、可回滚、可日志。2.3 BootLoader与APP的协同契约地址、向量表、跳转三要素缺一不可BootLoader能否正确跳转到APP取决于三个硬性约定要素BootLoader侧要求APP侧对应配置错误后果起始地址#define APP_START_ADDR 0x08004000bootloader.hAPP链接脚本中.text起始地址必须为0x08004000跳转到非法地址HardFault向量表偏移SCB-VTOR APP_START_ADDR;跳转前设置APP工程中SystemInit()需调用NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x4000)中断服务函数地址错乱定时器/UART中断失效栈顶地址从APP首地址读取*(uint32_t*)APP_START_ADDR获取MSP初始值APP的startup文件中__initial_sp必须位于bin文件最开头即第0字节进入APP后栈指针错误变量访问越界注意bin2hex.py脚本生成的升级包前4字节就是APP的__initial_sp值接下来4字节是复位向量地址Reset_Handler。BootLoader在写入Flash前会校验这两个值是否在合法范围内如栈顶不能低于0x20000000复位地址不能高于0x080FFFFF否则拒绝写入——这是防止误刷损坏设备的第一道防线。3. 核心模块拆解一个升级请求从UART接收到APP成功运行的完整链路升级过程不是线性流水线而是一个带超时、重试、校验、回滚的状态机。本工程将整个流程划分为5个原子状态每个状态都有明确的进入条件、执行动作和退出路径。下面以一次成功的固件升级为例逐帧解析关键代码。3.1 状态机总览五步闭环任何一步失败都安全回退typedef enum { BOOT_STATE_IDLE, // 等待升级指令如接收U字符 BOOT_STATE_RECEIVE, // 接收bin数据流带包头/长度/CRC BOOT_STATE_VERIFY, // 校验整包CRC验证APP头合法性 BOOT_STATE_FLASH_WRITE, // 擦除目标页逐半字写入 BOOT_STATE_JUMP_APP // 设置VTOR加载MSP跳转 } boot_state_t;状态流转规则IDLE → RECEIVEUART收到字符U且后续3字节为0x55 0xAA 0xFF自定义同步头RECEIVE → VERIFY接收字节数达到包头声明的total_len且最后一包CRC匹配VERIFY → FLASH_WRITEAPP头中app_version current_app_version且reset_handler_addr在合法Flash区间内FLASH_WRITE → JUMP_APP所有页擦写完成且写入后逐字节读回校验成功任意状态超时默认30秒或校验失败 → 强制返回IDLE并拉高LED提示错误3.2 接收状态RECEIVE环形缓冲区如何扛住115200波特率下的数据洪峰UART中断服务程序ISR只做最轻量工作读DR寄存器→存入环形缓冲区→更新tail指针。主循环在BOOT_STATE_RECEIVE下持续解析buffer按协议组包。// drivers/stm32f1xx_hal_uart.c void USART1_IRQHandler(void) { uint32_t isrflags USART1-SR; uint32_t cr1its USART1-CR1; if ((isrflags USART_SR_RXNE) (cr1its USART_CR1_RXNEIE)) { uint8_t data (uint8_t)(USART1-DR 0xFF); // 清RXNE标志 ring_buffer_write(rx_buf, data); // 写入环形缓冲区 } } // core/bootloader.c - 主循环中解析 if (state BOOT_STATE_RECEIVE) { while (ring_buffer_available(rx_buf) PKG_HEADER_SIZE) { // 读取包头4字节magic 2字节len 2字节crc16 uint8_t header[PKG_HEADER_SIZE]; ring_buffer_read(rx_buf, header, PKG_HEADER_SIZE); if (memcmp(header, BOOT_MAGIC, 4) 0) { // magic: 0x55 0xAA 0xFF 0x00 uint16_t pkg_len (header[4] 8) | header[5]; if (ring_buffer_available(rx_buf) pkg_len) { // 缓冲区足够开始接收整包数据 recv_pkg_data(pkg_len); state BOOT_STATE_VERIFY; break; } } } }参数说明PKG_HEADER_SIZE 84字节magic 2字节长度 2字节CRC16校验头。ring_buffer_write()内部使用原子操作更新tail避免ISR与主循环并发冲突recv_pkg_data()函数会将后续pkg_len字节从buffer搬出存入g_recv_buffer[512]静态分配避免malloc碎片。3.3 校验状态VERIFYCRC32不是终点APP头结构才是安全闸门仅仅校验整个bin的CRC32是不够的——攻击者可构造一个CRC匹配但内容恶意的bin。本工程强制APP头包含4个安全字段BootLoader逐项验证#pragma pack(1) typedef struct { uint32_t stack_top; // MSP初始值必须0x20000000 uint32_t reset_handler; // 复位向量地址必须在0x08004000~0x080FFFFF uint32_t app_version; // 版本号升序更新防降级 uint32_t app_crc32; // 整个APP区CRC32不含头部 uint8_t app_name[16]; // ASCII名称如SENSOR_V2.1 } app_header_t;校验逻辑core/bootloader.cbool verify_app_header(uint8_t* app_bin) { app_header_t* hdr (app_header_t*)app_bin; // 1. 栈顶地址合法性检查 if (hdr-stack_top 0x20000000 || hdr-stack_top 0x20005000) { BOOT_LOG(ERR: Invalid stack top 0x%08X\n, hdr-stack_top); return false; } // 2. 复位向量地址范围检查 if (hdr-reset_handler APP_START_ADDR || hdr-reset_handler (APP_START_ADDR 0x30000)) { // APP最大200KB BOOT_LOG(ERR: Invalid reset handler 0x%08X\n, hdr-reset_handler); return false; } // 3. 版本号防降级读取当前APP头版本进行比较 uint32_t cur_ver read_current_app_version(); if (hdr-app_version cur_ver) { BOOT_LOG(WARN: Downgrade blocked! cur%d, new%d\n, cur_ver, hdr-app_version); return false; // 可配置为允许降级此处默认禁止 } // 4. 计算APP区CRC32跳过头部16字节 uint32_t calc_crc crc32_calc(app_bin 16, APP_SIZE - 16); if (calc_crc ! hdr-app_crc32) { BOOT_LOG(ERR: APP CRC mismatch! calc0x%08X, hdr0x%08X\n, calc_crc, hdr-app_crc32); return false; } return true; }关键细节read_current_app_version()函数从当前APP Flash首地址读取app_header_t.app_version字段。它不依赖外部存储而是直接*((uint32_t*)(APP_START_ADDR 12))——因为版本号固定在APP头第12字节stack_top 4B reset_handler 4B app_version 4B。这种“自描述”设计让BootLoader无需额外配置即可感知当前版本。3.4 写入状态FLASH_WRITE页擦除与半字写入的时序陷阱STM32F103的Flash擦除以页为单位1KB/页写入以半字16bit为单位且写入前必须确保目标地址已擦除值为0xFFFF。本工程将APP区划分为多个页按需擦除// core/flash_if.c bool flash_write_page(uint32_t page_addr, uint8_t* data, uint16_t len) { // 1. 解锁Flash FLASH-CR | FLASH_CR_PG; // 使能编程 FLASH-CR | FLASH_CR_PER; // 使能页擦除 FLASH-AR page_addr; // 设置页地址 FLASH-CR | FLASH_CR_STRT; // 开始擦除 // 等待BUSY标志清零擦除约20ms while (FLASH-SR FLASH_SR_BSY); // 2. 逐半字写入data必须2字节对齐 for (uint16_t i 0; i len; i 2) { uint16_t halfword *(uint16_t*)(data i); *(uint16_t*)page_addr halfword; // 触发写入 page_addr 2; // 等待写入完成约5us while (FLASH-SR FLASH_SR_BSY); } // 3. 锁定Flash FLASH-CR ~FLASH_CR_PG; FLASH-CR ~FLASH_CR_PER; return true; }血泪经验曾因忘记在擦除后清除FLASH_CR_PER位导致后续写入失败却无报错——因为FLASH_CR_PER置位时FLASH_CR_PG被硬件忽略。本工程在每次操作后强制清除所有控制位杜绝此类隐性故障。4. 常见问题排查那些让你熬夜到凌晨三点的“灵异现象”及根治方案升级失败的表现千奇百怪但根源往往集中在几个经典坑点。以下是我在三个不同客户项目中踩过的真问题附带定位方法和修复代码行号。4.1 现象串口能收到U指令但后续数据包始终无法触发RECEIVE状态原因ring_buffer_available(rx_buf)返回值恒为0实际是环形缓冲区tail指针在ISR中未正确更新。定位在USART1_IRQHandler中添加__NOP()用ST-Link单步跟踪tail变量发现tail后未对RING_BUFFER_SIZE取模。解决修改ring_buffer_write()函数在buf-tail后增加buf-tail % RING_BUFFER_SIZE;。原始代码漏掉了这行drivers/ring_buffer.c第47行。4.2 现象升级完成后APP能运行但第一次ADC采样值全为0原因BootLoader跳转前未关闭SysTick中断APP的SystemCoreClockUpdate()被SysTick ISR打断导致系统时钟寄存器读取异常。定位在APP的main()第一行加while(1) { __NOP(); }用逻辑分析仪抓取SysTick引脚发现跳转后仍有脉冲输出。解决在BOOT_STATE_JUMP_APP状态入口处插入SysTick-CTRL 0; // 关闭SysTick NVIC-ICPR[0] 0xFFFFFFFF; // 清除所有挂起的中断 NVIC-ICER[0] 0xFFFFFFFF; // 禁用所有中断core/bootloader.c第328行4.3 现象同一份升级包在A设备上成功B设备上校验失败CRC32不匹配原因B设备PCB上UART线路过长15cm且未加100Ω端接电阻115200波特率下信号过冲导致接收字节错位。定位用示波器抓UART_RX引脚发现上升沿有明显振铃部分bit被识别为双倍宽度。解决硬件层面在UART_RX引脚就近加100Ω贴片电阻到地软件层面在recv_pkg_data()中增加字节级CRC校验每收到1字节立即计算其在包内的偏移CRC与发送端预计算的字节CRC比对错则丢弃整包。已在Tools/bin2hex.py中新增--byte-crc参数生成该校验码。4.4 现象升级过程中设备突然断电重启后BootLoader无法启动APP卡在BOOT_STATE_IDLE原因Flash写入到一半断电导致APP头中app_crc32字段为0xFFFFFFFF擦除态但BootLoader的verify_app_header()未检查该值是否有效。定位用ST-Link Utility读取Flash发现APP首地址0x08004000处数据为全0xFF但app_crc32字段偏移12字节也是0xFFFFFFFF。解决在verify_app_header()中增加if (hdr-app_crc32 0xFFFFFFFF) { BOOT_LOG(ERR: APP CRC is erased! Skip verification.\n); return false; // 或改为跳过CRC校验仅检查地址合法性 }core/bootloader.c第189行4.5 现象使用bin2hex.py生成的升级包BootLoader提示“Invalid magic”原因脚本默认生成的magic是0x55 0xAA 0xFF 0x00但BootLoader代码中BOOT_MAGIC宏定义为{0x55, 0xAA, 0xFF}少1字节。定位对比Inc/bootloader.h与Tools/bin2hex.py发现前者定义#define BOOT_MAGIC {0x55, 0xAA, 0xFF}3字节后者写入4字节。解决统一为4字节在bootloader.h中改为#define BOOT_MAGIC {0x55, 0xAA, 0xFF, 0x00} #define PKG_HEADER_SIZE 8 // 422并同步更新bin2hex.py中的MAGIC b\x55\xAA\xFF\x00。5. 二次开发实战如何为你的硬件定制通信协议、增加OTA能力、接入安全启动拿到这个工程别急着编译下载——先想清楚你的产品需要什么。我见过太多团队直接拿开源BootLoader上线结果半年后被客户投诉“升级太慢”“无法回滚”“不支持无线升级”。下面给出三条可立即落地的改造路径每条都附带修改点和验证方法。5.1 改造UART协议从单包升级到分块确认提升弱网环境成功率原协议是一次性接收整个bin对噪声敏感。若你的设备部署在电机旁或变频器附近建议升级为分块ACK协议每接收1KB数据BootLoader回传ACK块序号CRC16上位机收到后再发下一块。修改点在core/bootloader.c中扩展状态BOOT_STATE_RECEIVE拆分为RECV_BLOCK_WAIT_ACK和RECV_BLOCK_READY新增send_ack(uint16_t block_id, uint16_t crc16)函数drivers/stm32f1xx_hal_uart.c修改bin2hex.py按1024字节切分bin每块前加2字节块头block_id total_blocks。验证方法用USB转TTL模块模拟干扰——在TX线上串接一个100Ω电阻100pF电容到地制造高频衰减。原协议在此环境下丢包率30%分块ACK后降至0.2%实测100次升级全部成功。5.2 接入安全启动Secure Boot用RSA-2048签名验证APP合法性工业设备必须防篡改。本工程可无缝集成ARM TrustZone-M或外置安全芯片但最简方案是在APP头后追加RSA签名BootLoader用公钥验签。修改点扩展app_header_t在末尾增加uint8_t signature[256]RSA-2048签名verify_app_header()中调用rsa_verify()函数可移植mbed TLS的mbedtls_pk_verify()bin2hex.py增加--sign-key private_key.pem参数用私钥对APP头bin计算签名。关键约束RSA验签需约80ms72MHz必须关闭所有中断公钥需硬编码在BootLoader Flash中如0x08003000且该区域设为写保护FLASH_OBR寄存器配置。我一般把公钥哈希存入OTP区域启动时校验公钥完整性。5.3 增加双Bank OTA实现“升级不中断服务”的终极方案医疗设备或PLC控制器要求升级时业务不中断。方案是Flash分两区Bank A/BBootLoader永远从当前active bank启动升级时写入inactive bank校验成功后切换active标志。目录结构调整Linker/ ├── STM32F103CB_FLASH_BANKA.ld # Bank A: 0x08000000~0x0801FFFF (128KB) └── STM32F103CB_FLASH_BANKB.ld # Bank B: 0x08020000~0x0803FFFF (128KB)核心新增逻辑定义#define ACTIVE_BANK_FLAG_ADDR 0x08003FF0存储1字节标志0A, 1BBOOT_STATE_JUMP_APP中根据标志读取对应bank的APP头FLASH_WRITE阶段先擦除inactive bank再写入新固件最后一步*(__IO uint8_t*)ACTIVE_BANK_FLAG_ADDR new_bank_id;原子写入。验证技巧在main.c中加入心跳LED每100ms翻转一次。升级过程中观察LED——若闪烁不间断证明双Bank切换无停顿若闪烁暂停500ms则需优化Flash擦除时间可改用扇区擦除但需重写链接脚本。从那以后我每次接到BootLoader需求都强制走一遍“断电测试”在FLASH_WRITE循环中插入if (i 1024) NVIC_SystemReset();模拟升级中途掉电然后检查设备能否自动恢复到旧版本。只有通过这个测试的代码我才敢让它进产线。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
