通过QSPI协议实现多片Flash级联的解决方案

多Flash共享QSPI总线？一文搞懂级联设计的坑与解法

你有没有遇到过这种情况：项目做到一半，发现外部Flash容量不够用了。换更大容量的芯片吧，价格翻倍；加第二片Flash吧，MCU引脚又捉襟见肘。

别急——QSPI多片级联就是为这种困境量身打造的方案。

它不是什么黑科技，但却是很多中高端嵌入式系统里“低调却关键”的一环。今天我们就从实战角度出发，拆解这个在工业HMI、车载仪表、智能音箱里广泛使用的技术：如何用一组QSPI信号线，轻松驱动两片甚至更多Flash，并实现大容量XIP执行和高效数据存储。

为什么标准SPI扛不住了？

先说个现实：如果你还在用传统SPI接口挂载Flash，那基本已经掉队了。

比如一片W25Q128JV，最大读速也就80Mbps，实际连续读取时延高达几十微秒。跑RTOS还行，但如果要直接从Flash运行复杂固件（也就是XIP），或者加载高清GUI资源，体验会非常卡顿。

而现代MCU如STM32H7、GD32F4xx、NXP i.MX RT系列都集成了硬件QSPI控制器，支持四线传输、DMA预取、AHB映射，理论带宽一下子冲到320Mbps以上。这才是高性能系统的标配。

✅ 关键区别在哪？
标准SPI只用MOSI/MISO两条数据线；
QSPI在Quad模式下使用IO0~IO3四条双向线，相当于把单车道变四车道。

更妙的是，QSPI不仅能提速，还能通过多片级联解决容量瓶颈。我们不需要额外增加数据引脚，只要多出几个片选（CS）就行。

多片Flash怎么接？物理连接的核心逻辑

最常见的做法是：共用CLK和IO0~IO3，每片Flash独占一个CS引脚。

来看一个典型连接图：

MCU │ ├── QSPI_CLK ────────┐ ├── QSPI_IO0 ────────┼───→ Flash #1 & Flash #2 （并联） ├── QSPI_IO1 ────────┤ ├── QSPI_IO2 ────────┤ ├── QSPI_IO3 ────────┘ ├── QSPI_CS0 ────────→ /CS of Flash #1 └── QSPI_CS1 ────────→ /CS of Flash #2

就这么简单？没错。所有通信都走同一组信号线，靠片选来“点名”谁响应。

举个比喻：这就像老师上课提问，全班同学都坐在教室里（共享总线），但只有被叫到名字的学生才会站起来回答问题（拉低CS），其他人保持沉默（高阻态）。

⚠️ 必须注意的硬规则

任何时候只能有一个CS有效，否则总线冲突，轻则读错数据，重则烧毁IO；
所有Flash的供电最好独立去耦，每个VCC旁放一个0.1μF陶瓷电容；
高频系统（>80MHz）要注意布线等长，尤其是CLK与IO之间的长度差控制在500mil以内；
IO线上建议加10kΩ~100kΩ弱上拉，防止空闲时悬空干扰。

这些细节看着不起眼，但在EMC测试或低温环境下可能直接决定产品能否稳定工作。

软件怎么管？地址映射才是灵魂

硬件接好了只是第一步。真正的难点在于：软件如何让多片Flash看起来像一块连续的大存储？

答案是——虚拟地址映射 + 分区管理。

假设你有两片32MB的Flash：
- Flash A 接在 CS0，起始物理地址 0x0000_0000
- Flash B 接在 CS1，起始物理地址 0x0000_0000

虽然它们“各自为政”，但我们可以在软件层面给它们分配不同的虚拟地址空间：

// 定义分区表 flash_partition_t g_partitions[] = { { .base_addr = 0x90000000, .size = 0x2000000, .cs_pin = 0 }, // 32MB → Flash A { .base_addr = 0x92000000, .size = 0x2000000, .cs_pin = 1 } // 32MB → Flash B };

这样一来，应用程序只需要知道“我要访问0x9100_0000”这个地址，底层驱动自动判断它属于哪一片Flash，切换CS，再发起操作。

是不是有点像内存管理单元（MMU）的感觉？虽然没那么高级，但原理相通：把分散的物理资源抽象成统一的逻辑视图。

如何实现地址路由？

写个简单的查找函数即可：

int find_flash_by_address(uint32_t addr, flash_partition_t **part) { for (int i = 0; i < ARRAY_SIZE(g_partitions); i++) { uint32_t start = g_partitions[i].base_addr; uint32_t end = start + g_partitions[i].size; if (addr >= start && addr < end) { *part = &g_partitions[i]; return i; // 返回设备索引 } } return -1; // 地址无效 }

有了这个机制，上层文件系统（比如LittleFS或FAT）、固件更新模块、日志服务都可以无视底层有多少片Flash，专心做自己的事。

实战技巧：JEDEC ID探测与兼容性处理

不同厂家的Flash命令集略有差异。比如Winbond和Micron对“使能写操作”的指令都是0x06，没问题；但某些特殊功能寄存器的操作码就不一定一致了。

所以强烈建议在初始化阶段做一件事：读取每片Flash的JEDEC ID。

uint32_t read_jedec_id(uint8_t cs_pin) { uint8_t cmd = 0x9F; uint8_t rx_buf[3]; qspi_select_device(cs_pin); qspi_send_command(&cmd, 1); qspi_receive_data(rx_buf, 3); qspi_deselect_device(cs_pin); return (rx_buf[0] << 16) | (rx_buf[1] << 8) | rx_buf[2]; }

返回值形如0xEF4019（Winbond W25Q256）或0xC22019（MXIC MX25L256），你可以根据ID动态匹配对应的驱动参数，比如：
- 是否支持QPI模式
- 四字节地址启用方式（0xB7or0xE9）
- 扇区/块大小
- 写保护配置方法

这样哪怕后期换了Flash型号，也不用改代码重新编译，真正实现“即插即认”。

大容量固件也能XIP？关键在这里

很多人误以为XIP只能用于小容量启动代码。其实不然。

只要你有足够的QSPI带宽 + 合理的缓存策略，完全可以把整个RTOS镜像放在Flash里直接执行。

以i.MX RT1050为例，它的SEMC/QSPI模块支持将外部Flash映射到AHB总线空间（例如0x6000_0000起）。CPU取指就跟访问内部Flash一样自然。

配合以下优化手段，性能完全可用：
- 开启指令预取缓冲区（Prefetch Buffer）
- 设置合适的Dummy Cycles（一般8~12个时钟周期）
- 使用快速读指令（如0xEB，双倍速率DDR模式）
- 对热点函数进行RAM缓存（critical function copy to RAM）

我们在某款医疗设备中就实现了超过8MB的FreeRTOS + GUI框架全程XIP运行，SRAM仅用于动态变量和堆栈，大大缓解了内存压力。

FOTA升级怎么做才安全？

说到多片Flash的优势，最实用的一点就是——天然适合A/B分区冗余设计。

设想这样一个流程：
1. 当前运行固件在 Flash A（Active区）
2. 新版本下载到 Flash B 的备用区
3. 校验无误后标记“待激活”
4. 下次重启时，Bootloader检测标志位，切换执行源

万一新固件崩溃，下次还能自动回滚到旧版本。这对工业设备、车载系统来说至关重要。

而且因为两片Flash可以混用不同品牌（只要软件适配），你还具备供应链备份能力。某家缺货？换另一家照样跑。

常见坑点与避坑指南

问题现象	可能原因	解决方案
读出的数据全是0xFF或0x00	片选未正确拉低 / Flash未唤醒	检查CS电平、确认退出深度掉电模式
写入失败但不报错	未发送写使能命令（WREN）	每次编程前必须发`0x06`
超过128MB无法访问	未启用四字节地址模式	发送`0xB7`命令切换至4-byte mode
总线竞争导致死机	多个CS同时有效	在驱动层加互斥锁或状态机
图形加载卡顿	使用标准SPI读而非Quad Read	改用`0xEB`指令 + 正确配置Dummy Cycle