This article explains design approaches for achieving both XiP and data logging with QSPI flash. By deploying code in RAM and utilizing FeRAM, it is possible to avoid read constraints during write operations and support stable system design.
Understanding the Basics of QSPI and XiP
QSPI enables high-speed communication with external flash, allowing large-scale code execution while saving RAM through XiP. At its core is the controller’s “memory-mapped mode”, but behind this convenience lies a trade-off: the CPU continuously occupies the bus, making the balance between fetch efficiency and peripheral access arbitration a key factor for stable operation.
What is QSPI? Interface Method with Serial Flash
QSPI (Quad SPI) is a communication method that uses four synchronized data lines, achieving more than four times the throughput of conventional SPI. It is mainly used to connect to external NOR flash, and by using four lines for command, address, and data phases, it enables efficient data transfer beyond the clock frequency. Modern microcontrollers integrate dedicated controllers that connect QSPI directly to the system bus, leading to high-speed memory access without requiring software awareness.
Technical Concept and Requirements of Execute in Place (XiP)
XiP is a technique where the CPU fetches and executes code directly from flash memory without loading it into RAM. To enable this, the microcontroller’s memory controller must map the external flash address space into the internal system address map. From the CPU’s perspective, external flash behaves like a slower ROM, so optimizing instruction cache and prefetch buffers becomes critical to compensate for the speed difference and maintain system responsiveness.
Advantages and Limitations of XiP Using QSPI
XiP using QSPI reduces startup time and BOM cost, but also introduces the physical constraint of “bus occupancy”. Because code execution relies on the external bus, other peripherals cannot write data to the same QSPI bus while the CPU is fetching instructions. Therefore, when performing write operations such as data logging in parallel, it is essential to consider performance degradation and the risk of execution interruption due to bus contention.
Implementation and Challenges of Real-Time Data Logging
Logging is important, but in an XiP environment, “write operations during execution” run into physical limitations. For example, during flash writes, which involve boost voltage, the device cannot read from the same chip or bank due to the Read-While-Write constraint. If this is ignored, instruction supply is interrupted, and the system stalls immediately.
Definition and Use Cases of Real-Time Data Logging
Data logging refers to recording time-series data such as operating conditions of industrial equipment or sensor values in IoT devices, used for failure analysis and predictive maintenance. In applications requiring high-frequency sampling, write delays directly lead to data loss, making file system and buffering efficiency critical. While QSPI flash offers large capacity at low cost, its impact on the system bus during write operations cannot be ignored.
Write Operations and Constraints of QSPI Flash
Programming and erasing QSPI flash takes significantly longer than read operations. In most flash memories, data cannot be read from any region of the same chip during write or erase operations (no Read-While-Write capability). Under this constraint, issuing a write command during XiP blocks instruction fetch, posing a high risk of immediate CPU hard faults.
Conflict Risks Between Logging and XiP
The biggest challenge in combining XiP and logging is system hang due to read/write conflicts. Even writing a single byte can cause the flash to enter a “busy” state, during which the CPU cannot fetch the next instruction. Execution continues only while cache hits occur, but a cache miss will immediately stop the system. Avoiding this requires not only software techniques but also memory placement strategies and hardware-aware design.
Design Strategies to Achieve Both XiP and Data Logging
To ensure stable coexistence, layout design that avoids physical conflicts is essential. While software methods such as deploying executable code in RAM can circumvent flash memory constraints, optimizing device selection itself by leveraging the high-speed write capability of FeRAM (ferroelectric memory) can fundamentally reduce design complexity.
Placing Critical Code in Internal RAM and Region Separation
The most reliable approach is to place log-writing routines and critical interrupt handlers in internal RAM instead of flash. By using compiler section directives to preload code that may execute during write operations into RAM, the CPU can continue operating even when flash is busy. This prevents temporary XiP interruption and ensures real-time system performance.
Eliminating “Write Wait” with FeRAM
The simplest way to overcome flash limitations is to use FeRAM with a QSPI interface for data logging. FeRAM does not require erase cycles and supports high-speed overwrite at bus speed, meaning it never enters a “busy” state during writes. This allows true parallel execution of XiP instruction fetch and real-time logging, significantly simplifying RAM placement design.
File System Design and Data Integrity Best Practices
From a software perspective, using a power-failure-resistant file system and reducing write frequency are effective strategies. With flash, data must be buffered in RAM and written in batches, but with long-endurance FeRAM, near-immediate writes with minimal buffering are feasible. Combining this with journaling functions ensures data integrity while maintaining long-term reliability.
Efficient System Design Using QSPI
A “non-stopping system” requires memory mapping that accounts for physical constraints, along with the use of high-speed non-volatile memory such as FeRAM. By integrating software-based wait control with hardware-aware load distribution, it is possible to achieve both continuous instruction execution and real-time data recording.
Key Points for Achieving Both XiP and Logging
The core of the design lies in controlling the memory “busy state” and preventing conflicts with CPU instruction fetch. With flash, this requires software-based avoidance such as moving critical code to RAM. With FeRAM, the conflict is eliminated at the physical level, significantly reducing design effort. In systems where real-time performance is critical, selecting the right architecture based on device characteristics directly impacts both development time and reliability.
Technical Challenges and Countermeasures in Design
During operation, a key issue is millisecond-level bus occupancy caused by flash erase operations. To mitigate this, smoothing write frequency and carefully scheduling garbage collection are important. Even when using FeRAM, capacity and cost constraints remain. Therefore, a multi-slave configuration, where program code is stored in low-cost flash and frequent logging is handled by FeRAM, can maximize cost efficiency.
Future Outlook and Optimization Directions
Going forward, multi-bank flash supporting Read-While-Write and higher-capacity FeRAM will make logging in XiP environments more practical. Additionally, combining high-speed PSRAM on the QSPI bus as a temporary logging cache is evolving as a method to further reduce storage load. By integrating these emerging memory technologies, next-generation embedded systems can achieve higher performance and robustness.
RAMXEED Quad SPI-compatible FeRAM family
https://www.ramxeed.com/products/feram/s1.html
