QSPI for shared XiP and file system

Question

Is it possible for a single-die QSPI NOR flash module be simultaneously used for both XiP and a file system? By simultaneous I mean that a function running from XiP accesses data elsewhere on XiP.

The MCU, in this case, is an NXP Kinetis K8x (ARM Cortex M4), which has an onboard QSPI peripheral. The symptom is:

1. Code executing from internal flash can access the file system on QSPI flash without any problem.
2. Code executing from external flash that does not access the file system runs without a problem.
3. Code executing from external flash that accesses the file system hangs the system. In the debugger I see that the QSPI peripheral's busy-bit remains set forever.

Can anyone explain what's going on? Will a dual-die flash module solve this? Should I be looking at the QSPI peripheral settings?

===

More Info:

How to use Quad SPI on KL8x Series: https://www.nxp.com/docs/en/application-note/AN5244.pdf

A dual-die flash module won't solve anything, as both dies share one QSPI controller on the MCU, with one set of buffers, etc.

If I use memory-mapped reads for the file system, then, of course, the same internal mechanism is used to fetch and buffer both instructions and data. And the system does not hang.

So, all I need to do is isolate the file system write functions, and make sure that these run from internal flash, or as RAM functions.

Answer 1

I know nothing about the K8x specifically, but you have a general conceptual problem: You have two entities competing for access to the QSPI interface, the instruction decoder and the filesystem code.

If you could guarantee that they never need access simultaneously, there would be no problem, but the fact is that the instruction decoder can require an XIP fetch at any time, even when using cache. If that demand occurs during a filesystem access, the system will lock up.

Changing settings or changing the external flash module will not help. The bottleneck is the QSPI controller itself.

As Chris suggested, the fix is to make sure that all of the code required to complete any filesystem access is NOT executing directly from the external flash module. Instead, copy the filesystem driver and anything that it depends on into internal flash or RAM (or external DDR SDRAM).