STM32H750 Bootloader与QSPI Flash应用升级方案解析

简介：面向STM32H750VBT6微控制器开发者，这份ZERO开发板完整工程源码围绕Bootloader、应用程序与下载算法三大核心模块展开，解决无硬件编程器场景下的固件引导、更新与恢复问题。压缩包共2000个文件、约152.7MB，以C语言为主（876个.h头文件与834个.c源文件），另含188个HTML文档、29个Python脚本、11个PDF手册、8个Shell脚本等，分别对应驱动定义、程序逻辑、网页说明、自动化辅助与编译部署。已有247人学习下载。项目中的Bootloader注重启动速度、内存占用与固件校验，并支持通过通信协议完成升级；下载算法涵盖传输、校验、写入及异常容错；应用程序源码提供可扩展的框架，并涉及TCP/IP协议栈与FatFs文件系统，便于二次开发实时数据处理或网络通信功能。附带的文档与图片辅助理解硬件特性与软件架构，适合希望深入STM32平台开发与固件设计的中初级工程师。

1. 基于 STM32H750VBT6 的 ZERO 开发板：128KB 片内 Flash 撑不起应用，Bootloader 成了必选项

STM32H750VBT6 这颗芯片主频能拉到 480MHz，算力和外设都够猛，偏偏片内 Flash 只给了 128KB。跑个带 GUI、带文件系统、带算法库的固件，工程稍微一膨胀就放不下，更别提远程升级了。ZERO 开发板这套方案的思路很直接：Bootloader 留在片内 Flash，应用程序放到外挂 QSPI Flash 里，再配一个下载算法（FLM）让 Keil、J-Flash 这样的工具直接往外部 Flash 写固件。我这次拆的就是这套 Bootloader、应用程序与下载算法设计源码，它解决的核心问题就三个：代码放哪、怎么跳过去、怎么烧进去。适合正在做 H7 系列 IAP 升级、研究外部 Flash 启动，或者被 128KB 容量卡住的开发者，照着分区表和跳转流程改改就能用。

2. 启动链路与内存映射：为什么 Bootloader 留在片内，APP 必须住在 QSPI

2.1 H750 的地址布局：片内 128KB 与外部 QSPI 的坐标

先看地址，这是整篇文章的地基。STM32H750VBT6 的片内 Flash 起始地址是0x0800_0000，大小 128KB，SRAM 倒是给得很足，有 1MB 左右，但 Flash 是硬约束。ZERO 开发板在外挂了一颗 SPI NOR Flash（常见的是 W25Q256 这类 8～32MB 的型号），挂在芯片的 QUADSPI 外设上，复用0x9000_0000起始的 memory-mapped 地址空间。只要 QUADSPI 配置成 memory-mapped 模式，CPU 就能像读片内 Flash 一样直接从这个地址取指执行，这就是所谓的 XIP（Execute in Place）。

为什么要这样编排？因为 Bootloader 本身要承担最基础的启动职责，它必须放在上电就能跑的地方，片内 128KB 完全够用；而应用程序动不动几百 KB，只能放到外部 Flash。这套源码把片内 Flash 前半段留给 Bootloader，剩余空间放升级参数和临时缓冲，APP 统一从0x9000_0000启动，分区规划我整理成了下面这张表：

分区表本身是源码里最常见也最容易被忽略的部分。我一般会要求每个分区头放一个魔数（Magic Number），比如0xA5A5A5A5，启动时先判魔数再看 CRC，防止半包数据被当固件跑起来。大小建议写死在头文件里，不要运行时去探测 Flash 容量，省得把 W25Q128 和 W25Q256 混用的时候算出错误边界。

2.2 上电后的完整启动链：从 0x08000000 到 0x90000000

整条启动链是这样的：芯片复位后，内核从0x0800_0000取向量表和第一条指令，Bootloader 先做时钟初始化、QSPI 引脚复用配置、把外挂 Flash 读出来做校验；校验通过，把向量表搬到0x9000_0000，把主栈指针设成 APP 的栈顶值，然后跳过去；APP 的Reset_Handler接管后续的 SystemInit 和 main。

这里的核心矛盾是：Bootloader 里对 QSPI 的初始化配置，和 APP 里面对的 Flash 必须是同一个状态。很多人的 APP 里又写了一份独立的 QSPI 初始化，结果跳转之后 QSPI 外设被重新复位，memory-mapped 模式被关掉，CPU 第一条取指就死在0x9000_0000。稳妥的做法是：跳转前把 QUADSPI 外设的时钟、GPIO、CR/AR/DLR 寄存器保持原状，APP 侧如果确实需要重新初始化，先读出来比对参数，相同就直接跳过初始化流程。

还有一点，H750 的 QSPI 支持双 Flash 模式，ZERO 板上只挂一颗，用普通模式下BK2的问题不会碰到，但如果你的板子用了两片 Flash 组 8 线模式的，Bootloader 的分区计算就要按两块 Flash 的总容量算，这个是很容易被忽略的差别。我拆这套源码的时候特别留意了它的 QSPI 初始化函数，里面把 FCCR（Flash Configuration Control Register）的指令、地址、模式字节都配进了FLASH_CMD，这套参数决定了 memory-mapped 模式下每条读指令长什么样，后面讲 FLM 的时候还会再提到。

3. Bootloader 实现：分区表、YMODEM 接收与两级跳转的关键代码

3.1 分区表结构体与 CRC 校验：先写好引导的「契约」

Bootloader 要判断外部 Flash 里有没有合法的 APP，不能靠猜，要靠头部信息。源码里定义了一个简单的分区头结构体，放在 APP 区的最前面，Bootloader 读出来逐字段校验。核心代码可以抽象成下面这样：

#define MAGIC_APP 0xA5A5A5A5 #define APP_ADDR 0x90000000UL typedef struct { uint32_t magic; /* 魔数，固定 0xA5A5A5A5 */ uint32_t app_size; /* 固件实际字节数 */ uint32_t crc32; /* 对整个固件算出的 CRC32 */ uint32_t version; /* 版本号，自增，用于回滚判断 */ uint32_t reserved[3]; /* 预留，便于以后扩展 */ } app_header_t; static uint32_t calc_crc32(const uint8_t *buf, uint32_t len) { /* 用 ST 提供的 CRC32 外设或软件查表法实现，此处略去查表内容 */ uint32_t crc = 0xFFFFFFFF; for (uint32_t i = 0; i < len; i++) { crc ^= buf[i]; for (int b = 0; b < 8; b++) { crc = (crc >> 1) ^ (0xEDB88320UL & (~((crc & 1) - 1))); } } return ~crc; } int check_app_header(void) { app_header_t *hdr = (app_header_t *)APP_ADDR; if (hdr->magic != MAGIC_APP) { return -1; /* 没有有效固件 */ } if (hdr->app_size == 0 || hdr->app_size > (32UL * 1024 * 1024)) { return -2; /* 大小非法 */ } uint32_t crc = calc_crc32((const uint8_t *)(APP_ADDR + sizeof(app_header_t)), hdr->app_size); return (crc == hdr->crc32) ? 0 : -3; }

这段代码解决了「有没有 APP、APP 完不完整」两个问题。APP_ADDR直接定义为0x9000_0000，是因为这个地址在 memory-mapped 模式下是直接可读的，hdr->magic读出来的就是外部 Flash 第一个扇区开头的 4 字节，不需要先调用任何 QSPI 读写函数。CRC32 用软件查表或者 H7 自带的硬件 CRC32 都行，注意硬件 CRC 在 H7 上喂进去的多项式和软件算的要一致，否则两边数值永远对不上——这是我在项目里踩过的坑之一，后面避坑章里细说。reserved[3]看着多余，实际很有用，以后想加签名校验、加发布时间戳都不用改分区结构，直接占位。

3.2 YMODEM 接收流程：分包、CRC16-CCITT 与超时重传

Bootloader 的升级通道用的是串口加 YMODEM 协议，这是老协议但生命力极强，几乎所有的串口终端工具（SecureCRT、MobaXterm、Xshell）都原生支持，不需要额外写上位机。YMODEM 的核心机制是「发C等待、收数据块、回 ACK、收 EOT、收结束包」，每包 128 字节（SOH）或 1024 字节（STX），块号从 1 开始，校验用 CRC16-CCITT（多项式0x1021，初值0x0000）。

接收侧的主循环骨架长这样：

#define PKT_128 128 #define PKT_1024 1024 #define MAX_RETRY 5 static int ymodem_receive(uint32_t dst_addr, uint32_t max_size) { uint8_t buf[1028]; /* 包头 + 数据 + CRC，容纳最大包 */ int block = 1; int expecting_data = 0; /* 是否已收到开始帧 */ uart_send_byte('C'); /* 先发 C 通知发送方开始 */ while (1) { int len = uart_recv_line(buf, sizeof(buf), 3000); /* 3 秒超时 */ if (len < 0) { if (--retry_count <= 0) return -1; /* 连续超时，放弃 */ uart_send_byte('C'); /* 再次邀请 */ continue; } uint8_t type = buf[0]; if (type == 'C' && !expecting_data) { /* 发送方也在等我们 */ uart_send_byte('C'); continue; } if (type == 0x01 || type == 0x02) { /* SOH 128B / STX 1024B */ uint8_t pkt_no = buf[1]; uint8_t pkt_no_inv = buf[2]; if ((pkt_no ^ pkt_no_inv) != 0xFF) { uart_send_byte(NAK); /* 块号取反校验失败 */ continue; } uint16_t crc_rx = (buf[len-2] << 8) | buf[len-1]; uint16_t crc_calc = crc16_ccitt(&buf[3], len - 5); if (crc_rx != crc_calc) { uart_send_byte(NAK); /* 数据坏了，重传 */ continue; } if (pkt_no == block) { /* 校验通过，写入外部 Flash 对应偏移 */ qspi_write(dst_addr + (block-1)*data_len, &buf[3], data_len); uart_send_byte(ACK); block++; } else { uart_send_byte(ACK); /* 重复包，回 ACK 跳过 */ } } else if (type == 0x04) { /* EOT */ if (expecting_data == 1) { /* 第一次 EOT */ uart_send_byte(ACK); expecting_data = 2; } else { uart_send_byte(ACK); /* 第二次 EOT 直接放行 */ return 0; } } else if (type == 0x00) { /* 结束空包 */ uart_send_byte(ACK); return 0; } } }

几个参数值得说清楚。uart_recv_line的 3 秒超时是针对「发完一包后对方没有回应」的等待，如果发C之后 3 秒没收到任何字节就重发C，最多重试 5 次；而真正收数据包的时候，TCP 类工具一般会连续发送，所以这里的超时不会误伤正常传输。block++是在数据写入成功之后才自增的，如果写 Flash 失败回 NAK，发送方会重发同一块号，不会造成数据错位。expecting_data这个状态机变量的作用是区分「文件开始前的协商」和「文件传完后的 EOT」，漏掉它很容易在收完数据包后把第一次 EOT 当成异常丢弃。

3.3 跳转函数：关中断、搬向量表、设栈顶，一个都不能少

下载完成、校验通过之后，Bootloader 最后要做的事情是跳转。跳转函数是整个引导流程里最敏感的一小段代码，每一步都有讲究，标准写法如下：

typedef void (*pFunction)(void); static void jump_to_app(uint32_t app_addr) { uint32_t stack_addr = *(volatile uint32_t *)app_addr; /* 1. 取 APP 栈顶 */ uint32_t reset_addr = *(volatile uint32_t *)(app_addr + 4); /* 2. 取 Reset_Handler */ if ((stack_addr & 0xFF000000) != 0x20000000 && (stack_addr & 0xFF000000) != 0x24000000) { return; /* 栈顶不在 RAM 区，说明地址不是合法 APP 入口 */ } __disable_irq(); /* 关掉全局中断，防止跳到一半被打断 */ SCB->VTOR = app_addr; /* 向量表搬到 APP 的起始地址 */ __set_MSP(stack_addr); /* 重新设置主栈指针 */ /* 可以在这里把 SysTick、DMA 等外设中断全部清掉 */ pFunction jump = (pFunction)reset_addr; jump(); /* 跳过去，不再回来 */ }

尾部再解释两个细节：栈顶合法性检查。stack_addr & 0xFF000000等于0x20000000（DTCM）或0x24000000（AXI SRAM）基本可以断定这是编译器生成的栈顶，而不是 Flash 里的乱数，这是防止「没烧固件硬跳」的最后一道闸。SCB->VTOR = app_addr必须在设置 MSP 之前做，而且在 H7 上向量表地址要按足够粒度对齐，我习惯统一按 1KB 对齐，因为有些编译器生成的向量表带__attribute__((section(".isr_vector")))，实际大小可能超过 512 字节，按 1KB 最稳。跳之前最好把 SysTick 的计数中断关掉，否则跳到 APP 后SystemInit还没跑完，SysTick 先响了，Handler 表还没准备好，直接进 HardFault。

4. 下载算法与应用程序配置：FLM 让 Keil 认识 QSPI，APP 认对中断入口

4.1 FLM 下载算法：擦除、页编程为什么必须搬到 RAM 里执行

Bootloader 解决了运行时的升级问题，但开发阶段每次烧固件都要先烧一个 Bootloader 再通过串口传，太折磨人。所以这套源码里还带了一个下载算法（Flash Loader，FLM），它的作用是把外部 QSPI Flash 伪装成一颗「片内 Flash」给 Keil / J-Flash / STM32CubeProgrammer 认识。下载算法本质是一个被调试器加载进目标板 RAM 的小程序，调试器调用它来完成擦除、编程、校验，下表是 FLM 里必须实现的几个函数：

FLM 最核心的玄学点是：ProgramPage 和 EraseSector 必须用__ramfunc声明放到 RAM 里执行。因为这个下载算法本身也是被调试器加载进 RAM 的，但很多人的工程把代码放在 Flash 里编译，调试器把 FLM 塞进 RAM 后运行是没问题的；可一旦要擦写外部 QSPI Flash，如果 Flash 驱动的代码还留在 Flash 里执行，擦写过程中 Flash 忙、CPU 根本没法从这个 Flash 取指。外部 QSPI Flash 本来就无法支撑擦写期间的读操作，这个矛盾在 FLM 场景下会被放大成「Keil 报 Erase failed，目标板跑飞」。我见过不止一个人在这上面耗了一整天，最后把函数加上__attribute__((section(".ramfunc")))就全好了。

ProgramPage 的核心逻辑其实就几步：发写使能指令（0x06）、发页编程指令（0x02）带 24 或 32 位地址、随后跟数据、然后不停读状态寄存器（0x05）的 BIT0 等 Busy 位清零。外部 SPI NOR 的页大小通常 256 字节，如果 FLM 的 ProgramPage 被请求写 1KB，循环内部要连续做 4 次「写使能 + 页编程 + 等忙」，每次之间必须等前一次完全落盘，中间掉一步，写进去的数据就是花的，校验必挂。

4.2 APP 侧分散加载与中断向量表：地址改一处，全盘皆活

有了 FLM 之后，Keil 可以直接把 APP 烧到0x9000_0000，但 APP 工程本身也要相应改动，否则烧进去也跑不起来。第一处是链接脚本。用 GCC 的话，stm32h750xx_flash.ld的 MEMORY 段要改成这样：

MEMORY { FLASH (rx) : ORIGIN = 0x90000000, LENGTH = 0x2000000 /* 外部 32MB QSPI Flash */ RAM (rwx) : ORIGIN = 0x24000000, LENGTH = 0x80000 /* AXI SRAM 512KB */ }

Keil 工程则是在 Target 对话框里把IROM1的起始地址填0x90000000，大小按外部 Flash 容量填。改完链接脚本，代码里还要把中断向量表挪过去。H750 的启动文件默认从0x08000000开始放向量表，APP 跑在外部 Flash，必须在main之前就把 VTOR 设置好，最干净的写法是放在SystemInit之后、main开始处：

/* main.c 最开头 */ SCB->VTOR = 0x90000000UL;

有人会问：Bootloader 跳转前已经设过一次了，APP 里还设一次是不是多余？不多余。因为你没法保证 Bootloader 永远存在，把 VTOR 写死在 APP 自己的启动路径里，这个 APP 拿掉 Bootloader 单独烧到外部 Flash 也能跑，这是更健壮的工程习惯。编译产物也要注意，生成的 bin 文件默认从地址 0 开始，如果直接把 Keil 生成的.axf转 bin，头部的偏移会错位，我一般用这条命令拉出干净的可烧写文件：

fromelf --bin --output app.bin build/stm32h750_app.axf

得到的app.bin才是真正包含向量表、从0x90000000开始的完整镜像。用 QSPI Flash 做 XIP 还需要在启动代码里把 MPU 配置一下，H7 上若不配 MPU，从0x90000000取指的速度和稳定性都会差一些，源码里在SystemInit里做了一次 MPU 配置，把0x90000000区域设为 Normal、Non-cacheable，这一步建议保留，不要为了省事删掉。

5. 避坑与常见问题排查：VTOR 没设、FLM 超时、升级翻车的五条记录

5.1 现象：跳转后第一句就 HardFault，连 main 都进不去

原因：跳转前 QSPI 外设被 Bootloader 复位了，或者 memory-mapped 模式被显式关闭。不少人会在跳转函数里顺手调用QSPI_DeInit()或者关了 QUADSPI 时钟，想「省电」，结果 CPU 跳到0x90000000取指时，外设时钟已经停了，地址总线上读回来全是0xFF，第一条指令就非法。

解决：跳转前不要动 QUADSPI 的时钟使能、CR 和 DLR 寄存器。如果确实需要重新配置，就在跳到 APP 之前把配置留在寄存器里，APP 侧启动时先读状态，发现已经是 memory-mapped 模式就直接跳过初始化。另外跳转函数里__disable_irq()之后不要再调用任何依赖中断的函数（比如 printf、HAL_Delay），关中断状态下这些函数会卡死或把中断标志搞乱。

5.2 现象：Keil 烧录时卡在 Erase/Program，然后报 Cannot access target

原因：FLM 里的擦写函数没有放进 RAM 执行，代码本身在 Flash 里跑，擦写期间 Flash 忙、读不了指令，调试器跟目标板的连接直接断掉。还有一种常见情况是 ST-Link / J-Link 的时钟频率设得太高，比如 ST-Link 默认的 4MHz 对片内 Flash 没问题，但连到外部 QSPI 链路较长时容易握手失败。

解决：把EraseSector、ProgramPage、Verify全部用__ramfunc放到 RAM 段。调试器频率降到 1MHz 试一次，能稳定下载再逐步往上加。这个坑的特异性很强——片内 Flash 工程怎么编译都不会暴露，一换到外部 QSPI 就原形毕露。

5.3 现象：串口 YMODEM 传输到一半，收发双方疯狂 NAK，一包数据重传七八次

原因：CRC16 的算法不一致。YMODEM 用的是 CRC16-CCITT，多项式0x1021，初始值0x0000，而很多人从网上抄的 CRC16 代码是 Modbus 变体（初始值0xFFFF），两边算出来的校验码永远对不上。另外接收缓冲只留了 128 字节，发方用 1024 字节的 STX 包时直接截断。

解决：先确认收发两端都用 CRC16-CCITT（0x1021/ init0x0000），再用串口助手抓一包实际数据，把第 3 字节开始直到末尾的 CRC 字段手动算一遍对比。接收缓冲按1028字节开，既容得下 STX 包也容得下 CRC 字段，别用 128 字节的数组接 1024 的包。

5.4 现象：APP 能进 main，但任何一个中断触发就死机或复位

原因：VTOR 没有设置，或者设置成了0x90000000 + 4这种错位地址。中断向量表必须整体从一个 4 字节对齐的基地址开始，一旦错位，中断一来 CPU 去错位的地方取向量，取回来的是某个指令的中间字节，直接 HardFault。

解决：在 APP 的SystemInit里无条件执行SCB->VTOR = 0x90000000UL;，并且确认这个赋值在第一个外设中断使能之前完成。调试时可以在 HardFault_Handler 里打断点，看SCB->VTOR的实际值和*((uint32_t *)SCB->VTOR)读出来的是不是0x08000000开头的栈顶指针，一对比就定位了。

5.5 现象：固件烧到 W25Q256 的高地址区域，读回来全是 0xFF，低 16MB 正常

原因：W25Q256 容量 32MB，超过了 24 位地址能寻址的 16MB 上限。芯片上电默认在 3 字节地址模式，访问高 16MB 需要先发0xB7进入 4 字节地址模式，或者每次访问都用带 4 字节地址的指令。Bootloader、FLM、APP 三处的 QSPI 驱动如果只有一处切了 4 字节模式，另外两处在高位区域就会读出全 0xFF。

解决：统一在三套代码的 QSPI 初始化里都进入 4 字节地址模式（发0xB7并置位 QSPI 控制器的地址宽度位），或者反过来统一用「3 字节地址 + 高位区域只当备份用」的策略。最稳妥的是读 JEDEC ID 判断容量，大于 16MB 就强制开 4 字节模式。这个坑在 ZERO 开发板这种板载 32MB Flash 的场景里几乎必踩，尤其是移植别人 16MB Flash 工程的代码时。

6. 从「能烧进去」到「敢量产」：回滚保护与 QSPI 时序验证

6.1 双分区与失败回滚：升级断电不再变砖

能烧进去只是第一步，真正的考验是升级到一半断电。我在这套源码上做的第一处改造就是加了备份区：外部 Flash 分成 A、B 两个分区，Bootloader 总是从 A 区启动，升级时先把新固件整体写入 B 区，写完后校验 CRC，通过则把版本号写进参数区并切换启动标志，再复位；如果 B 区校验失败，启动标志不变，Bootloader 继续从 A 区引导，旧固件毫发无损。这个方案的代价是外部 Flash 可用空间减半，但对于量产设备来说，这个代价远比售后跑去现场刷机低得多。

切换逻辑并不复杂：参数区里存一个uint32_t boot_slot，值为0xA0000001时从 A 启动，0xB0000001时从 B 启动，每次复位后 Bootloader 先读这个值，再配合 CRC 判断对应的分区是否完整。注意写参数区的时候要先擦后写，并且把关键标志写两遍，防止半字写入时掉电产生脏数据。

6.2 QSPI 时序验证：别信算出来的，要看抓出来的

QSPI 时序是我做过的项目里最容易「看着能跑、实际有隐患」的部分。W25Q256 标称支持 133MHz，但实际布线、上拉电阻、Flash 批次都会影响极限频率。我通常先按 50MHz 定 QSPI 时钟，跑一轮完整的「擦除 + 写入 + 读回 + 校验」，再用逻辑分析仪抓 CS、CLK、IO0–IO3 四根线，确认读指令的命令字节、等待周期（dummy cycles）和模式字节（mode bytes）跟芯片数据手册一一对应。等稳定跑 100 轮压力测试之后，才敢提到 100MHz 以上。

6.3 验证清单：每次烧录前强制走一遍

从那以后，我每次切换 Bootloader 或 QSPI 驱动代码，都强制走一遍五步验证：读 JEDEC ID 确认芯片型号、整片擦除后全地址读回为0xFF、写 0x5A5A 模式到高 16MB 地址再接回读取、跑 CRC 校验、最后断电重启确认跳转稳定。这套流程看着笨，但每个环节都对应一个具体的翻车现场。希望这套基于 STM32H750VBT6 的 ZERO 开发板 Bootloader、应用程序与下载算法源码能帮你少走几步弯路，愿你一次点亮，量产不翻车。

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