简介：本资源是一套面向嵌入式开发工程师与STM32进阶学习者的实战型实验例程，聚焦STM32H743IIT6单片机通过QSPI接口高速读取W25Q64闪存芯片，并深度集成MDMA实现零CPU干预的数据搬运。解决高性能外置Flash访问中带宽瓶颈与实时性不足的典型痛点，适用于Bootloader升级、固件热加载、日志缓存等工业与IoT场景。压缩包共95个文件，含55个头文件（.h）定义外设寄存器与配置宏、28个源文件（.c）覆盖QSPI初始化、MDMA通道配置、命令序列控制及中断服务逻辑，另含Keil工程文件（.uvprojx/.uvoptx）、启动脚本（.s）、调试配置（.dbgconf）及构建辅助脚本（.bat），结构完整、开箱即用。资源包大小为954KB，目录层级清晰，含标准HAL驱动、CMSIS核心支持与RTE组件，便于理解H7系列外设协同机制。目前已有569人学习下载，提供可直接编译运行的完整工程，附带关键注释与错误处理范式，助开发者快速掌握QSPI+MDMA高效率数据通路的设计与调试方法。 搞嵌入式这几年，我越来越觉得一句话特别真实：MCU 算力再强，没有一块像样的外部存储，应用就永远只能在“够用”和“将就”之间徘徊。最近我在 STM32H743IIT6 上整理了一套基于 QSPI 接口 W25Q64 的读取工程，顺手把 MDMA 通道也加进去了，核心就是把外设数据用 MDMA 搬进内存，CPU 几乎不参与。这个组合在 H7 上非常典型，适合做 GUI 图库映射、OTA 升级缓存、日志转存这类场景。
资料里带的是完整实验例程源码，但如果你只拿源码去烧录，而不理解背后的 QSPI 时序、W25Q64 指令体系、MDMA 请求映射，那大概率改不了几个参数就会卡住。所以这篇我打算从标题里的四个关键词展开，把 H743 上 QSPI 和 W25Q64 的底层原理、MDMA 联动方式、例程代码怎么搭、以及我在实测中踩过的坑一次说清楚。
1. 这套组合要解决什么问题：H743 上的高速外部 Flash 读取方案
1.1 为什么是 QSPI，而不是普通 SPI 或 SDIO
STM32H743IIT6 这颗料，Cortex-M7 内核跑到 480MHz，板载 2MB Flash、1MB RAM，资源在 MCU 里算非常豪华。但遇到两种情况，内部 Flash 还是不够用：一是装 GUI 用的图片素材和字库，随便一套稍有规模的中文字库就是几 MB；二是做产品日志或者固件升级缓存，需要大块连续可擦写的存储空间。
过去很多人用普通 4 线 SPI 接外部 flash，比如 W25Q64 的标准 SPI 模式，但普通 SPI 只有一根数据输出线，即使跑满 80MHz，每字节还是要 8 个时钟周期。QSPI 模式下，W25Q64 可以四根数据线同时输出，同样的时钟频率，理论吞吐量直接翻四倍。虽然 W25Q64 本身就是一颗 SPI NOR Flash，不存在“原生 QSPI”这个说法，它的 Quad 模式本质上还是拿那几根引脚复用成双向数据线，但对 MCU 侧来说，控制器的内存映射能力和突发读效率完全不是一个体验。
SDIO 方案也能挂 Flash 或者 TF 卡，但 SDIO 引脚多、协议栈重、还需要额外的命令初始化流程，杀鸡用牛刀。做嵌入式产品时，QSPI 是容量、速度、引脚占用之间最平衡的选项。STM32H743 的 QUADSPI 控制器本身就支持单线、双线、四线模式，还支持把外部 Flash 映射到 CPU 地址空间，直接按指针访问，这是普通 SPI 没办法给的体验。
1.2 为什么选 W25Q64
W25Q64 是华邦 NOR Flash 家族里很经典的一颗，容量 8MB（64Mbit），支持标准 SPI、Dual SPI、Quad SPI，分频后接口时钟可以支持到很高频率。选它做实验材料有一个很现实的原因：便宜、好买、资料烂大街。淘宝几块钱一片，随便造不心疼，非常适合用来验证 H743 的 QSPI 外设逻辑。
对于实验例程来说，W25Q64 的 8MB 容量也刚好覆盖大部分边界测试：3 字节地址就能完成全部操作，不需要像 W25Q256 那样处理 4 字节地址模式。如果换成 256Mbit 的芯片，地址宽度、QE 位、读命令序列都不一样，反而增加了干扰因素。
当然，这颗芯片也有一点要特别注意：它的 Page Program 是 256 字节一页，Sector 擦除是 4KB，Block 擦除是 32KB/64KB。这些参数决定了你在写驱动时，写入数据必须按页拆分、做跨页处理，擦除时还要避开正在使用的扇区。例程里我把这些底层操作全部封装好，这样业务层调用时根本不用关心 W25Q64 内部的组织方式。
1.3 MDMA 在这里扮演什么角色
STM32H743 里的 DMA 不只是 DMA1/DMA2 那套老东西，还带了一个更强的 MDMA（Master DMA）。MDMA 可以看成是能直接访问大多数 AHB/APB 外设的“搬运队长”，它支持任意到任意的传输，还能用链表描述符连成一条传输链，让复杂搬运任务不需要 CPU 一根一根地指挥。
在 QSPI 读 Flash 的场景里，MDMA 干的事情很简单：QSPI 控制器从 W25Q64 读出来的数据会先进入一个 FIFO，MDMA 负责把这个 FIFO 里的数据搬到你指定的内存 buffer。每次从 Flash 到 FIFO 的填充速度可能不稳定，但 MDMA 可以挂在外设请求信号上，来一点搬一点，搬运完成后触发中断告诉 CPU。
如果不加 MDMA，纯 CPU 轮询方式就得反复读 QSPI 状态寄存器、检查 FIFO 是否非空、然后手动搬运 4 字节。代码倒是简单，但每次等待和判断都会消耗主频，读取 8MB 数据时差距非常明显。加了 MDMA 之后，CPU 把初始化和启动命令发出去就可以去处理别的任务了，数据搬完再被中断拉回来，这种模型在实时系统里尤其重要。
2. 硬件链路与底层原理：读懂 QSPI、W25Q64、MDMA 三者之间的关系
2.1 STM32H743IIT6 的 QUADSPI 控制器
QUADSPI 在 H7 系列里是一个独立外设，它有一套完整的指令序列状态机。你在驱动里要做的不是像普通 GPIO 模拟 SPI 那样一根引脚一根引脚地操作，而是填好命令结构体、使能传输，剩下的时序由硬件自动生成。
ST 的 HAL 库里对应的是一个QSPI_CommandTypeDef结构体，里面包含指令、地址、数据长度、地址大小、指令模式、地址模式、数据模式、备用字节模式，以及操作类型和指令宽度这些字段。例程里的QSPI_ReadData函数，本质上就是组装这样一个结构体，然后调用HAL_QSPI_Command和HAL_QSPI_Receive*。
QUADSPI 支持两种读取模式：间接模式和内存映射模式。间接模式下，你给控制器发命令，数据会流进 FIFO，然后你可以用轮询、中断或 DMA 把 FIFO 里的数据取走；内存映射模式下，你直接把外部 Flash 当作一块只读内存，CPU 访问一个映射地址，硬件自动发起读命令，数据“看起来”就像从内部 Flash 读出来一样快。
2.2 W25Q64 的指令体系与状态机
嵌入式圈子里统计过，90% 的 QSPI 问题出在读不到数据，而读不到数据的原因里，又有很大一部分是“忘了让 Flash 进入 Quad 模式”。W25Q64 的寄存器里有一个 QE 位（Quad Enable），位于状态寄存器 2 的 bit1。这个位默认是 0，只有把它写成 1，芯片才允许四线指令，比如 0x6B、0xEB 这类 Quad 读命令。
所以初始化流程里有一个关键步骤：写状态寄存器 2。先发0x06写使能命令，再发0x31（Write Status Register-2），把 SR2 置成 0x02，把 QE 位拉起来。写完还要通过0x05读状态寄存器 1，轮询 BUSY 位，确保 Flash 内部操作完成。
读命令的选择也影响效率和时序。普通读0x03每次都要发命令地址，没状态切换，速度极慢；快速读0x0B可以加 dummy 周期，适合提高时钟频率；四线快速读0x6B支持从引脚上直接并行输出数据；四线 I/O 快速读0xEB则是地址和 dummy 周期也走四线，减少命令阶段占用的时钟数。例程用的方式以0x6B为主，实际项目里如果追求极限性能，可以考虑0xEB，但要确认主控支持连续读模式（Continuous Read Mode）以及退出连续模式的方法，否则会搞出一堆协议兼容问题。
2.3 MDMA 如何与 QSPI 联动
很多第一次上手 H743 的人会想当然：QSPI 是外设，MDMA 是 DMA，那直接配置 DMA 就好。实际上，H7 系列把 QUADSPI 的 DMA 请求信号接到了 MDMA 路径上，如果你在 CubeMX 里选 DMA1/DMA2，根本找不到 QUADSPI 的请求源，或者配置出来也是错乱的。这里有一个很关键的背景：H7 有两个 DMAMUX 域，其中 DMAMUX1 给常规 DMA，DMAMUX2 给 MDMA，QUADSPI 的请求要挂在 MDMA 这边。
联动逻辑也不复杂。QSPI 从 Flash 读数据时，FIFO 里每积累到一定字节数，硬件就会拉一个 DMA 请求信号。MDMA 看到这个信号后，自动把 FIFO 里数据搬到目标内存地址，然后继续等下一个请求。当所有预定长度的数据都搬完后，MDMA 产生传输完成中断，你在中断回调里置一个标志，应用程序就知道读取结束了。
这里要注意一个细节：MDMA 的传输粒度必须和 QSPI FIFO 的数据宽度匹配。H743 的 QSPI FIFO 是 32 位宽的，所以 MDMA 的TransferSize应该配置成 32 位，长度用字节数除以 4。如果你配置成 8 位，MDMA 读到的数据不仅字节序会乱，连续读模式下还可能丢请求，导致读出来的数据量比预期少。
3. 从零到一：QSPI + MDMA 读取例程的工程搭建与代码解析
3.1 引脚分配与时钟树配置
用 CubeMX 去搭建工程最省事。我使用 STM32H743IIT6，在 CubeMX 里选 QUADSPI 外设时，它会自动分配引脚：默认是 PA2（CLK）、PB6（NCS）、PB2（BK1_IO0）、PB10（BK1_IO1）、PB11（BK1_IO2）、PD7（BK1_IO3）。不同板子可能有差异，所以第一件事一定要打开原理图核对，确认这些引脚没有被其他外设占用。
时钟树方面，QSPI 的外设时钟可以直接选择 AHB3 或系统时钟分频。我在例程里把 QSPI Kernel Clock 配置成 100MHz 附近，再在 QUADSPI 初始化里用分频系数降到 50MHz 左右，这样 W25Q64 在四线模式下非常稳。很多人一上来就上 133MHz，结果读取偶尔出错，其实问题不一定在 Flash，而在板子走线和采样相位。对实验例程来说，稳定比极限速度重要，超频的事留给 PCB 达标的产品再说。
CubeMX 里还有几个跟 DMA 相关的勾选项：在 QUADSPI 的 DMA Settings 里把 TX/RX 通道都选成 MDMA，而不是 DMA1/DMA2。这一步选错，后面代码生成出来就不会有 MDMA 初始化代码，HAL 库调用也会直接卡在等待超时。
3.2 QUADSPI 初始化参数的计算与配置
初始化代码集中在MX_QUADSPI_Init或对应的 HAL 配置函数里。关键参数是这几个：
ClockDivider：时钟分频。H743 的 QUADSPI 时钟源经过这个分频系数，再送到外部 Flash。一般不要低于 2，分频越小时钟越高，但 PCB 信号质量要求也越高。FlashSize：外部 Flash 的首个逻辑地址。W25Q64 是 8MB，2 的 23 次方等于 8MB，所以这个值填 23。填错会导致地址空间映射异常。FifoThreshold：FIFO 阈值，也就是触发 DMA 请求的门槛。我习惯配 4，意味着 FIFO 里积累到 4 个字节（一个 32 位字）就触发一次搬运。SampleShifting：采样移位。这个参数影响的是读取数据时，控制器在什么时刻去采样总线电平。如果数据总是偶尔错误，可以在这里调整采样沿。ChipSelectHighTime：片选高电平时间。两次传输之间的间隔太短，Flash 状态机可能没准备好，所以这个值也不要配 0。
Flash 容量参数的计算，我推荐直接写成根据板级宏定义可调的，比如：
#define FLASH_SIZE_64MB (23U) // 2^23 = 8MB这样以后换更大容量的 Flash，只改一个宏，再配合 4 字节地址切换逻辑，驱动层不用大改。
3.3 W25Q64 基础操作封装
我习惯把 W25Q64 的所有底层操作单独放到一个文件，例如w25q64.c，对外只暴露几个接口：W25Q64_Init、W25Q64_Read、W25Q64_Write、W25Q64_EraseSector。内部实现时，先把 QSPI 命令结构体定义好。
写使能是最常用的小函数。HAL 库提供了HAL_QSPI_Command，可以把指令直接发给 Flash：
static void W25Q64_WriteEnable(void) { QSPI_CommandTypeDef cmd; cmd.Instruction = 0x06; cmd.AddressMode = QSPI_ADDRESS_NONE; cmd.DataMode = QSPI_DATA_NONE; cmd.DummyCycles = 0; cmd.InstructionMode = QSPI_INSTRUCTION_1_LINE; HAL_QSPI_Command(&hqspi, &cmd, HAL_QSPI_TIMEOUT_DEFAULT_VALUE); }写使能之后，写状态寄存器 2 打开 QE 位，然后等 BUSY 位清零。这里有个细节：修改 Flash 状态寄存器时，需要先读取旧状态寄存器的值，再保留其他位，否则会误清掉保护位。
四线快速读的封装稍微复杂一点。命令是0x6B，地址宽度 3 字节，地址模式是四线，数据宽度是你希望读取的字节数。因为 W25Q64 的地址是 3 字节，FlashSize 23 就是这个 3 字节地址的基础。
3.4 MDMA 通道配置与请求映射
CubeMX 生成工程后，MDMA 初始化代码一般长这样：
MDMA_HandleTypeDef hmdma_qspi_rx; void MX_MDMA_Init(void) { hmdma_qspi_rx.Instance = MDMA_Channel0; hmdma_qspi_rx.Init.Request = MDMA_REQUEST_QUADSPI; hmdma_qspi_rx.Init.TransferTriggerMode = MDMA_BLOCK_TRANSFER; hmdma_qspi_rx.Init.Priority = MDMA_PRIORITY_VERY_HIGH; hmdma_qspi_rx.Init.Endianness = MDMA_LITTLE_ENDIAN; hmdma_qspi_rx.Init.SourceInc = MDMA_SRC_INC_WORD; hmdma_qspi_rx.Init.DestinationInc = MDMA_DEST_INC_WORD; hmdma_qspi_rx.Init.SourceDataSize = MDMA_SRC_DATASIZE_WORD; hmdma_qspi_rx.Init.DestDataSize = MDMA_DEST_DATASIZE_WORD; hmdma_qspi_rx.Init.DataAlignment = MDMA_DATAALIGN_PACK; hmdma_qspi_rx.Init.BufferTransferLength = 1; hmdma_qspi_rx.Init.BlockCount = 1; HAL_MDMA_Init(&hmdma_qspi_rx); }请求方向要反过来看：读取时 QSPI 是源，内存是目标。所以源地址是 QSPI 的 FIFO 数据地址，目标地址是你的 buffer，源不增加、目标按 4 字节递增。Request字段必须设置成 QUADSPI 对应的请求，这一步我非常不建议手动裸写寄存器，最好在 CubeMX 中显式选中 MDMA 后让代码生成器自动填，否则请求号容易搞错。
MDMA 的 Buffer 大小需要注意，它和普通 DMA 的传输长度概念不同。配置 BlockCount 为 1、每次 Block Transfer 完成后触发中断，整体传输完成后也要处理中断状态。例程里我用的是HAL_MDMA_Start_IT起一个完整块传输，配合中断回调判断完成。
3.5 读取流程整合与代码结构
实际调用流程是这样：
- 初始化 QSPI 和 MDMA。
- W25Q64 掉电唤醒（
0xAB命令）。 - 读状态寄存器，等待 Flash 就绪。
- 调用
W25Q64_Read，内部组装0x6B命令，调用 HAL 层HAL_QSPI_Command，再调用HAL_QSPI_Receive_DMA。 - 等待 DMA 完成标志，读取 buffer 里的数据。
HAL 库的HAL_QSPI_Receive_DMA内部会自动把 MDMA 的源地址指向 QSPI FIFO，但这里有个隐藏行为：它默认使用你 CubeMX 生成的 MDMA 句柄。所以如果你在 CubeMX 里没把 QUADSPI 的 DMA 关联到 MDMA，这个函数调用的句柄就是空指针，直接 HardFault 或者卡死。
在工程结构上，我会把“QSPI 硬件操作”和“W25Q64 业务协议”分层：
qspi_if.c：维护 hqspi 句柄、提供底层的 HAL 包装；w25q64.c：调用 qspi_if 层，实现读、写、擦、状态机轮询；app_main.c：业务层，比如保存一组日志、再读出来做校验。
这样的分层方便以后把 W25Q64 换成 GD25Q64、MX25L6445EM 这类同规格芯片时，只需要改 w25q64.c 里头的命令字。
4. 踩坑实录：半个月调试中最常见的 7 个问题
4.1 MDMA 请求映射与 QSPI FIFO 事件的匹配
我在第一次做这个例程的时候，卡在“HAL_QSPI_Receive_DMA 一调用就超时”。逻辑上命令发了、Flash 也响应了，但 MDMA 就是不动。后来逐个排查，发现 CubeMX 的 DMA Settings 里虽然能看到 QUADSPI 的选项，但默认分配的是 DMA1，不是 MDMA。
症状非常典型：程序能初始化，但一旦执行带 DMA 的读取，就卡在某个等待标志上。原因是 QUADSPI 的 FIFO 请求事件根本没有路由到正在等待的 DMA 通道上。解决方法是回到 CubeMX，在 QUADSPI 的 DMA Settings 里手动勾选 “MDMA” 作为 DMA Request，重新生成代码。
如果是手动移植 ST 例程，还要检查 MDMA 初始化里的Request值，必须和芯片参考手册中 DMAMUX2 映射表格对应。简单判断方法是看 MDMA 中断回调有没有被触发：一次都没触发，基本就是请求映射问题；触发了但数据错，其实是数据宽度或者地址递增方向问题。
4.2 Cache 一致性：H7 上不能忽略的 D-Cache
H743 有 D-Cache，而 MDMA 搬运数据到内存时，数据是通过总线直接写入内存的，不会经过 CPU 的 Cache。如果你的 MPU 把这块内存配置成了 Cacheable 或 Write-Back，CPU 从同一地址去读时，命中的还是老旧的 Cache 行数据，读出来全是旧值或乱码。
这个问题只会出现在开启 D-Cache 时，而且很隐蔽。正确的做法是在 MDMA 搬运完成后，对目标内存做一次SCB_InvalidateDCache_by_Addr；在写入数据前，如果需要 CPU 保证数据能 DMA 出去，则要SCB_CleanDCache_by_Addr。
SCB_InvalidateDCache_by_Addr((uint32_t *)buffer, length);在例程里，我把这个操作放在接收完成回调之后，这样可以保证 CPU 拿到的就是 DMA 搬进来的新数据。硬编码关闭 D-Cache 能偷懒一时，但会影响整个系统性能，尤其 H7 这种 MHz 级别的核，开 Cache 和不开 Cache 的跑分差距非常大。
4.3 读数据全是 0xFF / 前几字节错乱
遇到“读出来所有数据都是 0xFF”，第一反应不要急着怀疑 QSPI 时序。先确认 W25Q64 是不是进入了掉电模式，或者芯片压根没被片选命中。用示波器看 NCS 引脚，如果发现 NCS 电平一直是高，大概率是片选极性配置反了；如果 NCS 有低电平，但 MISO 始终为高，则检查 QSPI 的 DataMode 是否配置成了四线，而 Flash 又没有使能 QE 位。
前几个字节错乱则大多跟 FIFO 阈值和采样移位有关。例如读命令发出后，Flash 需要几个 dummy 周期，如果你在命令结构体里配的DummyCycles比芯片手册要求少，控制器拉到前导数据还没稳定就开始采样，自然读错。W25Q64 的0x6B命令需要 8 个 dummy 周期，0xEB需要 6 个，这些数字必须按手册来。
4.4 常见问题速查表
我整理了这段时间调试时遇到的高频问题，按症状、原因、处理方式做成一个速查表，方便大家直接对照排查：
| 症状 | 可能原因 | 处理方式 |
|---|---|---|
| 读回来的数据全为 0xFF | Flash 处于掉电模式，或 QE 位未使能 | 发送 0xAB 唤醒；写状态寄存器 2 使能 QE |
| 卡死在 HAL_QSPI_Receive_DMA | DMA 请求未关联到 MDMA | 检查 CubeMX 中 QUADSPI 的 DMA Request 是否为 MDMA |
| 数据长度减半或丢字节 | MDMA 数据宽度与 FIFO 宽度不匹配 | 将 TransferSize 配置为 32 位，长度按 4 字节对齐 |
| 数据与读取缓冲错位 | DummyCycles 配置过多或过少 | 对照 W25Q64 数据手册核实读命令的 dummy 周期数 |
| 偶发数据错误 | D-Cache 未 invalidate | 在 DMA 完成后调用 SCB_InvalidateDCache_by_Addr |
| 擦除后写不进去 | 忘了写使能 0x06，或状态寄存器保护位打开 | 每次写操作前发 0x06；检查 SR1 的 BP 位 |
| 换一块板子就完全不通 | 引脚复用冲突或时钟树不一致 | 核对 CubeMX 引脚分配，确认没有外设冲突 |
这些坑算不上高深，但每个都能消耗你一个下午甚至一天。当初要是有人直接给我这样一张表，我能少走不少弯路。
5. 实测效果与性能优化建议
5.1 实测条件与性能数据
我在自己的板卡上做了一个简单测试：读取 W25Q64 前 4KB 数据，分别用三种方式对比耗时。第一种是普通 SPI 模式的轮询读取，时钟约 40MHz；第二种是 QSPI 间接模式配合 CPU 轮询；第三种是 QSPI + MDMA。
测试条件比较朴素，H743 主频 480MHz，QSPI 时钟大约 50MHz，关闭编译器优化，用 DWT 计数器计时。结果如下：
| 读取方式 | 4KB 耗时 | CPU 占用情况 |
|---|---|---|
| 普通 SPI 轮询 | 约 1.1ms | 全程占用 |
| QSPI 间接模式轮询 | 约 0.3ms | 全程占用 |
| QSPI + MDMA | 约 0.25ms | 仅启动和终断占用 |
MDMA 方式和 QSPI 轮询在这个小数据量下的差距不明显，因为 4KB 的数据量还不足以拉开差距，但换成 8MB 全片读取，差距就非常明显了。MDMA 在读取过程中，CPU 可以继续跑其他任务，比如刷新屏幕、处理串口协议。对于真实产品来说，“CPU 占用率下降”比“单次读取微秒级提升”更有意义。
5.2 进一步优化方向
如果后续项目需要从 QSPI Flash 读大量数据，比如 GUI 需要从外置 Flash 加载整张背景图，我不建议继续用间接模式加 DMA。更好的方式是切换成 QSPI 内存映射模式，把外部 Flash 直接映射到0x90000000起始的地址空间，然后用指针直接访问。这种方式下，CPU 的 D-Cache 也可以参与缓存，配合SCB_CleanDCache和SCB_InvalidateDCache维护一致性，读取速度能再上一个台阶。
内存映射模式也不是没有代价。它适合“读多写少”的场景，因为写操作仍然要走间接模式；如果你在内存映射模式下做写擦操作，必须先把 FMODE 切回间接模式。例程里我保留了两种模式的切换接口，但默认用间接模式加 MDMA，主要考虑是逻辑链路更清晰，适合教学理解。
如果要把接口时钟拉到 80MHz 以上，还要重点检查 PCB 走线：CLK 和数据线尽量等长，减少串扰；在 CubeMX 里微调SampleShifting，找到最稳定的采样点。每个人的板子布线不一样，没有一个绝对的“最优”参数，只能在示波器辅助下去试。
我后面还会继续把这套驱动裁剪成纯寄存器版本，去掉 HAL 库的冗余调用，专门为生产环境做一个轻量实现。到那时候，再跑一次 8MB 全片读取，横向对比数据会更有说服力。
最后再分享一个实操习惯：调 QSPI 这种外设，逻辑分析仪和示波器不能省。哪怕只有一个最便宜的逻辑分析仪，也要把 CLK、NCS、IO0、IO1 四路信号抓下来看一轮，很多配置问题一眼就能看出来，比反复改参数烧录快得多。我自己就是在把波形看懂之后，才真正理解了 QSPI 的时序关系，后面再换其他型号 Flash 和 MCU，心里都有底。
本文还有配套的精品资源，点击获取
