STM32H750内存不够用？我这样用两块W25Q80搞定IAP固件升级（附完整代码）-程序员充电站

STM32H750内存优化实战：双W25Q80实现高效IAP固件升级

面对STM32H750仅有128KB内部Flash的严苛限制，许多嵌入式开发者都在寻找既能保留完整功能又可实现远程升级的解决方案。本文将分享一种经过实战验证的设计方案——利用两块W25Q80 SPI Flash构建三级存储架构，在不牺牲性能的前提下实现可靠的固件升级功能。

1. 理解H750的存储困境与设计思路

STM32H750作为高性能Cortex-M7内核MCU，其128KB的内部Flash对于复杂应用来说确实捉襟见肘。当我们需要实现IAP(In-Application Programming)功能时，传统方案通常会在内部Flash划分出Bootloader和应用程序两个区域，但这会进一步压缩本就不足的可用空间。

我们的创新方案采用了两块W25Q80(每块1MB容量)SPI Flash，通过精心设计的存储架构解决了三大核心问题：

空间分配问题：将Bootloader分为两个阶段(Bootloader1和Bootloader2)，分别存储在不同介质中
写入限制问题：规避QSPI Flash在内存映射模式下的写入限制
可靠性问题：建立多重校验机制确保固件传输和更新的完整性

这种设计的关键优势在于：

保留了内部Flash的最大可用空间给应用程序
利用了SPI Flash的低成本和大容量特性
通过双存储介质实现了升级过程的冗余保护

2. 硬件架构设计与存储分配

2.1 硬件连接方案

我们的硬件连接采用了以下配置：

// W25Q80 #1 (用于存储Bootloader2和APP镜像) // 连接在QSPI接口，支持内存映射模式 #define QSPI_FLASH_CS_PIN GPIO_PIN_6 #define QSPI_FLASH_CS_PORT GPIOB // W25Q80 #2 (用于存储新固件包) // 连接在普通SPI接口 #define SPI_FLASH_CS_PIN GPIO_PIN_12 #define SPI_FLASH_CS_PORT GPIOD

2.2 存储空间分配策略

存储介质	分配内容	大小	访问方式
内部Flash	Bootloader1	64KB	直接执行
QSPI Flash	Bootloader2 + APP镜像	896KB	内存映射/直接读取
SPI Flash	新固件包	1MB	SPI接口读写

这种分配方式确保了：

Bootloader1足够精简，仅保留最基本的硬件初始化和跳转功能
Bootloader2包含完整的升级逻辑，可访问全部外设
APP镜像可以获得最大的连续存储空间

3. 三级Bootloader实现细节

3.1 Bootloader1的设计要点

Bootloader1作为整个系统的第一级引导，需要保持极简设计。其主要功能包括：

基础硬件初始化(时钟、GPIO、中断)
检查升级标志位
决定跳转到Bootloader2或执行APP
提供紧急恢复机制

关键代码片段：

void jump_to_app(uint32_t app_addr) { typedef void (*pFunction)(void); pFunction app_entry; app_entry = (pFunction)(*(__IO uint32_t*)(app_addr + 4)); __set_MSP(*(__IO uint32_t*)app_addr); app_entry(); }

3.2 Bootloader2的核心功能

Bootloader2存储在QSPI Flash中，通过Bootloader1加载到RAM执行。其主要职责包括：

固件验证：检查新固件的CRC32和版本号
数据搬运：将新固件从SPI Flash复制到QSPI Flash
状态管理：更新引导标志位和版本信息
错误处理：提供升级失败的回滚机制

注意：由于QSPI Flash在内存映射模式下不能直接写入，我们需要在RAM中建立缓冲区，通过间接方式完成写入操作。

3.3 固件更新流程实现

完整的固件更新流程可分为以下几个阶段：

准备阶段：
- 接收新固件包并存储到SPI Flash
- 设置升级标志位
- 重启进入Bootloader1
验证阶段：
- Bootloader2读取SPI Flash中的固件头信息
- 校验签名、CRC和硬件兼容性
传输阶段：
- 分块读取SPI Flash数据
- 写入QSPI Flash目标位置
- 每块写入后验证数据一致性
完成阶段：
- 更新版本信息
- 清除升级标志位
- 跳转到新APP

4. 关键问题解决方案与优化技巧

4.1 解决QSPI写入限制的三种方法

由于QSPI Flash在内存映射模式下无法直接写入，我们测试了三种可行方案：

RAM缓冲法：

void qspi_write(uint32_t addr, uint8_t *data, uint32_t len) { uint8_t buffer[256]; memcpy(buffer, data, len); HAL_QSPI_Write(&hqspi, addr, buffer, len); }

临时退出内存映射模式：
- 写入前禁用内存映射
- 执行写入操作
- 重新启用内存映射
双Bank切换法：
- 利用W25Q80的Bank切换功能
- 在一个Bank保持内存映射的同时写入另一个Bank

经过实测，RAM缓冲法在稳定性和性能上表现最佳，推荐使用。

4.2 提升传输可靠性的措施

为确保固件传输过程万无一失，我们实施了多重保护机制：

分块校验：每4KB数据计算一次CRC32
回滚标记：在开始更新前设置"更新中"标志
双备份存储：保留上一个可用版本
超时监控：防止意外死锁

4.3 性能优化实践

通过以下优化手段，我们将固件更新速度提升了3倍：

SPI时钟优化：

hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_2; // 提升到最高支持频率

双缓冲传输：

// 使用DMA双缓冲模式 HAL_SPI_Transmit_DMA(&hspi1, buffer1, BUFFER_SIZE); // 在DMA传输buffer1的同时准备buffer2

并行操作：
- 在SPI传输数据的同时计算CRC
- 重叠执行擦除和写入操作

5. 实际应用中的经验分享

在多个量产项目中应用此方案后，我们总结出以下几点实战经验：

电源稳定性至关重要：在升级过程中突然断电是最大的风险点。建议：
- 添加大容量储能电容(至少1000μF)
- 实现软件断电检测机制
- 关键操作立即刷新Flash
调试信息输出策略：在资源受限环境下，我们采用：
- 通过SWO输出精简日志
- 使用LED编码显示状态(如快闪表示擦除中)
- 保留最后错误码在备份寄存器

兼容性设计技巧：

// 固件头结构体设计示例 typedef struct { uint32_t magic; // 固定标识 0xAA55BB66 uint16_t hw_version; // 兼容硬件版本 uint32_t crc; // 整个固件的CRC32 uint32_t timestamp; // 构建时间戳 uint32_t size; // 固件实际大小 } firmware_header_t;