Running Code Directly from NOR Flash: XIP, Memory-Mapped QSPI, and Endurance Planning

Traditional MCU firmware lives in internal flash: reset, fetch, execute. But graphics stacks, wireless protocol stacks, and language runtimes have outgrown internal flash on many designs, so code storage moved to external NOR flash over Quad-SPI - and with it a fork in the road: copy everything to RAM first, or execute in place.

How XIP actually works

In memory-mapped mode, the QSPI controller translates CPU fetches into flash read commands transparently. The processor issues a load from an aliased address region, the controller drives the instruction, address, and dummy cycles onto the quad lines, and data returns as though it came from slow internal ROM. The mechanism is simple; the performance is not free. A 133 MHz quad-SPI part delivers a burst throughput on the order of 50 MB/s, but each first access to a new line pays command and address overhead. Continuous-read modes (the controller remembers the last instruction and streams addresses bare) plus a cache or prefetch buffer in front of the interface recover most of the loss.

Shadowing - copying code to RAM at boot and executing from there - gives deterministic full-speed execution at the cost of RAM capacity and boot time. The engineering trade is roughly: XIP when internal RAM is scarce and code locality is decent; shadowing when the control loop cannot tolerate fetch jitter, as in motor control or hard real-time acquisition.

ECC, endurance, and the logging problem

Modern NOR parts such as the Puya (普冉) P25Q series and BoyaMicro (博雅) BY25FQ series integrate on-die ECC, correcting single-bit errors within each page transparently. This matters because NOR wears by program and erase cycles - typical ratings run 100,000 cycles per sector - and worn cells show soft errors long before hard failure. On-die ECC means the system sees clean data well into aging, but it also means the error rate is hidden: teams that skip wear analysis may never notice a hot sector until corrected errors become uncorrectable.

Design guidelines that hold up in production:

• Partition by wear class: keep immutable code regions separate from parameter and logging regions. A diagnostic log written every second can erase a 4 KB sector 86,400 times a day if you let it.
• Journal, then erase: append log records across a sector and erase only when it fills; never rewrite a record in place.
• Reserve a swap region for firmware A/B updates: XIP makes in-place firmware update impossible by definition - the code being replaced is the code executing the update. Plan the layout for a download bank before pin assignment, not after.
• Verify dummy cycles per density: the same QSPI family at 8 Mbit and 128 Mbit often needs different dummy-cycle counts for the fastest read mode. Missing this shows up as intermittent corruption only at certain boot paths.

What to verify before layout freeze

Request the memory-mapped mode application note for the exact part number, confirm the maximum XIP clock with your trace length and level shifter choices, and run a 48-hour hammer test on the logging partition with production-like write rates. The first two prevent board respins; the last one prevents the field return where a customer helpfully explains that the device forgets its calibration every few weeks. NOR flash is a mature, forgiving technology - but only for teams that read the endurance table with their own use case in mind.