做嵌入式有些年头了第一次被安排做STM32G4 Bootloader开发的时候心里其实也发怵。当时项目要求整机批量出厂后能走串口升级固件不能每次改个bug就拆壳上烧录器。网上资料一搜一大堆但要么停留在F1系列的老套路要么只讲原理不给代码真正能把CubeMX配置、中断向量表、Flash划分这条线串起来讲清楚的少之又少。后来自己踩了无数个坑也帮同事排过不少雷才慢慢把这套流程吃透。这篇文章我就以STM32G4为主线从CubeMX工程配置开始把Bootloader的Flash划分原则、跳转逻辑、固件接收与烧写这些核心环节逐个拆开讲。凡是新手容易卡壳的地方我会单独拎出来说清楚为什么这么写、不这么写会出什么问题。别人文档里不写的坑我会尽量都补上。如果你正准备在STM32G4上做IAP升级或者已经被启动跳转、写Flash失败、中断不响应这些问题折磨得头大这篇文章应该能让你少走几个星期弯路。1. 先把Bootloader这件事想清楚为什么需要它1.1 Bootloader到底在解决什么问题Bootloader本质上是一段放在芯片启动地址上的“引导程序”。芯片上电后先运行它它来决定是直接跳转执行主应用程序还是进入升级模式接收新的固件。这样做最大的好处就是设备在出厂后不需要借助外部烧录工具也能通过串口、CAN、USB甚至无线方式完成固件更新。很多刚入行的朋友不理解直接给整机留一个SWD接口用烧录器刷不也一样吗但如果你的设备已经装进密封外壳或者部署在几百个现场逐个开壳烧录既费人力又有风险。更关键的是产品交付后不可能永远不更新功能、不修bug远程升级能力在很多行业已经成了标配。STM32G4这类芯片内置了足够大的Flash完全可以在不增加硬件成本的前提下通过软件方式实现IAP In Application Programming。不过Bootloader也不是随便写写就能用的。它的核心难点不在于那几行跳转代码而在于你得对整个芯片的存储结构、启动机制、外设中断机制有足够清晰的理解。这恰恰是网上教程讲得最不透彻的地方。1.2 STM32G4的启动流程与IAP原理Cortex-M4内核的启动流程很固定。上电后硬件自动从地址0x08000000读两个字第一个字是初始栈指针MSP第二个字是复位异常处理函数的入口地址也就是PC的初始值。随后CPU从复位向量指向的地址开始执行代码。默认情况下中断向量表就在0x08000000。理解这一点是搞懂Bootloader跳转的钥匙。我们做IAP时Bootloader放在0x08000000App应用程序放在另一个Flash地址比如0x08010000。片上电先执行BootloaderBootloader判断条件后如果想进入App就直接把栈指针和PC指针指向App区域。但App区域有自己的中断向量表它通常不会还在0x08000000因此App启动后必须重新设置中断向量表偏移SCB-VTOR否则一旦产生中断CPU仍然会去0x08000000处寻找中断服务函数而那里跑的是Bootloader的中断向量表结果就是中断错乱、功能失灵。STM32G4作为M4内核产品写跳转代码时还需要注意内核与厂商库之间的配合。HAL库已经帮我们封装好了读写Flash和设置VTOR的接口但底层原理必须心里有数你跳转的App地址必须是一个合法的Flash地址App的起始位置必须存放正确的栈顶地址和复位向量两个条件少一个系统直接HardFault。2. CubeMX配置少走弯路的工程初始化2.1 时钟树与引脚规划别让外设打架用STM32CubeMX生成STM32G4工程起步最关键的还是时钟树。很多人觉得时钟随便配一下能跑就行但在Bootloader开发里Bootloader和App两边的主频如果不一致极容易引出串口波特率错乱、Flash读时序异常等莫名其妙的问题。我一般建议Bootloader和App用同一套时钟配置比如外部晶振25MHzPLL跑到系统最高频率170MHz两边保持一致这样就少了一个可变量。引脚规划也值得提前想清楚。Bootloader阶段要用串口下载固件那就要避开App里已经使用的引脚尤其要小心冲突。比如你的App默认把某个串口引脚复用成了别的功能Bootloader启动后初始化了同一个串口结果一跳到App外设配置就打架。规范做法是Bootloader只初始化自己需要用到的外设跳转App前不进行DeInit直接让App接管所有外设寄存器状态。因为复位后每个芯片外设都处于默认状态App启动时本来就会重新初始化一遍Bootloader不用画蛇添足。CubeMX里还有一个容易踩的坑就是生成代码时默认开启了全部中断但你根本没有写中断处理函数。Bootloader阶段如果开了无关外设中断一旦触发就会进入死循环。我习惯在CubeMX里只开启Bootloader必需的UART和必要的DMA其它外设全部禁用把风险降到最低。2.2 串口、GPIO与看门狗的配置细节Bootloader最常用的升级通道就是串口。CubeMX里配置UART时除了使能USART外还要关注波特率稳定性。Bootloader阶段系统刚上电如果PLL还没稳定就初始化UART首帧数据大概率是错的。因此我在代码里会先配置时钟、延时几十毫秒再初始化串口。串口收发建议用环形缓冲区加中断的方式简单可靠。如果文件比较大可以考虑用DMA配合空闲中断。但这里提醒一句STM32G4的DMA请求映射和F1差别不小生成DMA初始化代码后务必确认请求源选的是对应串口的TX/RX否则数据看着像发了实际上根本没进外设。GPIO方面Bootloader里至少要做一个升级请求引脚比如一个按键输入或者跳线检测。我用得比较多的是一个上拉输入引脚外部接地表示要求进入升级模式。配置成内部上拉、外部下拉触发这样电路板出厂时无需额外跳线也能通过软件控制进入Bootloader。看门狗是很多人忽视的雷区。如果Bootloader里开启了独立看门狗IWDG而接收固件的过程比较慢没有及时喂狗芯片就会在升级途中反复复位。我的建议是Bootloader里尽量不开看门狗如果产品安全要求必须开那也必须在接收固件时用状态机喂狗而不是简单地在主循环里随便喂。升级写Flash的瞬间不能喂狗所以要计算好单次擦写时间保证不超时。2.3 自定义链接脚本的前置准备IDE工程设置在CubeMX里生成了初始工程之后Bootloader本身不需要额外改链接脚本但App工程是必须要改的。无论你用Keil、IAR还是STM32CubeIDE都要让App的链接地址从你划分的App区起始地址开始。这一步经常被忘记导致很多人写完跳转代码后发现App根本跑不起来。Keil里我会在Options for Target - Target页签把IROM1的Start改为App起始地址比如0x08010000Size改为App可用大小。IAR则是在.icf文件里修改ROM起始地址。STM32CubeIDE使用GCC链接脚本需要在.ld文件中改FLASH的ORIGIN和LENGTH。这些改动虽然简单但每个IDE的位置都藏得比较深新手往往找不到。还有一点要注意改了链接地址后一定要确认编译生成的bin文件大小没有超出App分区容量。有的编译器默认只报错不警告超了根本不知道。我习惯在编译脚本里加一条size检查命令超容量直接中断编译比事后刷机变砖强得多。3. Flash划分Bootloader灵魂在于空间规划3.1 STM32G4 Flash布局与页/扇区结构STM32G4系列虽然同属一个家族但不同型号的Flash容量和页大小并不完全一样。比如G431和G473的Flash容量就不同页大小也可能存在差异。所以在设计分区前第一步永远是查对应型号参考手册中的Flash organization章节确认总容量、页大小、页数量以及是否支持双Bank。这里要特别强调双Bank。STM32G4不少型号支持双Bank Flash结构也就是Flash被分成两个独立的存储块支持在一个Bank上执行代码的同时擦写另一个Bank。这个特性对A/B升级方案非常有用但对于刚开始接触Bootloader的朋友双Bank也会带来额外的复杂度。如果你不需要真正的断电回滚建议在配置Option Bytes时将Flash设置为Single Bank模式让Flash变成一段连续地址Bootloader逻辑会简单很多。设置这个选项可以用STM32CubeProgrammer也可以在代码里通过FLASH_OBProgram实现。页大小决定了你擦除的最小单位。比如某个型号的页大小是4KB那你写App时最好按页对齐避免出现跨越两个页的逻辑。否则程序里虽然是顺序写地址但Flash写操作在每个页的末尾都需要重新Unlock和擦除一个不小心就会覆盖相邻区域的数据。3.2 推荐的分区方案因为STM32G4的Flash容量覆盖范围比较大我直接给一个通用的三分区方案并解释每个区的用途分区起始地址示例大小用途Bootloader区0x0800000032KBIAP引导代码、串口接收逻辑、Flash驱动App参数区0x080080004KB升级标志、版本号、配置参数、升级计数器App区0x08009000剩余空间用户应用程序、中断向量表、业务代码为什么要单独划分一个参数区这是很多人忽略的细节。如果升级标志直接放在App区末尾每次擦写App区都会把标志擦掉导致逻辑混乱。单独划一块参数区Bootloader先读参数区来判断是直接跳App还是进入升级流程然后App也只有明确收到升级指令时才写这一个标志这样两者互不干扰。A/B备份分区是更高阶的方案两个App分区交替存放当前版本和新版本Bootloader启动时根据标志选择运行哪一版。这个方案升级失败可以自动回滚但需要双倍Flash空间。对于G4大容量型号完全可行但我不建议第一版Bootloader就直接上A/B先把单分区跑通再考虑冗余设计。3.3 中断向量表偏移与App工程设置App程序运行前一定要重定位中断向量表否则一切中断都是泡泡。在STM32G4中通过设置SCB-VTOR寄存器来指定新的向量表基址。常规写法#define APP_FLASH_START 0x08009000 SCB-VTOR APP_FLASH_START;不过这句代码必须放在App工程的最早期最好的位置是在编译器自带的启动文件执行完之前。如果你用的是HAL库通常把这个赋值放在SystemInit函数后面、main函数最开始的位置而且要保证此时全局中断还是关闭状态。否则在重定位过程中来了一个中断CPU依然会去旧地址取向量如果旧地址处已被覆盖就直接崩了。一个更常见的坑是VTOR偏移量必须对齐。Cortex-M4要求向量表地址要按表大小对齐但STM32的向量表大小通常远小于64字节实际使用中大家习惯按至少0x400对齐。比如你在0x08009000划分App区0x9000本身就是0x400的倍数没问题。但如果你把App放在0x08009200这种地方设置VTOR后大概率会出问题因为0x200不是0x400的倍数。所以App区起始地址尽量选0x08008000、0x08010000这类规整地址别选奇奇怪怪的偏移。4. 核心代码实现从跳转到Flash写入4.1 跳转App前的最后检查栈顶与复位向量跳转动作本身很简单但“安全跳转”才是关键。写一个万无一失的跳转函数必须对App区开头两个字的合法性做检查。第一个字是栈顶地址必须落在芯片的RAM地址范围内第二个字是复位向量必须落在Flash地址范围内。检查不通过就说明App区根本没有烧录或者烧录的是损坏数据这时候强行跳过去只能是死循环。下面这个函数我用了很多年稍微改改就能用#define APP_START_ADDR 0x08009000 typedef void (*AppFunc)(void); void JumpToApp(void) { uint32_t stack_addr *(volatile uint32_t *)APP_START_ADDR; uint32_t reset_addr *(volatile uint32_t *)(APP_START_ADDR 4); // 简单合法性检查栈顶应该在SRAM区复位向量应该在Flash区 if ((stack_addr 0xFFF00000) ! 0x20000000) { return; } if ((reset_addr 0xFFF00000) ! 0x08000000) { return; } // 关闭全局中断防止跳转过程中断响应错乱 __disable_irq(); // 设置中断向量表偏移 SCB-VTOR APP_START_ADDR; // 设置主栈指针 __set_MSP(stack_addr); // 跳转到App复位向量 AppFunc app_entry (AppFunc)reset_addr; app_entry(); }注意这里我特意加了__disable_irq()很多教程没这一步结果跳转时正好来一个串口中断CPU按老向量表取中断函数直接HardFault。跳转前关中断是最稳妥的做法App启动阶段会重新配置NVIC不会有什么影响。另外提醒一句__set_MSP之后如果App里用了RTOSOS会再切换一次栈指针到线程模式所以Bootloader侧不用考虑MSP和PSP切换的细节交给App处理即可。4.2 串口Ymodem/自定协议接收固件升级固件怎么传到芯片里核心是一个通信协议。船坞用Ymodem因为很多上位机工具原生支持也有不少产品为了省事自己定义一套“帧头长度数据CRC”的小协议。我第一版Bootloader用的是Ymodem后来因为需要在公司内部上位机集成更多业务逻辑改成了自定义协议。Ymodem的好处是成熟稳定断点续传和文件校验都有现成实现PC端用SecureCRT或者STM32CubeProgrammer都能发。坏处是代码量有点大底层1024字节一包处理不好容易触发Bootloader的缓冲区溢出。如果你也是第一次做直接用精简版的Ymodem接收即可核心就两个动作接收包含文件名和长度的起始帧再循环接收数据帧每帧写入Flash最后接收结束帧。自定义协议则灵活很多。比如我常用的一版协议格式字段长度说明帧头2字节0xAA55命令1字节0x10升级开始 / 0x20数据包 / 0x30结束包序号2字节从0递增数据长度2字节通常256或512数据区变长固件内容CRC324字节对前面所有字段做校验接收时我一般不开复杂的状态机就用一个简单的固定大小数组缓存一帧校验通过后直接请求下一帧。上位机发送速度要控制每次收到应答再发下一包这样Bootloader压力小调试也直观。4.3 Flash擦写时序与读保护注意STM32G4的Flash写入和擦除必须遵循官方时序。HAL库提供了HAL_FLASH_Unlock、HAL_FLASHEx_Erase、HAL_FLASH_Program等接口用起来很方便但有几个细节需要特别留意。第一写Flash前要确保目标地址处于擦除状态。Flash只能把1写成0不能把0写成1。所以编程前必须先擦除整个页。你不可能只擦一个字节页是擦除的最小单位。如果你升级的数据跨越页边界必须一次擦除多页。第二执行Flash操作时需要关闭所有中断尤其要关掉串口中断防止擦写过程中进入中断服务程序而服务程序又访问了正在被擦写的Flash区域导致总线错误。HAL库内部其实会处理这些事情但在实际项目中我仍然习惯在调用擦写接口之前手动__disable_irq()写完再恢复。第三读保护。STM32G4的Option Bytes里有RDP级别如果把读保护级别设成1那Bootloader和调试器默认还能通过SWD连接但如果你用CubeProgrammer读取Flash就会受限。调试阶段我干脆不设置读保护等产品量产前再把读保护和写保护按需要打开。否则你会发现明明写Flash代码没问题但一运行就返回错误十有八九是写保护挡着。代码层面的擦写流程可以参考下面这个简化版void FlashWriteFirmware(uint32_t app_addr, uint8_t *data, uint32_t len) { FLASH_EraseInitTypeDef erase; uint32_t page_error 0; uint32_t page_size FLASH_PAGE_SIZE; // 查手册 __disable_irq(); HAL_FLASH_Unlock(); // 擦除涉及的所有页 erase.TypeErase FLASH_TYPEERASE_PAGES; erase.Page GetPageFromAddress(app_addr); erase.NbPages (len page_size - 1) / page_size; HAL_FLASHEx_Erase(erase, page_error); // 依次写入数据STM32G4支持64位编程 for (uint32_t i 0; i len; i 8) { uint64_t data64 0; for (int j 0; j 8; j) { if (i j len) data64 | ((uint64_t)data[i j]) (8 * j); else data64 | 0xFF (8 * j); } HAL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD, app_addr i, data64); } HAL_FLASH_Lock(); __enable_irq(); }这里GetPageFromAddress需要根据具体型号把地址换算成页号不同型号差异较大务必参考手册实现。记住Flash写操作前检查电源电压是否稳定G4的Flash编程需要VDD满足要求如果供电不稳写进去的数据可能直接损坏。5. 调试中的坑与排查实录5.1 跳转无效/死机的三个元凶跳转App后程序跑飞这个问题几乎每个Bootloader开发者都遇到过。我总结了三个高频原因按出现概率排序。第一App工程编译地址没有改。很多人写好了BootloaderApp还是默认链接在0x08000000两个程序都放在同一个地址跳过去自然是执行了Bootloader自己的代码或者直接访问了不存在的函数地址。这个检查最快打开App工程的Map文件看第一条记录是不是从0x08009000开始即可。第二栈指针检查没通过但Bootloader忽略了状态强行跳转。有的资料里跳转函数不检查stack_addr合法性而App区还没有烧录时内存里全是0xFFFFFFFF转换出来的地址访问直接触发总线错误。所以跳转前必须做合法性校验校验不通过就留在Bootloader里。第三App区中断向量表偏移没设对。App跳起来后能跑一会儿但一流一个USART中断就死多半就是这个原因。需要检查SCB-VTOR的值是否和链接脚本里的FLASH_ORIGIN完全一致以及是否有代码在跳转前改写了VTOR又被Bootloader覆盖。5.2 写Flash导致硬错误写Flash出错也是高频问题。常见表现是调用HAL_FLASH_Program时直接HardFault或者返回值一直是错误状态。排查思路逐个来现象可能原因处理办法一写Flash就死机中断没有关闭Flash擦写期间进了中断调HAL_FLASH_Program前关全局中断返回参数错误0xFF目标地址没有擦除先调用页擦除再写数据只有地址末尾出错写入长度超过Flash分区容量检查bin文件大小和分区剩余空间全片擦除失败写保护被使能或RDP级别过高检查Option Bytes用CubeProgrammer解除写完读回数据不对编程电压不稳检查电源纹波尤其电池供电设备最坑的一种情况是Bootloader程序本身就放在Flash里而你在Bootloader运行过程中擦写了一个覆盖当前执行代码的页。比如Bootloader核心函数在0x08000000附近App区起始地址不小心写成了0x08000000结果一执行擦除把Bootloader自己擦没了芯片直接报废。所以划分Flash分区时App起始地址务必远离Bootloader代码段。5.3 中断不响应的排查App启动后别的都正常就是按键中断、串口中断不触发这个现象十有八九还是向量表偏移问题。你可以在App启动早期加断点看SCB-VTOR的值是否等于App地址。如果是0x08000000说明代码没执行到重定位那一行。另一种情况是NVIC没有正确使能中断通道。CubeMX生成的外设初始化代码里有些外设需要在HAL_UART_Init外再手动HAL_NVIC_EnableIRQ。很多人把Bootloader和App的NVIC配置混在一起导致App里明明初始化了外设中断却一直被Masked。排查方法很简单在中断服务函数里打断点看能不能进去进不去就查NVIC寄存器看对应的IRQ是不是使能了。还有一个容易被忽略的问题跳转前Bootloader如果注册了相同中断的服务函数跳过去后该中断在NVIC里可能还保持着使能状态而App注册的中断处理函数是好的但中断标志位已经被Bootloader消费了所以App永远等不到第一次中断触发。这个可以通过在跳转前清所有NVIC pending位来解决严谨一点调用NVIC_ClearPendingIRQ逐个清理。6. 一套能落地的开发流程清单6.1 从0到1的步骤梳理如果你照着前面的思路做我建议按下面这个顺序推进每一步做完都要验证没问题再走下一步避免最后攒一堆错误一起爆发在CubeMX中生成Bootloader工程配置时钟、UART、升级请求GPIO。实现在Bootloader模式下用上位机发送固件通过串口接收并写入指定Flash区。使用烧录器把Bootloader烧写到0x08000000通过串口手动发送一包测试数据确认能够写完Flash并能读回一致。新建App工程修改链接脚本把起始地址改到App分区。在App初始化最前面设置SCB-VTOR编译出bin文件。先用烧录器把App烧到App分区再手动复位测试跳转是否成功。最后通过Bootloader串口走一遍完整升级流程验证上位机发送、接收、写Flash、跳转全链路。加上版本校验、CRC校验、失败回退机制。这个顺序的核心思想是先保证Bootloader自己运行稳定再保证能收到数据最后才联调跳转。很多人一上来就急着把整个IAP流程调通结果串口数据都收不对跳转了也看不出是哪一步出的问题然后陷入无尽的debug。6.2 我最终采用的固件升级流程最终跑顺的流程是这样上电后Bootloader先读参数区的升级标志。如果标志是“无需升级”直接校验App区的有效性校验通过就跳转App如果标志是“有固件待接收”或者有外部升级引脚触发就进入升级模式。在升级模式里上位机发Ymodem起始帧Bootloader收到文件名和大小后开始逐包接收。每包数据CRC32校验通过后写入App区写完一页就擦除下一页。全部收完后Bootloader再把参数区的升级标志改回“无升级”复位并跳转App。如果中途发生超时、CRC错误Bootloader会保留升级标志下次上电继续等而不去跑一个可能半残的App。App侧的逻辑更简单App正常运行过程中收到一条来自串口的升级指令就先把接收到的固件大小写入参数区再把升级标志置为“需要升级”然后软复位。以后哪怕App代码写坏了只要Bootloader还在就能靠串口救回来。6.3 给你的几点忠告第一不要一开始就追求复杂功能。A/B分区、加密签名、断点续传这些东西可以后面再加第一步先把“串口发bin文件芯片写Flash重启运行”这条链路跑通。第二上位机工具也很关键。别小看发送工具很多坑其实出在上位机一次发太快、丢包、顺序错乱。我开发时先用PC端串口调试助手手动发一帧一帧测试确保协议无误后再写自动化脚本。第三文档和版本管理一定要做好。Bootloader和App一般是两个独立工程建议单独建Git仓库每次改动都打Tag。因为Bootloader一旦烧进去后期维护时你很难实地调试只能靠升级App来修复功能。如果Bootloader本身有bug就只能上烧录器这个成本在生产环境中非常尴尬。另外量产烧录时建议先烧Bootloader再通过串口/工具烧App程序。不要把Bootloader和App合成一个hex文件刷进去除非你非常确定两边的地址和中断向量表都处理得当。否则在工厂不小心刷错一次后面排查比前期开发痛苦得多。
