Schreibalgorithmus für Flashspeicher

[Klebwax]

Ich habe mir nun überlegt, daß nach Schreiben einer Seite auf den Flash die nächste Seite gelöscht werden muß. Diese Seite ist dann mit 264 Bytes des Wertes FFh beschrieben. Das nächste Gerät, das auf diesem Flash schreiben möchte, sucht diese gelöschte Seite, also nach den 264 FFh Bytes, schreibt darauf und löscht dann die nächste freie Seite und so fort.

Das klingt schon mal richtig gut. Wenn ich das jetzt richtig verstanden habe, wird immer ein Sektor nach dem anderen beschrieben. Der Speicher wird also vollkommen gleichmäßig benutzt, besser geht es nicht.

http://dangerousprototypes.com/blog/...royer-wrap-up/

Wenn nicht gerade das Leben von dem Teil abhängt, würd ich auf die 100.000 Zyklen nicht viel geben. Hier wurden die garantierten 1 Million Zyklen um das zehnfache übertroffen. Und das denk ich mal ist typisch, da amerikanische Anwälte an den Datenblättern mitschreiben.

MfG Klebwax

[Peter(TOO)]

Im Datenblatt steht dass alle 10'000 Zyklen eine Aufräumprozedur ausgeführt werden muss um die maximale Lebensdauer zu erhalten. Da sollten also 100'000 bis 1 Mio. drin liegen.

Das eigentliche Problem lieg in der Speicherzelle, welche die Quantenmechanik benutzt, genauer den Tunneleffekt.

Im Prinzip verwendet man einen MOS-Feldeffekt-Transistor bei welchem die Gate-Elektrode nicht angeschlossen wird (Floating-Gate). Über dieser Gate-Elektrode befindet sich, isoliert, eine weitere Elektrode, welche mit der Gate-Elektrode einen Kondensator bildet.

Bei einem ungeladenen Kondensator entspricht die Gate-Spannung der Steuerspannung.
Ist der Kondensator geladen, beträgt die Gate-Spannung die Steuerspannung minus der Spannung am Kondensator.
Wählt man die Werte richtig schaltet der MOS-FET im einen Fall durch und im anderen sperrt er.
Wichtig ist natürlich, dass die Isolation zwischen den Kondensatorplatten sehr gut ist, die Elektronen sollen möglichst über 10 Jahre nicht verloren gehen.

So weit so schön.
Das Problem ist nun, wie man Elektronen auf das Floating-Gate bekommt.
Hier hilft jetzt der Tunnel-Effekt, "heisse Elektronen" können die Isolation überwinden. Das Problem ist nun aber, dass diese heissen Elektronen auch Atome mit sich reissen und so Material von den Elektroden in die Isolation verschoben werden. Irgendwann ist die Isolation dann keine mehr und die Speicherzelle kaputt.

In den Anfängen (EPROM) konnte man um die 100 Programmierzyklen garantieren. Mit der Zeit hat sich das immer wieder um den Faktor 10 gesteigert und man liegt heute so bei 1 Mio. Zyklen. Bei den EPROMs hat man die Elektronen noch mit UV-Licht herausgeschossen und nur elektrisch programmiert. Später kamen dann die EEPROMs, welche auch elektrisch gelöscht werden konnten. Den Durchbruch schaffte dann die FLASH-Technologie.

Normalerweise sind bei entladenen Kondensatoren alle Bits auf "1" und für eine "0" muss der Kondensator geladen sein.
Beim Löschen werden alle Kondensatoren entladen. Löschen geht meistens nur Blockweise, weil sich sonst die Anzahl der benötigten Transistoren mehr als verdoppeln, bzw. die Speicherdicht halbieren würde.

Speicherzellen, welche "1" sind und bleiben, werden gar nicht programmiert. Ist eine Zelle bereits "0"n darf sie auch nicht programmiert werden, weil man sonst die doppelte Spannung auf dem Kondensator hätte.
Beim Programmieren werden also nur diejenigen Zellen abgenutzt, welche von "1" auf "0" programmiert werden und beim Löschen dienigen welche von "0" auf "1" gesetzt werden.
Man kann also bestehende Daten überschreiben, so lange die neuen Daten nur "1" zu "0" machen müssen. (Aus diesem Grunde hatte der BRK-Befehl früher bei vielen CPUs den Wert 0x00. Man konnte also ein programmiertes PROM nehmen und einen BRK-Befehl nachprogrammieren.)

Ein Trick für Zähler war es, ein Bitfeld mit "1" anzulegen und bei jedem Programmierdurchlauf ein weiteres Bit auf "0" zu setzen. Die Anzahl "0" zeigte dann an, wie oft bereits programmiert wurde. Im Speicherbereich dieses Bitfeldes wurde dann jede Zelle nur 1x programmiert und abgenutzt.

Heute hat man für Memory-Sticks und SSDs spezielle Controller, welche laufend Daten, welche sich selten ändern, in Bereiche Kopieren, welche schon mehr abgenutzt sind und die weniger benutzen Bereiche verwenden um neue Daten zu schreiben. Ausser dem Controller weiss dann keiner wo ein bestimmter Datenblock physikalisch auf den Chip abgelegt ist.

MfG Peter(TOO)

[Searcher]

Vielen Dank für eure tollen Antworten.

Wear Leveling ist wirklich das, was ich tun möchte. Die notwendigen Infos dazu sollen auf jeden Fall auf dem Flash selber vorhanden sein, da der Stick flexibel an verschiedene Geräten benutzt werden soll. Im Internet habe ich dazu jetzt genügend Infos gefunden, die mir aber allesamt mindestens eine Nummer zu groß für meine Anwendung sind; und sicher auch dementsprechend kompliziert zu implementieren sind.

Beim Surfen im Inet sah ich auch weitere relativ große und günstige RAM- und Flashspeicher, teilweise im DIP8 Gehäuse. Der RAM war zB bei sehr geringem Strom und hinunter bis zu nur einem Volt bestimmt gut pufferbar und unbegrenzt oft beschreibbar. Wäre eigentlich ideal für mich zum Datensammeln auf einem autonomen Fahrgestell und gleich danach Auswertung der Daten auf dem PC. Hab mich jetzt aber erstmal an dem, mir schon zur Verfügung stehenden nocost Flash verbissen

Ja, ein Sektor bzw eine Seite soll nach der anderen beschrieben werden. Wenn die letzte Seite erreicht ist, soll von vorne bei der ersten wieder weitergemacht werden. Als Schreib-/Lesezeichen dient dabei die gelöschte Seite. Das Auffinden der gelöschten Seite geht bei dieser Speichergröße für mich noch schnell genug und braucht während des Gebrauchs ja nur einmal am Anfang durchgeführt zu werden.

Ich brauche kein Filesystem. Falls Minimalangaben über die gespeicherten Daten oder über den Flash notwendig werden, könnte ich die relativ zu der gelöschten Seite ablegen. zB auf der folgenden Seite, die auch entsprechend verschoben werden könnte, wenn es mal notwendig sein sollte. Ich denke, daß ich in nächster Zeit nur ein bis zwei kByte pro Einsatz des Flashes brauche.

Wow, hoffentlich kann mich das Wissen um die internen Vorgänge im Flash jetzt nicht an der unvoreingenommenen Nutzung behindern Super Info! Auf jeden Fall werde ich die im Datenblatt angegebenen Schreibzyklen zu Flashspeichern nicht mehr so absolut nehmen. Auch die 13 Tage ununtebrochenen Schreiben-/Lesenkönnens des Flash Destroyers von der Dangerousprototypes Seite lassen mich leicht am Sinn des Wear Leveling für meinen Zweck zweifeln. Egal, jetzt habe ich da schon mal angefangen, finde es interessant, werde es durchziehen und beim nächsten Mal dann, hoffentlich spätestens bei Einsatz eines RAM-Speichers wie den oben erwähnten, darauf verzichten

Gruß
Searcher

[Peter(TOO)]

Hallo Searcher,

Wear Leveling ist wirklich das, was ich tun möchte. Die notwendigen Infos dazu sollen auf jeden Fall auf dem Flash selber vorhanden sein, da der Stick flexibel an verschiedene Geräten benutzt werden soll. Im Internet habe ich dazu jetzt genügend Infos gefunden, die mir aber allesamt mindestens eine Nummer zu groß für meine Anwendung sind; und sicher auch dementsprechend kompliziert zu implementieren sind.

Wenn du mit dem Fachenglisch zurecht kommst, kannst du nach alten Appnotes suchen, so 20-30 Jahre alt.
Damals gab es die heutigen Controller noch nicht und man musste das selbst per Software machen.

Zum 24C04 wurde damals eine Menge geschrieben. In den Anfängen hatten die eine Lebensdauer zwischen 1'000 und 10'000 Zyklen, heute stehen sie auch bei 1M.

MfG Peter(TOO)

[schorsch_76]

Um den "Master Record" zu schützen/schonen kannst du bsp. die ersten 16 Sektoren/Seiten reservieren. Die Seite 0, zeigt, welche der folgenden Seiten gerade genutzt wird. Nach x Zyklen wechselst du von "Filesystem Management" Seite 1 auf 2 ... 2 auf 3 ... usw. bis du wieder bei 1 bist. So verteilst du die Schreiblast des "Filesystems" auf 16 Seiten.

Die jeweilige aktive Seite, managt das "Filesystem". Belegte Sektoren, etc pp. Auch könnte hier hinterlegt werden wie oft schon auf welchen Block geschrieben wurde.

Die Seite 0 wird nur dann "belastet", wenn du die Seite bsp,. von 1 auf 2 springt.

Unter Linux wird bsp. UBIFS2 benutzt um auf "rohem" NAND Speicher zu arbeiten. Das was du hier hast
http://www.linux-mtd.infradead.org/doc/ubifs.html

Hier wird bsp. Beschrieben wie das Verteilen des schreiben prinzipiell funktioniert. Ab Seite 16/17 des PDFs wird es für dich sehr interessant sein. Ich denke aber dass due ruhig alles lesen kannst. Sind nur 50 Folien.
http://www.linux-mtd.infradead.org/doc/ubifs.pdf

[Ceos]

ich finde die Idee klasse, man teilt sozusagen die Fehlerwahrscheinlichkeit für den counter damit runter

die Anzahl Seiten für den Counter sollte dann idealerweise >= Anzahl an Runden im restlichen Flash sein ... die genutzten Flash Seiten würde ich für maximale Sicherheit eventuell noch doppelt nehmen und immer eine Kopie als Fallback mitführen. Halbiert zwar Grundsätztlich den Speicher bzw. die Lebensdauer aber führt zumindest nicht unmittelbar in einen Dead-Zustand sondern man kann vorwarnen dass mind. 1 Seite fehlerhaft ist

[schorsch_76]

Hier noch ein Paper der Universität Peking über Wear Leveling (auf englisch)
http://dbgroup.cs.tsinghua.edu.cn/li...11-lazyftl.pdf

[Searcher]

Da ist ja nochmal was zusammengekommen. Über die Überwachung des Speichers und Ersatzschaltung von schlechten Zellen habe ich mir bisher noch keine rechten Gedanken gemacht.

Um den "Master Record" zu schützen/schonen kannst du bsp. die ersten 16 Sektoren/Seiten reservieren. Die Seite 0, zeigt, welche der folgenden Seiten gerade genutzt wird. Nach x Zyklen wechselst du von "Filesystem Management" Seite 1 auf 2 ... 2 auf 3 ... usw. bis du wieder bei 1 bist. So verteilst du die Schreiblast des "Filesystems" auf 16 Seiten.

Fand ich auch gut und das Weiterspinnen des Gedankens. Scheint mir etwas für größere Speicher zu sein, bei denen eine Suche im ganzen Speicher nach einem "Filesystem" zu lange dauert. Muß ich mir zusammen mit den geposteten Links noch gründlicher ansehen. http://www.linux-mtd.infradead.org/doc/ubifs.html läßt sich im Augenblick nicht öffnen. (timed out)

Danke und Gruß
Searcher

PS. Englisch ist kein Problem für mich. Außer Deutsch alle anderen Sprachen und vor allem fernöstliche schon