Schreibalgorithmus für Flashspeicher

Hallo,

ich möchte einen Flashspeicher, den ich auf einer defekten Festplatte gefunden habe und der eine SPI Schnittstelle besitzt, zum Datensammeln flexibel einsetzen. Dazu habe ich einen SPI-Stick gebastelt, den ich im Augenblick auf einem Steckbrett von einem ATmega88PA aus ausprobiere.

Der Flashspeicher ist ein 45DB041B, etwa 500kByte groß. Datenblatt:http://www.atmel.com/Images/doc3443.pdf, Application note AN-4

Die Speicherstellen des Flashes sind nur für eine beschränkte Anzahl von Schreibvorgängen benutzbar, oft so im Bereich von 100000 mal. Ich konnte für diesen Flash keine Angabe darüber finden und weiß im Augenblick auch nicht ob ein Löschen und Wiederbeschreiben als zwei Schreibvorgänge zählen.

Um den Flash schonend zu nutzen, möchte ich die Speicherstellen, die in Seiten (pages) von je 264Bytes organisiert sind, reihum beschreiben. Also SPI-Stick einstecken und Seite 0 beschreiben. SPI-Stick abziehen und beim nächsten Mal Seite 1 beschreiben.

Dazu müßte man sich irgendwie merken, welche Seite zuletzt beschrieben wurde. Da der Stick aber irgendwo eingesetzt werden kann, müßte diese Information auf dem Stick selber gespeichert werden, was aber eine überproportionale Belastung für diese Speicherstelle gegenüber den anderen Speicherstellen darstellen würde.

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.

Dazu habe ich eine Routine geschrieben, die ein Gerät benutzten soll um solch eine gelöschte Seite zu suchen. Dauert maximal so etwa 270ms bei den 2048 seiten, wenn es die letzte wäre. (etwa 620kHz SPI Takt bei 8 MHz µC Takt)

Mal abgesehen davon, ob es für mich, außer durch Programmfehler, im Bereich des Möglichen liegt, die 100000 Schreibvorgänge zu erreichen ohne zu wissen wieviel die Festplatte schon schon an Kredit aufgezehrt hat, jetzt endlich die Frage :-) : Wie vermeidet man das Beschreiben immer der gleichen Speicherstellen und sorgt für eine gleichmäßige Belastung?

Gruß
Searcher

Hallo,
da hast du ja einiges an Arbeit reingesteckt.
Wie es aussieht suchst du nach dem Begriff Wear Leveling.
Da gibt es verschiedene Verfahren, um die Speicherzellen gleichmäßig abzunutzen, kenne mich aber nicht genauer aus.

In deinem Fall könnte man noch eine relativ einfache Lösung in Betracht ziehen:
Der ATmega88 hat intern ja auch noch EEPROM, da genügen ja 2 Bytes, in denen man die nächste zu schreibende Page ablegt.
Da EEPROM nichtflüchtig ist, bleiben die Daten es auch ohne Versorgungsspannung vorhanden.
Allerdings muss man glaube ich die EESAVE Fuse umstellen, damit beim Übertragen eines neuen Programms auf den ATmega der Inhalt nicht gelöscht wird.

Dennoch wird man quasi nie die 100000 Zyklen erreichen ;)

Viele Grüße,
Bernhard

Zitat:

---

Zitat von Searcher

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

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)

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 :-k 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 :cool: 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 :confused:

Gruß
Searcher

Hallo Searcher,

Zitat:

---

Zitat von 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)

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

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

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

Richtig, man kann auch wichtige Felder mehrfach (redundant) abspeichern.
Beim Lesen macht man dann z.B. eine Mehrheitsentscheidung, also z.B. 2 aus 3 oder 3 aus 5 gelesenen etc...
Das kann ja auf mehrere Pages verteilt werden. Oder auf mehrere ICs. Ein kleines RAID :D
Grüße, Bernhard

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.

Zitat:

---

Zitat von 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.

---

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