QSPI Hardware Implementation and Driver Principles

QSPI protocol overview

QSPI stands for Queued SPI. It is an extension of the SPI protocol. In general, SPI can be categorized as standard SPI, dual SPI, and Queued SPI. Dual SPI and Queued SPI are commonly used as the communication interface for SPI flash devices.

Applications

QSPI is a queued serial peripheral interface protocol that extends SPI. It can use single-, dual-, or quad-line modes to communicate with external flash memory at high speed. Typical application scenarios include:

• Data storage: storage of large amounts of data such as code, images, and video to increase read/write capacity and throughput.
• Code execution: executing code directly from external flash to save internal flash space, for example using QSPI XIP (execute in place) in memory-mapped mode.
• Communication with other peripherals: QSPI can interface with other devices that support the QSPI protocol, such as sensors and displays, improving flexibility and throughput.

Protocol features

QSPI typically supports two operating modes: Config mode and Memmap (memory-mapped) mode. Some chips implement additional modes, but they can generally be classified under these two.

A QSPI command sequence consists of up to five phases: instruction, address, alternate bytes, dummy cycles, and data. Any phase may be skipped, but at least one of instruction, address, alternate bytes, or data must be present.

In most controllers, QSPI supports dual read and quad read modes but does not support dual write and quad write modes. QSPI does not implement an input/output loopback mode.

QSPI flash driver overview

Many flash driver implementations share similar principles. This article uses TI's QSPI flash driver as an example to explain the hardware implementation, read/write operation modes, and EDMA transfer behavior.

QSPI hardware implementation

In QSPI communication, the host SoC acts as the master. The CS pin is used to select which external flash device to communicate with, and the master provides the clock to control data transfer to and from the slave device.

The host contains an internal QSPI controller. The external device is a flash that supports QSPI. The interface typically includes one CLK pin, one CS pin, and four IO pins for data transfer.

QSPI read/write modes

QSPI supports multiple read/write modes, including 3-wire single write/read, 4-wire single write/read, dual read, and 6-wire quad read. In practical projects, it is common to use 4-line single write for write operations and 6-line quad read for read operations to make the most efficient use of the flash hardware.

The QSPI controller can be divided into two main modules: SFI_MM_IF and SPI_CORE. SFI_MM_IF handles initialization of read/write commands, address, and dummy cycle count; SPI_CORE handles clock polarity and phase, transfer length, and related timing.

SFI_MM_IF consists of:

• SFI register control: initializes read/write commands and related settings.
• SFI translator: sends the configured commands from the SFI registers to the SPI_CORE module for the external flash.

SPI_CORE consists of:

• SPI_CNTIF: SPI control interface used to set commands, clock polarity, and phase; used in config mode.
• SPI_CLKGEN: SPI clock generator, used to configure communication clock frequency.
• SPI_MACHINE: SPI state machine that takes commands from SPI_CNTIF and controls data shifting and transfer.
• SPI_SHIFTER: SPI data shifter that captures and generates interface signals.

The QSPI controller supports two usage methods: Config mode and Memmap mode. Write operations are generally performed in Config mode only; read operations are often done in Memmap mode so that external flash contents appear directly in the MCU memory layout.

QSPI with EDMA transfers

When reading large amounts of data via QSPI, using Memmap mode combined with EDMA is recommended to reduce CPU load and let EDMA perform the bulk data transfers. The detailed mechanics of EDMA are outside the scope of this article.

AUTOSAR Flash driver standard interface

This section lists standard AUTOSAR Flash driver interfaces and requirements so that developers can understand the key API functions and their purposes when using a flash driver.

Important points to note when using AUTOSAR Flash driver APIs include:

• Always call Fls_Init to initialize the flash driver before invoking read, write, or other flash operations; otherwise subsequent flash requests will be invalid.
• If an external flash is accessed via a QSPI driver, initialize the QSPI driver before calling Fls_Init to ensure a valid initialization sequence.
• When writing to flash, align the write address and length to the flash page size, typically 256 bytes but dependent on the flash model.
• When erasing flash, align the erase address and length to the sector size, typically 4 KB but dependent on the flash model.
• Fls_Read, Fls_Write, and other key API operations are asynchronous and non-reentrant. Ensure exclusive access to the flash driver; avoid conflicts between application-level code and FEE modules. Use NVM to serialize flash requests where applicable.

QSPI flash driver usage notes and best practices

Flash-related problems encountered during development are often intermittent and difficult to reproduce. Defensive programming and consideration of failure scenarios are important. The following practical recommendations address common issues in flash driver development:

• On every system startup or reset, perform an external flash reset. This can be implemented in one of three ways:
  • Power-cycle the flash via hardware during startup or reset to force a reset.
  • Drive the reset pin low via software to reset the external flash, taking pin multiplexing into account.
  • Send a software reset command to the flash over QSPI during initialization.
• If an external SPI flash is accessed via QSPI, check whether the flash's QE (Quad Enable) bit is enabled by default. If QE is not enabled, quad SPI communication will not work. It is recommended to set the QE bit during factory programming or during software initialization. The QE bit behavior depends on the flash model; program it according to the device datasheet.
• During initialization, verify the flash device ID (for example, manufacturer ID) to detect incorrect or mislabelled parts.
• Occasional system crashes or unintended execution may trigger flash write or erase operations and corrupt application code, preventing normal startup. Protect critical code regions in external flash to prevent accidental modification so the system can recover after a reset.