1
\$\begingroup\$

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.

\$\endgroup\$
1
  • \$\begingroup\$ The sensible way to do this would be to defer the low level access to flash as a filesystem to a compact routine executing from RAM or internal program flash. \$\endgroup\$ Apr 5, 2019 at 17:43

1 Answer 1

1
\$\begingroup\$

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).

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.