Grund für begrenzte Anzahl Writes bei EEPROMs

Hallo zusammen,

es wird etwas länglich und ich hoffe, dass hier jemand jemanden kennt der jemanden kennt der was weiß…

Für einen Zähler, dessen Stand im EEPROM eines µCs mitgeführt wird, muss ich mich ernsthaft mit der Lebensdauer von EEPROMs befassen.

Die Hauptfrage ist, ob
a.) das Setzen eines einzelnen(!) Bits eines Bytes (Bit -> 0) unschädlich für dieses Bit ist, oder ob
b.) beim Setzen eines einzelnen(!) Bits eines Bytes (Bit -> 0) nur dieses eine Bit „leidet“, oder ob
c.) beim Setzen eines einzelnen(!) Bits auch alle anderen Bits in Mitleidenschaft gezogen werden.

Außerdem d.), e.) und f.) wie vor, aber für das Löschen von Bits (Bit -> 1).

Bei einem Kilometerzähler in einem Autotacho (geschätzte Lebensdauer: ca. 10^7 x 100 Meter) lernte ich folgendes Verfahren: Die untersten 7 Bit des Zählers werden durch 16 Byte = 128 Bit repräsentiert. Jede 100 m wird ein weiteres Bit davon auf 0 gesetzt. Nach 12,8 km sind alle 128 Bit auf 0, aber jedes Bit wurde nur einmal auf 0 gesetzt. Jetzt werden entweder alle 16 Byte zu FFh gelöscht, oder es werden der Reihe nach alle Bits einzeln gelöscht - das weiß ich nicht. Nach 12,8 bzw. 25,6 km kann dann ein echter Zähler inkrementiert werden. Also kippt jedes Bit pro 12,8 oder 25,6 km nur zwei Mal um, davon einmal setzen, einmal löschen. Wenn das z. B. 100 k mal passieren darf, sind das über 10^7 km.

Meine Vermutung ist, das einzelnes Setzen gänzlich unschädlich ist (Annahme a.) und Löschen eines Bits auch alle anderen in Mitleidenschaft zieht (Annahme f.).

Auch mein (Betriebszeit-)Zähler bzw. die EEPROM-Zellen sollen bis ca. 10^7 (10 Millionen) Zählerstände mit Sicherheit durchhalten. Die Anzahl der Schreibzyklen ist mit 100 k angegeben.

Es wäre als am sinnvollsten, Bits einzeln auf 0 zu setzen und dann byteweise auf 1 zu löschen.

Wer bis hierhin noch alles verstanden hat, der sei schon mal gelobt.

Vielen Dank, Uwe

PS: Ich will lediglich mehr über EEPROMs wissen. Die Hardware steht, deshalb bitte keine Tipps, alles ganz anders zu machen. Die helfen nicht und ich wüsste sie auch selber.

Wer bis hierhin noch alles verstanden hat, der sei schon mal
gelobt.

Hallo Uwe,

sehr vermutlich hast du da einen kleinen Gedankenfehler. Denn nach meiner Logik kippen beim Übergang von z.B. 7 auf 8 vier Bits, und nicht nur eins.

0111 ==> 1000

Bei jedem Schreibvorgang werden einige Atome anders strukturiert. Man hat zwar keinen Materialverlust, aber irgendwann werden die Atome, ich sage es mal ganz salopp, zu faul, sich noch mal zu bewegen oder man braucht eine höhere Spannung.

Man kann das verhindern, zumindest verzögern, wenn man den Befehl F9 oder C3? (glaube ich mich zu erinnern) benutzt. Damit setzt man einen Anhang im freien, frischen Bereich am Ende des Programmes.

Ich hatte keine Lust meine (auf Leinen gedruckte) Befehlstabelle herauszusuchen. Weiss gar nicht mehr wo die ist.

Warum fragst du nicht im Brett Programmierung (unter Computer) die Spezis?

Noch etwas ist mir aufgefallen: 10^7 x 100 Meter, das sind doch gerade mal 100.000 km.

Schönen Gruß
Termid

Hallo Termid,

sehr vermutlich hast du da einen kleinen Gedankenfehler. Denn
nach meiner Logik kippen beim Übergang von z.B. 7 auf 8 vier
Bits, und nicht nur eins.

0111 ==> 1000

Ich beschreibe keinen Binärzähler. „Mein“ Zähler kann nur so viele unterschiedliche Zustände einnehmen, wie er Bits hat. Mit 128 Bits kann er also nur bis 128 zählen. (Natürlich ist nicht der ganze Zähler so aufgebaut, sondern nur eine Art „Vorteiler“.)

Bei jedem Schreibvorgang werden einige Atome anders
strukturiert. Man hat zwar keinen Materialverlust, aber
irgendwann werden die Atome, ich sage es mal ganz salopp, zu
faul, sich noch mal zu bewegen oder man braucht eine höhere
Spannung.

Schade, dass ergibt keinerlei Bestätigung oder Widerlegung meiner 6 Annahmen…

Man kann das verhindern, zumindest verzögern, wenn man den
Befehl F9 oder C3? (glaube ich mich zu erinnern) benutzt.
Damit setzt man einen Anhang im freien, frischen Bereich am
Ende des Programmes.

Wo kommt so was vor? Bei FLASH? Ich spreche von EEPROMs, die kennen nur Read und Write.

Warum fragst du nicht im Brett Programmierung (unter Computer)
die Spezis?

Weil das weiß Gott eine reine Hardwarefrage ist.

Noch etwas ist mir aufgefallen: 10^7 x 100 Meter, das sind
doch gerade mal 100.000 km.

10^7 = 10 Million. 10 Millionen x 0,1 km = 1 Million Kilometer(?).

Viele Grüße, Uwe

Hallo,

Für einen Zähler, dessen Stand im EEPROM eines µCs mitgeführt
wird, muss ich mich ernsthaft mit der Lebensdauer von EEPROMs
befassen.

das Thema hatte ich im Laufe der Jahre auch imer wieder mal, weil
die Zyklenzahl von EEPROM-Zellen nun mal begrenzt ist.
Also muß man sich immer überlegene, wie man ein Programmablauf schreibt,
um nicht Zellen tot zu schreiben bzw. tot zu löschen.

Welche Zugriffe nun für die Zellen kritischer sind und welche eher
unkritisch, kann ich nicht genau sagen. Fakt ist, dass die Information
durch Eintunneln von Ladungen in vergrabene Strukturen erfolgt
(floating gates). Wenn eine Zelle beschrieben ist, muß man wieder
löschen, um neue Infos reinzubringen. Löschen und schreiben hängen
also mehr oder weniger direkt zusammen.

Jedes Speichern und auch jedes Löschen bewirkt eine Verschlechterung
der Struktur, so daß die Ladungen irgend wann nicht mehr gehalten
werden können. Dann kippt eine solche Zelle von ursprünglich 1 auf 0um.

Das äußert sich dann so, dass die Zelle nicht mehr gelöscht werden
kann, weil dabei ja das floating Gate aufgeladen wird.
Kann natürlich auch passieren, das es zwar noch aufgeladen wird, aber
dann nach einiger Zeit doch die Ladung verliert.

Die Hauptfrage ist, ob
a.) das Setzen eines einzelnen(!) Bits eines Bytes (Bit -> 0)
unschädlich für dieses Bit ist, oder ob
b.) beim Setzen eines einzelnen(!) Bits eines Bytes (Bit -> 0)
nur dieses eine Bit „leidet“, oder ob
c.) beim Setzen eines einzelnen(!) Bits auch alle anderen Bits
in Mitleidenschaft gezogen werden.

Ich denke, nur das Bit welches wirklich angesteuert wird, wird auch
strapaziert.

Außerdem d.), e.) und f.) wie vor, aber für das Löschen von
Bits (Bit -> 1).

Werden EEPROM nicht soweiso byteweise gelöscht? Da macht IMHO die
Betrachtung von Einzelbits nicht so viel Sinn, oder?

Bei einem Kilometerzähler in einem Autotacho (geschätzte
Lebensdauer: ca. 10^7 x 100 Meter) lernte ich folgendes
Verfahren: Die untersten 7 Bit des Zählers werden durch 16
Byte = 128 Bit repräsentiert. Jede 100 m wird ein weiteres Bit
davon auf 0 gesetzt. Nach 12,8 km sind alle 128 Bit auf 0,
aber jedes Bit wurde nur einmal auf 0 gesetzt.

Das scheint mir eine durchaus schonende Lösung.
Ich denke auch, nur die Bits welche tatsächlich von 1 auf 0
runter gezogen werden, machen da eine Strapaze durch.

Jetzt werden
entweder alle 16 Byte zu FFh gelöscht, oder es werden der
Reihe nach alle Bits einzeln gelöscht - das weiß ich nicht.

Bin nicht sicher, aber Bit einzeln löschen ist wohl nicht.

Nach 12,8 bzw. 25,6 km kann dann ein echter Zähler
inkrementiert werden. Also kippt jedes Bit pro 12,8 oder 25,6
km nur zwei Mal um, davon einmal setzen, einmal löschen. Wenn
das z. B. 100 k mal passieren darf, sind das über 10^7 km.

Ja, aber die 100k Schreib/Lesezyklen sind ein Wert, den ich in Praxis
nicht ausnutzen würde. Das sind statistische Ausfälle mit Sicherheit
vorprogrammiert.

Meine Vermutung ist, das einzelnes Setzen gänzlich unschädlich
ist (Annahme a.) und Löschen eines Bits auch alle anderen in
Mitleidenschaft zieht (Annahme f.).

Löschen ist zumindest eine Stapaze für die Zellen. Aber ich würde mich
nicht drauf verlassen, dass schreiben gänzlich unschädlich ist.
In beiden Fällen müssen die Ladungsträger durch die Isolierschicht tunneln.
Ist aber auch eigentlich egal, weil schreiben und löschen sich immer
abwechseln müssen.

Auch mein (Betriebszeit-)Zähler bzw. die EEPROM-Zellen sollen
bis ca. 10^7 (10 Millionen) Zählerstände mit Sicherheit
durchhalten. Die Anzahl der Schreibzyklen ist mit 100 k angegeben.
Es wäre als am sinnvollsten, Bits einzeln auf 0 zu setzen und
dann byteweise auf 1 zu löschen.
Wer bis hierhin noch alles verstanden hat, der sei schon mal gelobt.

Für eine Datenaufzeichnung auf EEPROM haben wir das z.B. so gelöst,
dass zwar wie üblich sequenziell die Daten eingeschrieben werden,
aber nicht wie üblich ein Zähler im EEPROM mit läuft, der dann
natürlich schnell an die Grenzen kommen würde.
Statt dessen wird immer in der letzten Zelle eine Endekennung (EoF)
eingetragen. Bei jedem Schreibvorgang wird das EoF also gelöscht und
der Messwert eingeschrieben und dann EoF eine Pos. weiter geschrieben.
So werden über den benutzten Speicherraumraum die Zellen
gleichmäßig wenig belastet. Beim jedem Neustart muß natürlich
dann das EoF gesucht werden.
Wenn du dass also z.B. mit 200 Speicherplätzen machst, hast du die
Schreibzahl der Zellen um Faktor 100 reduziert.
Andere Methoden, die den Speicher quasi umlaufend benutzen sind
gibt es einige.
Gruß Uwi

Hallo,

a.) das Setzen eines einzelnen(!) Bits eines Bytes (Bit -> 0)
unschädlich für dieses Bit ist, oder ob

Du hast da einen Fehler drin: die Dinger haben eine Löschlogik, die auf jeden Fall das Byte erstmal löscht, bevor es neu geschrieben wird. Je nach internem Aufbau kann man nämlich beim Löschen nur Nullen erzeugen und beim Schreiben nur Einsen oder umgekehrt.
Und es kommt hinzu, dass immer Blöcke oder Zeilen oder Spalten gelöscht werden, so dass auch beim ändern einer Zelle immer mehrere Zellen gelöscht und neu beschrieben werden. Wobei niemand außer dem Hersteller weiß, wie die Zellen ‚sortiert‘ sind.
Wenn man die Anzahl der Zyklen erhöhen möchte, muss man mehrere Zellen über den ganzen Baustein verteilt verwenden. Beim Schreiben fängt man hinten in der Reihenfolge dieser Zellen an zu prüfen, wenn dort eine 0 drinsteht, ist sie noch unbenutzt. Bis man die erste Zelle findet, die einen Inhalt ungleich Null hat. Diese wird ausgelesen, um ein erhöht, neu geschrieben und dann der Inhalt geprüft. Falls er richtig war, ist alles klar, sonst muss man die nächste Zelle in der Reihenfolge verwenden.
Und bei der Auswahl der Zellen drauf achten, dass sie nicht irgendwie logisch zusammen hängen und jeweils gleichzeitig gelöscht werden.

Übrigens geben die Hersteller eine niedrigere Anzahl von Schreibzyklen an als tatsächlich nutzbar. Und es gibt verschiedene Hersteller mit unterschiedlich großen Angaben an dieser Stelle.

Gruß
loderunner

Hallo Uwi,

erstma Danke,

Ich denke, nur das Bit welches wirklich angesteuert wird, wird
auch strapaziert.

Hmmm - beim Setzen oder auch beim Löschen?

Außerdem d.), e.) und f.) wie vor, aber für das Löschen von
Bits (Bit -> 1).

Werden EEPROM nicht soweiso byteweise gelöscht? Da macht IMHO
die Betrachtung von Einzelbits nicht so viel Sinn, oder?

Genau. Deswegen nehme ich an, dass auf 8 Setzvorgänge je ein Löschvorgang, der alle 8 Bit löscht, kommt. Aber ich habe keinen Beleg dafür, dass das im Tacho so war.

Ich denke auch, nur die Bits welche tatsächlich von 1 auf 0
runter gezogen werden, machen da eine Strapaze durch.

Das würde sich mit der Erkenntnis decken, die ich aus dem Tacho meine, gewonnen zu haben. Ich bin mir aber nicht ganz 100%, ob ich das richtig verstanden habe.

Ja, aber die 100k Schreib/Lesezyklen sind ein Wert, den ich in
Praxis nicht ausnutzen würde. Das sind statistische Ausfälle mit
Sicherheit vorprogrammiert.

In der Praxis wird mein Zähler vermutlich auch nur täglich im Mittel 12 Stunden, also 4000 Stunden im Jahr, also 100000 Stunden in 25 Jahren zählen müssen, aber so lange wird das Gerät nicht leben. Den Rest nehme ich als Reserve.

Ist aber auch eigentlich egal, weil schreiben und löschen sich
immer abwechseln müssen.

Hmmm - Der Trick ist ja, 8 Bit einzeln zu schreiben (setzen), bevor einmal alle 8 Bit gelöscht werden, also nicht abwechselnd.

Für eine Datenaufzeichnung auf EEPROM haben wir das z.B. so
gelöst, …

Ja, das ist eine nahe liegende Idee. Ähnlich läuft es ja mit den einzeln zu setzenden Bits, bei denen nicht nur in einem, sondern zyklisch in 16 Byte jedes Bit einzeln gesetzt wird.

Grüße Uwe

Hallo loderunner,

Du hast da einen Fehler drin: die Dinger haben eine
Löschlogik, die auf jeden Fall das Byte erstmal löscht, bevor
es neu geschrieben wird.

Das wäre zu befürchten. Je nach „Intelligenz“ der Schreiblogik erkennt das EEPROM aber vielleicht, dass Bits lediglich zu setzen, aber nicht zu löschen sind. Anderenfalls hätten die Entwickler des Tachos Unsinn gemacht. Vielleicht hängt das aber auch vom EEPROM-Hersteller ab, und dann wird’s gemein…

Und es kommt hinzu, dass immer Blöcke oder Zeilen oder Spalten
gelöscht werden, so dass auch beim ändern einer Zelle immer
mehrere Zellen gelöscht und neu beschrieben werden.

Das wäre eine Katastrophe. Dass das bei FLASHs so ist, weiß ich, aber auch bei normalen EEPROMs?

Wenn man die Anzahl der Zyklen erhöhen möchte, muss man
mehrere Zellen über den ganzen Baustein verteilt verwenden.
Beim Schreiben fängt man hinten in der Reihenfolge dieser
Zellen an zu prüfen, wenn dort eine 0 drinsteht, ist sie noch
unbenutzt. Bis man die erste Zelle findet, die einen Inhalt
ungleich Null hat. Diese wird ausgelesen, um ein erhöht, neu
geschrieben und dann der Inhalt geprüft. Falls er richtig war,
ist alles klar, sonst muss man die nächste Zelle in der
Reihenfolge verwenden.
Und bei der Auswahl der Zellen drauf achten, dass sie nicht
irgendwie logisch zusammen hängen und jeweils gleichzeitig
gelöscht werden.

Hmmm… Hast du einen Beleg, z. B. eine Application Note dazu, oder bist du dir sicher, so was mal im Original (nicht als Vermutung von jemand anderem) kennen gelernt zu haben?

Grüße, Uwe

Hallo,

Ich denke, nur das Bit welches wirklich angesteuert wird, wird
auch strapaziert.

Hmmm - beim Setzen oder auch beim Löschen?

das kann ich dir jetzt auch nicht sagen.
Ich denke aber dass zumindst bei jedem Pegelwechsel eine volle
Belastung auf die Zele zukommt.
Ob z.B. ein Bit, das noch auf 1 steht trotzdem beim Löschen
strapaziert wird und wenn ja , wie srakt, weiß ich auch nicht?
Ich nehme aber, mal an, das damit zu rechnen ist, weil eben nicht
selektiv gelöscht wird. Die Löschspannung wird also sicher auch
wirken, wenn das Bit noch auf 1 steht.

Außerdem d.), e.) und f.) wie vor, aber für das Löschen von
Bits (Bit -> 1).

Ich denke auch, nur die Bits welche tatsächlich von 1 auf 0
runter gezogen werden, machen da eine Strapaze durch.

Das würde sich mit der Erkenntnis decken, die ich aus dem
Tacho meine, gewonnen zu haben. Ich bin mir aber nicht ganz
100%, ob ich das richtig verstanden habe.

Im Zweifelsfall müßte man das sowieso am konkreten Typ fest machen.
Dann kann man das auch mal per Test überprüfen, indem man eben
mal paar Chips mit dem einem Modus und parallel mit dem anderen Modus
beaufschlagt. So was sollte max. paar Stunden bis Tage dauern.
Wenn du dann z.B. bis 1 Mio. kommst, bis du gut im grünen Bereich.

Ist aber auch eigentlich egal, weil schreiben und löschen sich
immer abwechseln müssen.

Hmmm - Der Trick ist ja, 8 Bit einzeln zu schreiben (setzen),
bevor einmal alle 8 Bit gelöscht werden, also nicht abwechselnd.

Schon klar, aber auf einzelne Bit bezogen wird eben doch abwechselnd
geschrieben und gelöscht.
Dass du die Bits sequenziell nutzt, ist ja nur eine Variante der
Methode, die ich auch schon beschrieben habe.
Wenn du z.B. nicht nur 128 Bit nimmst, sondern z.B. 1024 Bit,
hast du nochmal eine deutliche Verringerung der Zyklenzahl.

Für eine Datenaufzeichnung auf EEPROM haben wir das z.B. so
gelöst, …

Ja, das ist eine nahe liegende Idee. Ähnlich läuft es ja mit
den einzeln zu setzenden Bits, bei denen nicht nur in einem,
sondern zyklisch in 16 Byte jedes Bit einzeln gesetzt wird.

Klar, aber ob man das mit Bits oder mit Bytes oder größeren
Einheiten macht, ist ja eigentlich egal. Entscheidend ist ja nur,
dass die Zyklenzahl für jede benutzte Zelle niedrig genug bleibt.
Gruß Uwi

Hallo,

Je nach „Intelligenz“ der Schreiblogik
erkennt das EEPROM aber vielleicht, dass Bits lediglich zu
setzen, aber nicht zu löschen sind. Anderenfalls hätten die
Entwickler des Tachos Unsinn gemacht.

Ist halt einfacher so. Die Dinger haben ja nur ein Paar Gatter und keinen Microcontroller drin.

Und es kommt hinzu, dass immer Blöcke oder Zeilen oder Spalten
gelöscht werden, so dass auch beim ändern einer Zelle immer
mehrere Zellen gelöscht und neu beschrieben werden.

Das wäre eine Katastrophe. Dass das bei FLASHs so ist, weiß
ich, aber auch bei normalen EEPROMs?

Was genau meinst Du mit ‚normalen EEPROMs‘? Die seriellen I2C-ansteuerbaren Dinger? Bei denen ist es genau so wie von mir beschrieben.

Hmmm… Hast du einen Beleg, z. B. eine Application Note dazu,
oder bist du dir sicher, so was mal im Original (nicht als
Vermutung von jemand anderem) kennen gelernt zu haben?

Ich habe damals als Entwickler bei Schneider TV mit ein paar Vertretern darüber gesprochen. Ich wollte damals die Lautstärke etc. einer Stereoanlage mit Drehgeber statt Poti auch über das Ausschalten hinaus in einem 24C02 abspeichern. Und die wird halt relativ oft vom Benutzer verstellt, also muss man sich überlegen, ob man jede Änderung abspeichern darf. An eine ApplicationNote dazu kann ich mich nicht erinnern, aber da würde ich mal bei Microchip nach suchen - die habe einiges in dieser Richtung.
Gruß
loderunner