QSPI (Quad-SPI) NOR Flash and XIP: How to Wire It and Run Memory-Mapped Code
Quad-SPI uses 4 data lines and 2 clocks per byte, ~4× the throughput of standard SPI; XIP lets the CPU execute code in place from external flash without copying to RAM first. But XIP requires NOR (random read) — NAND can't. This guide covers SPI/Dual/Quad, how XIP works, and maps to GD25Q plus "the MCU side needs a QSPI/OSPI controller (only some GD32 have one)."
Single / Dual / Quad SPI: why Quad ≈ 4×
The read speed of a serial NOR flash hinges on how many data lines you use. Standard SPI carries 1 bit per clock, so a byte takes 8 clocks; Dual uses 2 lines, and Quad uses four lines (IO0–IO3), carrying 4 bits per clock so a byte takes only 2 clocks — meaning at the same clock, Quad's read throughput is about 4× standard SPI's. Above that are QPI (the command also goes on 4 lines, saving protocol overhead) and Octal/xSPI (8 lines). Remember: "Quad ≈ 4×" is a mechanism-level hard fact (2 vs 8 clocks/byte); the actual MB/s varies with clock, routing and controller.
What XIP is: memory-mapped, execute directly
XIP (eXecute-In-Place) lets the CPU fetch and execute code directly from external serial flash without first copying it all to RAM. The mechanism: the MCU's QSPI controller maps the external flash into the CPU's address space (commonly at some address region), and when the core fetches instructions from that region it's just like reading internal memory, while the QSPI controller silently turns each instruction fetch into a flash read transaction. Benefits: code/assets too big for internal flash can be offloaded, saving internal memory and simplifying boot and updates. The cost: a serial fetch is slower than internal flash, so a small cache / line buffer usually hides the latency (without a properly set cache and an executable MPU attribute, XIP performance drops noticeably).
⚠️ Why NOR is required: NAND structurally can't XIP
Why must XIP use NOR, and NAND can't? Because XIP requires true random byte read at any address. NOR supports random addressing with access times as fast as ~10 ns, so the CPU can read any single byte directly → XIP works. NAND is page-based: it must first load a whole page into a page register, the first-byte latency is ~20–50 µs, and it has no byte-level addressing, so it structurally cannot XIP directly; the NAND approach is to copy code into RAM first and then run it (shadowing). So the "execute directly in place" path always uses NOR (like the GD25Q); NAND (like the GD5F) is positioned for bulk data storage.
GD25Q + the MCU needs a QSPI controller
Matching parts: GigaDevice GD25Q is SPI NOR flash supporting Standard/Dual/Quad SPI, most members at 133 MHz (some high-density parts also offer 104 MHz x4 DTR), with densities from 512 Kb up to 256 Mb (common GD25Q32, GD25Q128, GD25Q256); GigaDevice also markets "ultra-fast XIP" — well suited to storing code plus read-only assets like fonts and UI graphics. But note: XIP requires a QSPI/OSPI controller on the MCU side — and this is series-specific, not every GD32 has one. Confirmed: the GD32H7 (built-in dual Octal SPI, with the AN122 OSPI execution-environment app note) and the GD32F4 series (QSPI, which can map QSPI flash as internal memory for XIP); the smaller GD32F1/F3 series mostly don't, so check that part's datasheet/user manual before selecting.
How to choose
First, confirm the MCU side has a QSPI/OSPI controller, or there's no memory mapping and thus no XIP (the GD32H7's Octal and GD32F4's QSPI work; small GD32 mostly don't). Second, align the interface mode on both ends — to use the full bandwidth enable Quad (and QPI + continuous-read / XIP mode where needed); the whole GD25Q line supports Standard/Dual/Quad. Third, size the density by total "code + font/graphic assets," leaving headroom for XIP code. Fourth, the clock ceiling depends on the MCU controller and PCB routing/signal integrity, not just the flash headline. Fifth, feature flags: Suspend/Resume (don't interrupt XIP reads during an update), Security Register + OTP, Unique ID, RESET/WP#/HOLD# as needed; for low-voltage routing consider the 1.8V GD25LQ. For bulk data storage rather than executable code, switch to SPI NAND (GD5F). JLink Technology is an authorized GigaDevice distributor supplying the full GD25Q SPI NOR line, GD5F SPI NAND, and GD32 parts with QSPI/OSPI (such as the GD32H7); tell us your density, interface and XIP needs and we will help with selection and reply with samples, datasheets and pricing.
Products mentioned
GD25Q256 256Mbit SPI NOR Flash
The GD25Q256 is a 256Mbit (32MB) serial SPI NOR Flash, 2.7~3.6V, up to 133MHz, with Dual/Quad I/O and 4-byte addressing (to reach the full 32MB). It includes OTP/Unique ID and program/erase suspend-resume, in SOP16 / WSON8 / TFBGA24. With a standard command set, it is commonly used as a Winbond W25Q256 alternative.
GD32H759 Arm Cortex-M7 600MHz High-Performance MCU
The GD32H759 is a high-performance Arm Cortex-M7 MCU from GigaDevice at 600MHz (L1 cache, double-precision FPU), with up to 3840KB Flash and 1024KB SRAM (ITCM/DTCM, ECC). It integrates 3× CAN-FD, dual Ethernet MAC (with EtherCAT), 2× USB HS/FS, 6× SPI, 2× OSPI, a TFT-LCD controller, and 14-bit ADC — for industrial automation, motor control, and graphical HMI. LQFP100/144/176, BGA.
GD5F1GQ5 1Gbit SPI NAND Flash
The GD5F1GQ5 is a 1Gbit SPI NAND Flash from GigaDevice with a 2KB page and 128KB block (64 pages), supporting x1/x2/x4 (Quad) SPI. The series splits into on-chip-ECC variants (UE, 2.7~3.6V, up to 133MHz) and ECC-free variants (RE, 1.7~2.0V, 104MHz), in WSON8 — for code and data storage on MCUs/SoCs.
Need these components or design help?
JLink Technology provides parts, datasheets, and engineering support.
Request a Quote