EEPROM- Lebensverlängerung
-
MisterX schrieb:
Könnte es sein, das du nur virtuelle Adressen siehst und es intern schon auf den gesamten Speicherbreich verteilt wird nach und nach?
In der Doc steht nichts dergleichen drin, weder in der alten, noch in der aktuellen, aaaber ...
+fricky schrieb:
^^es gibt hersteller, die garantieren, dass deren EEPROMS 1 million schreibzyklen wegstecken. vielleicht haste sowelche erwischt?
... implementiert hatte ich nach einem alten Datenbuch von Philips (kann man noch wenigstens aufs Klo mitnehmen), die Krümel auf dem Board stammen von ST. Die garantieren - tadaa - tatsächlich 1 Mio+.
+fricky schrieb:
eventuell sogenanntes 'wear leveling'. kannst ja mal danach googlen.
Wow, das ist aber aufwendig
. Ne, ich denke, wenn ich das primitivst simuliere, indem ich immer weiter ziehe (über drei Blocks), dürfte ich aus der Ecke niemals Probleme zu erwarten haben.
-
pointercrash() schrieb:
... fällt euch was Schlaueres ein ...
Ja, noch ein kleiner Tipp: Das Gerät soll ja "bloss" seine zwei Jahre funktionieren - ab da alles egal
-
Tim schrieb:
Nachteil bzw. Voraussetzung: Genügend Zeit im Brown-Out zum screiben/verifizieren/schreiben muss da sein.
klar, beschreiben von EEPROMs beim brown-out kann im prinzip immer danaben gehen, weil mehr energie benötigt wird, was die spannung noch schneller runterzieht. wenn's dumm läuft, schafft er nicht alles bits zu beschreiben, bits kippen nach kurzer zeit von selber um, oder der ganze chip gibt den geist auf. pc(): datenblätter gucken, rechnen, messen, oder im zweifelsfall 'nen 100µF kondensator dranlöten.
-
+fricky schrieb:
oder im zweifelsfall 'nen 100µF kondensator dranlöten.
Nimm doch gleich ne Autobatterie?
-
Tim schrieb:
Nimm doch gleich ne Autobatterie?
riesige mengen an blei und schwefelsäure? das ist doch niemals RoHS-konform.
-
Hallo Leute,
aaalso, ich hab' jetzt endlich eins kaputtgekriegt - nach 3,7 Mio Zugriffen.
abc.w schrieb:
Ja, noch ein kleiner Tipp: Das Gerät soll ja "bloss" seine zwei Jahre funktionieren - ab da alles egal
Kein guter Tip, weil nicht Consumerzeugs, sondern Anlagensteuerung mit erwünschter Laufzeit von 15 Jahren. Ich mach' mir deswegen Sorgen, weil Servicefälle extrem teuer werden, deswegen brauche ich ja auch das "Langzeitgedächtnis", das die Nutzung der Maschine protokolliert.
Tim schrieb:
Zur Lebenszeit/Zyklenzeit: Wenn die Hersteller 10000 Zyklen garantieren, kann man schon davon ausgehen, dass ein großer Teil der ICs deutlich mehr verkraften, die brauchen da ja genügend Luft nach unten.
Ja, so Faktor 5 - 10 ist da üblich, aber F80 hatte mich überrascht. Ich hab' die ganze Kiste zuletzt auch heftig übertaktet, weil ich Befürchtungen hatte, noch vor dem Teil zu sterben.
Tim schrieb:
Sprich du benutzt einen Sektor bis er am Ende ist. Hätte den Vorteil, dass man die Verbrauchtheit ein wenig abschätzen könnte. Nachteil bzw. Voraussetzung: Genügend Zeit im Brown-Out zum screiben/verifizieren/schreiben muss da sein.
Hab' mich jetzt in Forensik versucht und mit dem beschädigten Teil herumgespielt. Ich kann in dem ganzen Block der dauerbeschriebenen Zelle kein einziges Byte mehr korrekt ändern (Bit 2 hängt auf 'Hi' fest), nur noch Auslesen geht. Die anderen Blocks funktionieren weiterhin.
Bringt mich zu der Überlegung, immer zwei Blocks zu beschreiben und die Integrität durch CRC oder sowas zu sichern.+fricky schrieb:
klar, beschreiben von EEPROMs beim brown-out kann im prinzip immer danaben gehen, ...
Hehe, erinnert mich an einen Bug der ersten AVRs mit internem EEP. Da konnte es passieren, daß durch Querströme an den Pins die Schreibautomatik angegangen ist, obwohl der Prozessor schon längst "tot", also jenseits seines Shutdowns war, desgleichen beim Einschalten mit einer Stromquelle, die nicht schnell genug "hochkam". Die Dinger wurden liebevoll "Alzheimer- Boards" genannt.
Tim schrieb:
Nimm doch gleich ne Autobatterie?
Aber nur, wenn sie schaltfest ist
Im Ernst, hat noch nie geschadet, 'ner CPU 'nen 10er Tantal- Böppel als "Notration" mitzugeben ...
-
pointercrash() schrieb:
Bringt mich zu der Überlegung, immer zwei Blocks zu beschreiben und die Integrität durch CRC oder sowas zu sichern.
ich kann mich an eine ähnliche anwendung erinnern, wobei ein sekundenwert bei jeder änderung in 'nem i2c-eeprom gespeichert wurden. jeder wert hatte dabei einen eigenen zähler für schreibzugriffe. sobald ca. 90% der vom hersteller erlaubten schreibzyklen erreicht waren, wurde einfach stumpf weitergeschaltet. bei 'ner anfangskapazität von 2K intaktem speicher, versprach diese einfache lösung eine funktionsdauer von etwas über 30 jahren.
-
+fricky schrieb:
... sobald ca. 90% der vom hersteller erlaubten schreibzyklen erreicht waren, wurde einfach stumpf weitergeschaltet. bei 'ner anfangskapazität von 2K intaktem speicher, versprach diese einfache lösung eine funktionsdauer von etwas über 30 jahren.
Das ist ähnlich der Tim- Methode.
Das Ding kann ja nur in einem Block nicht mehr schreiben (wahrscheinlich ist ein Linedriver col durch). Ich kann jetzt nichtmal sagen, ob das typisch ist, weil ich das Teil echt verheizt habe. Deswegen lasse ich das zweite gerade auch noch kaputtgehen - innerhalb der Specs. Vielleicht geht ja nur eine Zelle drauf.
Wenn das Desaster auf das Lesen eigentlich keinen Einfluß hat, ist ja eine "Einblocklösung" völlig ausreichend, egal, ob man beim ersten Kaputtgehen weiterschaltet oder bei 90% der garantierten Schreibzugriffe.Klappt hingegen das Lesen nicht mehr, wäre beides unzureichend. Ich denke, ich mach' das so, daß ich in zwei Blöcken Buch führe und ab den 90% einfach um zwei weiterschalte. Ich hab's noch nicht durchgerechnet, bin mir aber ganz sicher, damit weit über die 15 Jahre hinauszukommen.
-
pointercrash() schrieb:
Das ist ähnlich der Tim- Methode.
nee, der vorteil ist, dass nie was kaputtgeht, weil keine zelle öfter als erlaubt beschrieben wird. so musste dir z.b. keine gedanken um benachbarte blöcke u.ä. machen. wenn das eeprom nach ~30 jahren 'voll' ist, hat es zwar ganz schön gelitten, ist aber noch voll funktionsfähig.
-
Für die, die es interessiert:
Also, ich habe nunmehr beide EEPROMs restlos zerstört , eins davon ist einfach blockweise kaputtgegangen (mit immer noch funktionierendem readout), letzter Block bei fast 30 Mio (Schreib-) Zugriffen.
Das zweite hat bei etwas über 20 Mio Schreibzugriffen den Betrieb vollständig eingestellt (nur noch $FF auslesbar), rein theoretisch waren da aber vorher noch 6 Blocks lesbar, I2C Interface tut noch.
Das ist zwar nur exemplarisch (hab' nicht die Zeit und Hardware, ein paar Stangen zu vernichten), aber kein einziges mal gab es auf nur eine einzelne Zelle (Byte) eingeschränkte Fehler.
Der Schreibbetrieb fiel blockweise oder entweder total bzw. der Lesebetrieb total (kann ich so nicht unterscheiden) aus.
Also liegt die Vermutung nahe, daß bei gesicherten 1 Mio Zugriffen eher die "Data Retention Time" mit 40 Jahren zuschlagen würde. Ich beschreibe einfach zwei Blocks parallel und schalte nach 50% Lebensdauer um 2 Blocks weiter - basta.Also, wenn die Neandertaler das schon so gemacht hätten, könnte die Anlage theoretisch heute wohl noch leben ...
-
Ich würde nach dem Schreiben immer einen Block weiter gehen. Jeder Block hat dann noch ein Bit damit man weiß welcher Block zuletzt beschrieben wurde. Also beim ersten Beschreiben von 0 auf 1 und wenn der Block wieder erreicht wird von 1 auf 0. Dann eine Variable im SRAM welcher der letzte Block war. Man muss dann nur einmalig beim Einschalten suchen welcher der letzte Block war. So nutzen sich alle Blöcke gleichmäßig ab. Und wenn man es noch richtig übertreiben will kann man einen Block reservieren wo abgespeichert wird welche Blöcke defekt sind, damit sie ignoriert werden.