How Do You Interface External QSPI Flash on the nRF52840?

Detailed Explanation

The nRF52840 ships with 1 MB of internal program flash, which sounds generous until it's split between the BLE/Thread stack (whether that's Nordic's SoftDevice or the Zephyr-based stack in the nRF Connect SDK), the application itself, and, on any product using DFU, MCUboot's dual-slot partitioning, which by design reserves space for a second copy of the entire application image so an update can be staged and verified before it overwrites the running one. Once those pieces are accounted for, the flash actually available for application data storage is often a small fraction of the nominal 1 MB. The QSPI peripheral exists to add external NOR flash for exactly that remaining need, without competing with the SoC's own program storage.

How the QSPI Peripheral Works

QSPI stands for Quad Serial Peripheral Interface, referring to four bidirectional data lines (IO0 through IO3) instead of the single MOSI/MISO pair a standard SPI bus uses, alongside the usual clock and chip-select lines. This lets a QSPI-capable flash chip transfer four bits per clock cycle instead of one, at up to 32 MHz on the nRF52840, giving substantially higher throughput than the same part driven over conventional single-line SPI.

The peripheral supports two access modes. In direct read/write mode, firmware issues explicit read, write, and erase commands to the external flash, similar in concept to how a regular SPI flash driver works, just over the faster quad-SPI bus. In memory-mapped mode, the peripheral presents the external flash's address space as if it were part of the SoC's own memory map, so application code can read from it using ordinary pointer or array access rather than issuing flash-read commands, with the peripheral handling the underlying QSPI transactions transparently.

Typical External Flash Parts

Common QSPI-compatible NOR flash parts paired with the nRF52840 range from a few megabytes up to 64 Mbit (8 MB) or larger, depending on the design's storage needs, most commonly from Winbond, Macronix, or Adesto/Renesas. The Adafruit Feather nRF52840 boards, a widely used development platform for this exact use case, include an onboard 2 MB QSPI flash chip as a standard feature, which is often the first place developers encounter this peripheral in practice before applying the same pattern to a custom board.

Practical Examples

A BLE Mesh product is a representative case: Mesh provisioning data, network and application keys, and the model configuration state can grow well beyond what a design comfortable with internal flash's remaining budget can absorb, especially on a device also running MCUboot's dual-slot DFU partitioning. Moving that Mesh state, or a broader LittleFS filesystem holding it alongside application configuration and logs, onto external QSPI flash frees the internal flash for the code and stack partitions it's actually sized for.

A second common case is DFU image staging on a device that also wants a large writable filesystem. Rather than reserving MCUboot's secondary slot entirely inside internal flash (doubling the effective code-storage cost), some designs stage the incoming DFU image on external QSPI flash and copy it into the internal secondary slot only once the transfer completes and validates, trading a slightly more involved update flow for meaningfully more usable internal flash during normal operation.

Design Considerations

• Confirm which nRF52 variant is actually in the design before assuming QSPI is available. The QSPI peripheral is specific to the nRF52840 within the nRF52 family; see nRF52 variants compared for which parts include it and which don't. Designing around external QSPI flash and then substituting a lower-cost nRF52832 or nRF52833 late in the project removes the peripheral entirely, not just some of its throughput.
• Decide between direct access and memory-mapped mode based on the actual use case, not by default. Direct read/write/erase mode suits a filesystem or explicit data-storage pattern where firmware manages reads and writes deliberately; memory-mapped mode suits large, mostly-read data (media assets, large lookup tables, a pre-staged DFU image) accessed like ordinary memory. Using memory-mapped mode for data that changes frequently, or direct mode for something better served as memory-mapped, adds firmware complexity without a real benefit either way.
• Size the filesystem layer to the external flash's actual erase-block geometry, the same wear-levelling and erase-granularity considerations that apply to any NOR/NAND flash filesystem. See embedded flash storage: LittleFS and FatFS for how a filesystem layer handles wear levelling and erase-block alignment, which applies equally whether the underlying flash is internal or external QSPI.
• External flash adds board area, a component, and BOM cost that internal-flash-only designs don't carry. Before adding a QSPI flash chip, confirm the actual storage shortfall is real (calculate the SoftDevice/stack, application, and MCUboot dual-slot partition sizes against the nRF52840's 1 MB) rather than assuming external flash is needed without first checking whether a partitioning change or a smaller BLE stack configuration closes the gap.
• External flash storage architecture: sizing internal-versus-external flash partitioning, DFU staging strategy, and filesystem selection for an nRF52840 product with a real storage budget constraint is exactly the kind of firmware architecture work Zeus Design's embedded team handles for BLE and Mesh product development.

Common Mistakes

• Assuming any nRF52 part supports QSPI because "the nRF52840" is treated as representative of the whole family. Only the nRF52840 has the peripheral; a design that specs QSPI flash against a different nRF52 variant, or that assumes cross-variant portability without checking, will not compile against the target SoC's peripheral set.
• Wiring QSPI flash without accounting for its power-down and deep-power-down modes. Many QSPI NOR flash parts draw meaningfully more current in active standby than in their lowest power-down state, which matters directly on a coin-cell or ultra-low-power BLE design; leaving the flash chip in an active state between accesses undermines the same power budget the rest of an nRF52840 design is normally optimised for.
• Treating external QSPI flash as a drop-in extension of the internal flash address space without a filesystem or explicit partitioning scheme. Raw, unmanaged access invites the same erase-before-write and wear-levelling problems any NOR flash has; use a filesystem or a deliberate partition table rather than ad hoc reads and writes.