QSPI für gemeinsam genutztes XiP und Dateisystem

Ist es möglich, dass ein Einzelchip-QSPI-NOR-Flash-Modul gleichzeitig für XiP und ein Dateisystem verwendet wird? Mit gleichzeitig meine ich, dass eine von XiP ausgeführte Funktion auf Daten an anderer Stelle auf XiP zugreift.

Die MCU ist in diesem Fall ein NXP Kinetis K8x (ARM Cortex M4), der über ein integriertes QSPI-Peripheriegerät verfügt. Das Symptom ist:

  1. Code, der vom internen Flash ausgeführt wird, kann problemlos auf das Dateisystem auf dem QSPI-Flash zugreifen.
  2. Code, der von einem externen Flash ausgeführt wird, der nicht auf das Dateisystem zugreift, wird problemlos ausgeführt.
  3. Code, der von einem externen Flash ausgeführt wird, der auf das Dateisystem zugreift, lässt das System hängen. Im Debugger sehe ich, dass das Busy-Bit des QSPI-Peripheriegeräts für immer gesetzt bleibt.

Kann jemand erklären, was los ist? Wird ein Dual-Die-Flash-Modul dieses Problem lösen? Sollte ich mir die QSPI-Peripherieeinstellungen ansehen?

===

Mehr Info:

So verwenden Sie Quad-SPI auf der KL8x-Serie: https://www.nxp.com/docs/en/application-note/AN5244.pdf

Ein Dual-Die-Flash-Modul wird nichts lösen, da beide Chips einen QSPI-Controller auf der MCU mit einem Satz Puffer usw. teilen.

Wenn ich speicherabgebildete Lesevorgänge für das Dateisystem verwende, wird natürlich derselbe interne Mechanismus verwendet, um sowohl Anweisungen als auch Daten abzurufen und zu puffern. Und das System hängt nicht.

Alles, was ich tun muss, ist, die Schreibfunktionen des Dateisystems zu isolieren und sicherzustellen, dass diese vom internen Flash oder als RAM-Funktionen ausgeführt werden.

Der vernünftige Weg, dies zu tun, wäre, den Low-Level-Zugriff auf Flash als Dateisystem auf eine kompakte Routine zu verschieben, die vom RAM oder internen Programm-Flash ausgeführt wird.

Antworten (1)

Ich weiß nichts speziell über das K8x, aber Sie haben ein allgemeines konzeptionelles Problem: Sie haben zwei Entitäten, die um den Zugriff auf die QSPI-Schnittstelle konkurrieren, den Befehlsdecoder und den Dateisystemcode.

Wenn Sie garantieren könnten, dass sie niemals gleichzeitig Zugriff benötigen, gäbe es kein Problem, aber Tatsache ist, dass der Befehlsdecoder jederzeit einen XIP-Abruf erfordern kann, selbst wenn der Cache verwendet wird. Wenn diese Anforderung während eines Dateisystemzugriffs auftritt, wird das System gesperrt.

Das Ändern von Einstellungen oder das Wechseln des externen Blitzmoduls hilft nicht. Der Engpass ist der QSPI-Controller selbst.

Wie Chris vorgeschlagen hat, besteht die Lösung darin, sicherzustellen, dass der gesamte Code, der für den Zugriff auf das Dateisystem erforderlich ist, NICHT direkt vom externen Flash-Modul ausgeführt wird. Kopieren Sie stattdessen den Dateisystemtreiber und alles, wovon er abhängt, in den internen Flash oder RAM (oder externen DDR-SDRAM).

QSPI für gemeinsam genutztes XiP und Dateisystem
AntwortenHierDatenschutz-Bestimmungen1y, 0v