Warum ändert sich die Sektorlöschzeit im neuen Nor-Flash, weil der Treiber nicht funktioniert?

Ich arbeite an einer Anwendung mit NOR-Flash-Chips. Ich musste die Chips mitten im Designprozess wechseln. Die angegebenen Unterschiede zwischen den neuen und alten Chips sind nur „Geräte-ID“ und „Sektor-Löschzeit“. Ich dachte, ich könnte angesichts der kleinen Unterschiede ohne Neuschreiben meines Flash-Treibers auskommen, aber der Treiber für den alten Chip funktioniert nicht mit dem neuen.

Warum ist die Sektorlöschzeit so wichtig für den Fahrer? Wie ändere ich es?

Wir benötigen mindestens die folgenden Informationen: alte/neue Flash-Chip-Teilenummern, für welche Plattform schreiben Sie den Treiber, können Sie uns den Treibercode zeigen, können Sie Datenblätter für die Chips bereitstellen?
Wenn Sie "mein Flash-Treiber" sagen, haben Sie das geschrieben? Hast du Quellcode dafür? Es sollte ziemlich einfach zu überprüfen sein, ob der Code nach der spezifischen Geräte-ID des älteren Chips sucht. Es ist sehr üblich, dass Software, die Flash verwaltet, Geräte-IDs explizit überprüft.

Antworten (2)

Die Sektorlöschzeit ist für jeden Treiber von Bedeutung, da es ein bisschen Timing ist, das notwendig ist, um den Chip richtig zu verwenden. Flash-Chips haben Löschzeiten , dh wie lange die spezielle Löschspannung an die Zellen angelegt werden muss, um sicherzustellen, dass sie gelöscht werden. Wenn diese Mindestzeit nicht eingehalten wird, werden die Zellen möglicherweise nicht vollständig gelöscht, was tatsächlich ein Datenfehler ist.

Einige Chips können auch eine maximale Löschzeit haben. Einige Chips erfordern die externe Hardware, um das Löschtiming durchzuführen, andere führen das interne Timing durch und setzen ein Statusbit, wenn das Löschen abgeschlossen ist. In diesem Fall müsste ein Treiber entweder die maximal mögliche Löschzeit abwarten oder das Bit abfragen, um sicherzustellen, dass das Löschen abgeschlossen ist, bevor er mit anderen Operationen fortfährt.

Wie bei jeder Spezifikation bedeutet eine Verletzung, dass auf keinen der anderen Parameter mehr Verlass ist. Wenn dieser Chip sich selbst löscht und nach Abschluss ein Bit setzt und der vorhandene Treiber dieses Bit abfragt, um den Abschluss des Löschvorgangs zu bestimmen, dann sollte keine Modifikation des Treibers erforderlich sein.

Auf jeden Fall ist es sehr, sehr schlechte Übung, zu denken, dass Sie mit der Verletzung einer Spezifikation "auskommen" können, nur weil sie nur ein wenig daneben liegt, und Sie sollten sich schämen, überhaupt darüber nachzudenken.

Wie viele Flash-Geräte haben Sie verwendet, bei denen sich die Software um das Löschtiming für etwas anderes als die Timeout-Bestimmung kümmern musste? Mir fällt nur eins ein: der interne Flash eines TI DSP. Jedes andere Flash-Gerät, an das ich denken kann, das ich jemals verwendet habe, hatte selbstgesteuerte Löschzyklen. Kennen Sie standardmäßige "eigenständige" Flash-Chips, die keine selbstgesteuerte Löschung haben?
Wahrscheinlich führen alle großen Flash-Chips ein internes Timing durch. Wenn Sie den Programmspeicher einiger PICs über einen externen Programmierer programmieren, muss der Programmierer in einigen Fällen das Timing durchführen. Oder es ist schneller, wenn der Programmierer dies tut und es genau tun kann, da der Chip in seinem Oszillator nachlässt, sodass die Nennzeit länger als erforderlich ist. Es gibt oft eine maximale Spezifikation für die interne Löschzeit, sodass ein Treiber möglicherweise sein eigenes Timing ohne Überprüfung vornehmen könnte.
Soweit ich gesehen habe, verließen sich die OTP-Teile von Microchip auf einen externen Programmierer, um Programmierimpulse zu timen, aber seine Flash-basierten Teile sind alle intern getaktet; Ich erinnere mich vage, dass einige Flash-basierte PICs es einem externen Programmierer möglicherweise ermöglicht haben, das Flash-Schreib-Timing zu steuern, erinnere mich jedoch nicht an einen Hinweis auf eine Kontrolle über das Flash-Lösch-Timing.
Übrigens, eine Funktion, an die ich mich vom DSP erinnere, die die Softwaresteuerung des Flash-Timings ermöglichte, war eine Funktion zur Auswahl einer von drei "Lese" -Schwellenwerten, damit die CPU Bits unterscheiden konnte, die vollständig gelöscht, größtenteils gelöscht, größtenteils programmiert oder vollständig programmiert waren . Man könnte somit bestimmen, ob ein Bereich des Speichers potentiell marginale Bits hat. Ich weiß, dass Fehlerkorrektur und Multi-Level-Flash bedeuten, dass die Konzepte, dass einzelne Bits "teilweise programmiert" sind, nicht im gleichen Sinne sinnvoll sind wie auf dem TI-Teil, aber ...
... es würde immer noch nützlich erscheinen, wenn Flash-Chips einen Hinweis darauf geben könnten, ob ein Teil eines Blocks geringfügig geschrieben wurde, als Hinweis darauf, dass Software versuchen sollte, Daten auf diesem Block an eine andere Stelle zu kopieren und dann, sobald die Kopie abgeschlossen ist, zu löschen und recyceln Sie den Block.

Sie haben keine Teilenummern erwähnt, aber die Hersteller von Flash-Chips haben im Laufe der Zeit verschiedene kleine Details zur Funktionsweise ihrer Chips geändert. Es ist möglich, dass Ihr Treiber einen Code hat, der die Geräte-ID verwendet, etwa "Wenn ID=dies, neue Methode verwenden, andernfalls Methode verwenden". Wenn der vorherige Chip eine "neue Methode" erforderte und der neue Chip eine andere ID hat, aber auch eine "neue Methode" erfordert, funktioniert der Code nicht, da versucht wird, die "alte Methode" zu verwenden. Es ist auch möglich, dass Ihr Code von einigen Details abhängt, wie das Gerät meldet, wenn es bereit ist. Wenn bei einigen alten Geräten Daten ausgestempelt und angehalten wurden, als das Gerät seinen „Bereit“-Status meldete, änderte sich der gemeldete Wert asynchron, wenn das Gerät den laufenden Vorgang beendete. Auf neueren Geräten

Ich stimme dem Geräte-ID-Bit zu. Meiner Erfahrung nach ist es SEHR üblich, dass Software Geräte-IDs explizit überprüft. Ich denke, es ist wahrscheinlicher, dass das Problem auf der Geräte-ID-Seite liegt als auf der Löschzeit ... obwohl alles möglich ist.