SPI Flash: Die Hälfte der Bits sind Null

Ich habe einen STM32, der zwei sehr ähnliche SPI-Blitze antreibt, einen N25Q und einen M25P .

Während mein Treiber mit dem N25Q tadellos zurecht kommt, funktioniert der M25P seltsamerweise nur "halb". Was passiert ist, dass, wenn ich eine Seite mit Bytes schreibe und diese Seite zurücklese, die vier MSB-Bits jedes Bytes 0 sind und die vier LSB-Bits jedes Bytes korrekt sind.

Was könnte dazu führen, dass die Hälfte der Bits 0 sind?

Ist es ein von Ihnen geschriebener Treiber oder haben Sie ihn irgendwo hergenommen? Ich suche nach einem Treiberquellcode oder Beispiel für N25Q von STM32 und habe bisher nur diesen electronic.stackexchange-Thread gefunden. Ich denke jedoch, dass es für einige Benutzer hilfreich wäre, auf den Treiber hinzuweisen, die diese Fragen und Antworten hier finden. Es ist aber relevant. Danke.

Antworten (3)

Haben Sie die betroffenen Speicherseiten vorher gelöscht? Für Flash-Speicher können Sie nur 1 in 0 ändern (das M25P-Datenblatt von oben gibt dies ausdrücklich auf Seite 22 an, beim N25Q auf Seite 12). Wenn also der M25P vorher mit 0x0f's gefüllt wurde, würden Sie genau dieses Ergebnis erhalten. Wenn Sie für beide denselben Schreibbefehl (0x02) verwenden, sollte alles in Ordnung sein. Die Verwendung des Dual- oder Quad-Modus würde dazu führen, dass 2 (oder 4) Bits falsch sind, aber kein halbes Byte. Da Sie vermutlich eine ganze Seite programmieren, denke ich, dass dies keine steckengebliebenen Adressbits sein können. Andere Ursachen für das Problem könnten sein: fehlender Blockkondensator für den Flash-IC oder falscher SPI-Modus (was zu seltsamen Ergebnissen führen kann, da Sie normalerweise Daten genau in dem Moment lesen, in dem sie sich ändern). Letzteres kann mit einem Logikanalysator oder einem Oszilloskop überprüft werden.

Danke. Das war das Problem. Ist es also nicht möglich, zuverlässig in den Flash-Speicher zu schreiben, ohne zuerst einen Sektor zu löschen? Ziemlich teuer, wenn man bedenkt, dass das Löschen eines Sektors 1 Sekunde dauert ...
Das hat nichts mit Zuverlässigkeit zu tun – es ist einfach die Art und Weise, wie Flash-Speicher funktionieren. Sie können nur Bits löschen, aber das Setzen der Bits muss vorher durch Löschen erfolgen (insofern funktionieren sie wie ein EPROM). Aber es gibt einige Flash-Geräte, die diesen Lösch- und Schreibvorgang transparent für Sie erledigen (aber es wird nicht schneller).
Ich mag den Klang der Erfahrung in dieser Antwort. Ich frage mich, wie intelligent die intelligenten Flashcontroller zuvor gelöschte unbenutzte Sektoren rotieren, um langsame Schreibvorgänge bei Bedarf zu umgehen, und die Nutzung gleichmäßig rotieren, um virtuelle W/R-Vorgänge zu beschleunigen.
Vielleicht wird dies nur auf Soft- oder Firmware-Ebene für Out Of Memory (OOM)-Gruppierungen, Prioritäten und LowMemoryKiller, Defragmentierung im laufenden Betrieb ... durchgeführt. Die Sektorformatierungszeit ist eine so wertvolle Zeit, die es zu verschwenden gilt.
Diese Rotation ist AFAIK eine Firmware-Sache (deshalb gibt es immer einige Firmware-Fehler in diesen SSDs :) Die Notwendigkeit, Bereiche zu lesen, die Sie in den Speicher schreiben, sie löschen und dann neu schreiben müssen, ist der Grund, warum der Flash-Speicher währenddessen viel langsamer ist Schreibvorgang als für Lesevorgänge.

Ein offensichtlicher Grund ist, wenn Sie versuchten, Dual- und Quadraturdaten-Schnellschreibfunktionen zu verwenden, die für den N25Q entwickelt wurden und vom M25P nicht unterstützt werden. Aber ich vermute, das wissen Sie bereits.

Das ist eine gute Idee, aber ich verwende keine Dual- oder Quad-Daten.
Festsitzende Adressbits im Chip aufgrund eines Fehlers können Ihren Speicher dezimieren. Ist es funktionsfähig? Können Sie die Schnittstellensignale anhand der Chipspezifikation debuggen?

Haben Sie für die M25P eine andere Anzahl von Dummy-Bits eingestellt? Dies würde möglicherweise erklären, was Sie sehen, wenn Sie jeweils ein Byte zurücklesen.

SPI Flash: Die Hälfte der Bits sind Null
AntwortenHierDatenschutz-Bestimmungen1y, 0v