FlexSPI + QSPI NOR on the i.MX RT1062: Configuration and Verifying Max Speed

I had a board booting XIP from a Winbond W25Q128JV and no idea whether the flash was running anywhere near its limit. The FlexSPI config had been copied from an SDK example, serialClkFreq said 133MHz, and everything worked. That is exactly the situation where you assume you are fine and you are not.

So I measured it. The read path turned out to be at 97% of its theoretical ceiling — done, nothing to tune. The write path reported a number so good it was obviously wrong, and chasing that down was the more useful half of the exercise.

In this article I show how FlexSPI actually gets configured on the RT1062, how to compute the read ceiling and check you are at it, and why write speed must be verified against the flash datasheet rather than against the bus.

The whole result in five lines. Read is maxed. The write number is the one to be suspicious of — see step 5.

Platform

Step 1 — Know which of the two paths you are on

FlexSPI sits between the AHB bus and up to two SPI channels (port A / port B), each with two chip-selects. It exposes two independent paths into the same LUT-driven sequence engine, and almost every FlexSPI bug comes from confusing them:

flowchart LR
    CPU["Cortex-M7"] -->|"memory-mapped read/write<br>0x60000000"| AHB["AHB path<br>(XIP, transparent)"]
    CPU -->|"IPCR0/IPCR1 + IPCMD.TRG"| IP["IP path<br>(software-triggered)"]
    AHB --> RXB["AHB RX buffer"]
    AHB --> TXB["AHB TX buffer"]
    IP --> FIFO["IP TX/RX FIFO<br>128 bytes each"]
    RXB --> SEQ["LUT Sequence Engine"]
    TXB --> SEQ
    FIFO --> SEQ
    SEQ -->|"SCLK, IO0-3, CS"| FLASH["W25Q128JV"]

• AHB path (XIP). The CPU reads the 0x60000000… window and FlexSPI silently runs the LUT read sequence, buffering through the AHB RX buffer. This is what code execution and memcpy-style reads use. No status polling, fully transparent.
• IP path. You explicitly write IPCR0/IPCR1, set IPCMD[TRG], and push/pop bytes through the 128-byte TX/RX FIFOs. Required for erase and page-program, because those are explicit commands, not memory accesses.

Step 2 — Write the LUT, because there is nothing else

There is no read() or erase() register in FlexSPI. Every operation is a sequence of up to 8 instructions (4 × 16-bit words) in the 64-entry LUT. Each instruction is (opcode, pads, operand):

/* Quad I/O Fast Read (0xEB): CMD on 1 pad, address on 4 pads, 6 dummy, data on 4 pads */
[4 * NOR_CMD_LUT_SEQ_IDX_READ + 0] =
    FLEXSPI_LUT_SEQ(CMD_SDR,   FLEXSPI_1PAD, 0xEB, RADDR_SDR, FLEXSPI_4PAD, 0x18),
[4 * NOR_CMD_LUT_SEQ_IDX_READ + 1] =
    FLEXSPI_LUT_SEQ(DUMMY_SDR, FLEXSPI_4PAD, 0x06, READ_SDR,  FLEXSPI_4PAD, 0x04),

You are always programming a tiny bytecode interpreter, not calling a library. SDR vs DDR and Single/Dual/Quad/Octal are chosen per-instruction by the opcode and pad count — there is no global mode register. A single sequence can mix a 1-pad command with 4-pad data.

Step 3 — Pick the sampling clock, because it caps your frequency

This is the most-skipped part of the RM (§27.3.15), and it is the part that decides how fast you are allowed to go. To read data back reliably at high speed, FlexSPI must sample the incoming data at the right instant. It offers four RX clock sources via MCR0[RXCLKSRC]:

For modes 0 and 1 the DLL (DLLxCR) is set to a fixed one-delay-cell value (0x00000100) — no auto-lock. Mode 3 requires the DLL to lock to half the serial clock and is the only way past ~133 MHz, but it needs a genuine DQS strobe from the flash.

Step 4 — Configure for the W25Q128JVFIQ

Read LUT: use Quad I/O (0xEB), not Quad Output (0x6B)

Both are valid Winbond instructions. 0xEB (1-4-4) sends the address on 4 pads too, versus 0x6B (1-1-4) which sends the address on 1 pad. Less protocol overhead per transaction, same clock rating.

Clock tree

The FlexSPI serial root clock comes from PLL3_PFD0_CLK with FLEXSPI_PODF = 2, giving ≈132.9 MHz — measured live via CLOCK_GetClockRootFreq, which is the first line in the log capture above. The serialClkFreq enum in the boot-header struct only selects a divider the boot ROM uses transiently; the runtime frequency is set by clock_config.c. Keep both pointing at the same target.

Write path: quad page program (0x32)

Erase and program go through the IP path with their own LUT slots — write-enable 0x06, sector-erase 0x20/0xD7, quad page-program 0x32.

Step 5 — Verify, and distrust the good news

Read and write have fundamentally different ceilings and need different verification.

Read: compare against the theoretical bus ceiling

For quad SDR the ceiling is pure math — no flash-specific mystery number:

Measured over a 128 KB sequential AHB read, timed with the DWT cycle counter:

The remaining ~2.6% is the one-time command + address + dummy prefix (~20 clocks) amortised over 128 KB. To prove 128 KB was a large-enough sample, sweep the benchmark length (4 KB → 32 KB → 128 KB → 1 MB) and confirm the throughput curve is already flat. If it is still climbing, your sample was too small and undersold the real number.

Write: compare against the datasheet’s tPP, not the FlexSPI clock

Write speed is silicon-limited, not bus-limited. The SPI transfer of 256 bytes at 132.9 MHz quad takes only ~4 µs — negligible next to the flash’s internal program time. From the W25Q128JV AC Characteristics (§9.6):

So “max write speed” is a fixed property — you verify you are at tPP, not that you have tuned past it.

Now look again at the last line of the log capture: write throughput 24,972 kbps. That is 3.12 MB/s, which works out to 256 bytes ÷ 3,121,500 bytes/s ≈ 82 µs per page.

Verification checklist

• Read throughput ≥ ~95% of f_clk × 4 → read path is saturated
• Read throughput curve flat across benchmark sizes → sample large enough
• Measured page-program time inside the datasheet tPP typ–max band
• Per-page WIP poll count is plausible (not suspiciously low)
• Readback verify passes (data integrity, separate from timing)
• serialClkFreq (boot header) and runtime clock tree agree

Summary

The read path is finished: 518 Mbps at 132.9 MHz quad SDR is 97.4% of the theoretical ceiling, and with DQS unrouted there is no faster mode available on this board. Nothing left to tune.

The write path is not finished. The measurement is physically implausible, which means the busy-poll is racing completion rather than the flash being fast. Next step is instrumenting the poll loop and re-measuring against tPP.

The general lesson is the one worth keeping: a benchmark that beats the datasheet is not a result, it is a bug report about your measurement.

Related

• i.MX RT1062 pin config: pull/keeper, drive strength and slew rate — the pad-control fields behind these signals
• Adding a microSD card active object with QP/C and USDHC1 — the other storage path on the same board

💬 Questions, corrections, or your own war story with FlexSPI? Leave a comment below — I read and answer all of them.