Moin, Vor längerer Zeit testete ich einen PIC16F877A aus gegebenen Anlaß um herauszufinden wieviele Schreibzyklen im EEPROM tatsächlich ausgehalten werden können. (Nur für Hobby Anwendungen von Interesse und für die allgemeine Praxis nicht sehr empfehlungswert). Der Hersteller gibt mindestens 1E6 an. Ich schrieb ein kleines Testprogramm um mehr zu erfahren. Der arme uC brachte es dann auf 14E6 andauernde Schreibzyklen bis endlich Fehler auftraten. (Dazu brauchte der uC übrigens über ein-einhalb Tage). Interessant war, daß auch drei benachbarte Zellen unterhalb und oberhalb der getesteten Zelle beschädigt wurden. (Wer also nicht das ganze EEPROM benötigt könnte den Adressenbereich des EEPROMs in getrennte Unterblöcke Aufteilen und so wesentlich mehr Zyklen herausschinden). Wie gesagt, war ich nur neugierig und wollte es mal für mich herausfinden. Durch kluges Design sollte man natürlich die Schreibzyklen minimal gestalten. Wir hatten in der Firma damals einen "Junior" Designer dem das aus Zeitdruck versehentlich passierte, daß das EEPROM bei jedem Hauptdurchgang beschrieben wurde. Es dauerte drei Monate bis es beim ersten Kunden dann deswegen zu einer Reklamation kam. Dieses Problem führte zu einen kuriosen Gerät-Fehlverhalten. Zum Glück war das aber nur ein Einzelfall und es mußte kein allgemeiner "Recall" gemacht werden. Die Moral von der Geschichte ist, daß eine Code Review durch einen Kollegen dieses Vorkommnis vielleicht verhindert hätte. Gerhard
Gerhard O. schrieb: > Ich schrieb ein kleines Testprogramm um mehr zu > erfahren. Der arme uC brachte es dann auf 14E6 andauernde Schreibzyklen > bis endlich Fehler auftraten. Das hat keinen Aussage-Wert, denn zu dem Zeitpunkt "bis endlich Fehler auftreten" hat ein EEPROM keine sinnvoll lange Zeit mehr Daten zu halten. Die Angaben eines Herstellers jedoch Gerhard O. schrieb: > Der Hersteller gibt mindestens 1E6 an. bezieht sich auf eine Datenhaltigkeit die über einen längeren Zeitraum gehalten bzw. garantiert wird. Also sind solche Tests wie deine nur sehr beschränkt aussagekräftig.
erklehr behr schrieb: > Gerhard O. schrieb: >> Ich schrieb ein kleines Testprogramm um mehr zu >> erfahren. Der arme uC brachte es dann auf 14E6 andauernde Schreibzyklen >> bis endlich Fehler auftraten. > > Das hat keinen Aussage-Wert, denn zu dem Zeitpunkt "bis endlich > Fehler auftreten" hat ein EEPROM keine sinnvoll lange Zeit mehr > Daten zu halten. Das ist anzunehmen. Inwieweit unbenutzte Zellen aktuell und latent davon betroffen werden ist ohnehin unklar und die Datenspeicherung ungeschriebener Adressen davon beeinträchtigt wurde. Mein Beitrag war lediglich als anekdotischer Bericht beabsichtigt und ich wollte niemand zum absichtlichen Missbrauch des EEPROMs verführen;-) > > Die Angaben eines Herstellers jedoch > > Gerhard O. schrieb: >> Der Hersteller gibt mindestens 1E6 an. > > bezieht sich auf eine Datenhaltigkeit die über einen längeren > Zeitraum gehalten bzw. garantiert wird. Im Datenblatt auf der Übersichtsseite war es aber schon so formuliert: "1,000,000 erase/write cycle Data EEPROM memory typical" Die Datenhaltigkeit wird mit "Data EEPROM Retention > 40 years" angegeben. > > Also sind solche Tests wie deine nur sehr beschränkt > aussagekräftig. Natürlich. Ist ja auch nur ein Bericht über ein vorgefallenes Ereignis ohne irgendwelche Aussagen meinerseits machen zu wollen. 1E6 Schreib- /Lösch Zyklen sind also vom Hersteller erwartungsgemäß sehr konservativ angegeben. Es wäre ohnehin verantwortungslos die diesbezüglichen Herstellergarantien vorsätzlich zu überschreiten. Ich hoffe, dass damit irgendwelche Missverständnisse beseitigt sind. Gruß, Gerhard
Mit einem Code Review eines Kollegen ist es nicht getan. Zum einen muss der Kollege ja hunderte von Reviews machen, bis er einen kritischen Fehler findet. Zum anderen fallen dem auch nicht alle Fehler auf. In Summe hat die Firma weniger Kosten, wenn der Kunde die Fehlersuche macht. Und was will der Kunde machen - eure Konkurrenten lassen ihre Fehler auch von den Kunden suchen.
Eine Anmerkung schrieb: > Mit einem Code Review eines Kollegen ist es nicht getan. Zum einen > muss > der Kollege ja hunderte von Reviews machen, bis er einen kritischen > Fehler findet. Zum anderen fallen dem auch nicht alle Fehler auf. > > In Summe hat die Firma weniger Kosten, wenn der Kunde die Fehlersuche > macht. Und was will der Kunde machen - eure Konkurrenten lassen ihre > Fehler auch von den Kunden suchen. Stimmt wahrscheinlich. Allerdings findet man manchmal durch Zufall einen Fehler (Blinde Huhn;-) ) Das war ein extrem seltener Plunder den er da verzapft hatte und war sonst immer sehr kompetent. Im selben Programm waren an anderen Stellen noch Dutzende "richtige" EEPROM Writes zur Parametrisierung. Sonst bin ich aber von der Bananenpolitik der Fehlerbeseitigung aber nicht sehr begeistert;-)
> Ich schrieb ein kleines Testprogramm um mehr zu > erfahren. Der arme uC brachte es dann auf 14E6 > andauernde Schreibzyklen bis endlich Fehler auftraten. Da stellen sich Fragen ueber Fragen. :) Wenn du den Test noch dreimal mit andreren Speicherstellen machst, kommen dann aehnliche Werte raus? Wenn du das Teil dabei auf eine Heizung oder in den Kuehlschrank legst? Die fragliche Haltbarkeit wurde ja schon genannt. Olaf
olaf schrieb: >> Ich schrieb ein kleines Testprogramm um mehr zu >> erfahren. Der arme uC brachte es dann auf 14E6 >> andauernde Schreibzyklen bis endlich Fehler auftraten. > > Da stellen sich Fragen ueber Fragen. :) Oh weh! Diese anekdotische Begebenheit ist mittlerweile schon über 15 Jahre her. > > Wenn du den Test noch dreimal mit andreren Speicherstellen machst, > kommen dann aehnliche Werte raus? Es käme sicherlich auf einen Versuch an. Ob ich den damaligen Quellcode noch irgendwo habe ist allerdings sehr ungewiss. > > Wenn du das Teil dabei auf eine Heizung oder in den Kuehlschrank legst? Man könnte natürlich den Versuch wiederholen. Nur müsste der Testcode neu geschrieben werden. > > Die fragliche Haltbarkeit wurde ja schon genannt. Ja. Es wäre in der Tat sehr interessant, den Speicherinhalt des so gequälten uC nach so langer Zeit zu inspizieren wenn es ihn noch gäbe. Gerhard > > Olaf
Gerhard O. schrieb: > Diese anekdotische Begebenheit ist mittlerweile schon über 15 > Jahre her. Ich gehe davon aus das MC mitlerweile die shrinks auf kleinere Strukturbreiten durchgeführt hat. Dein durchaus löblicher Test wäre also mit einem aktuellen Gegenstück durchgeführt noch interessanter. Im allgemeinen vertraue ich den DB Angaben renomierter Hersteller und gehe z.B. davon aus das bei 1E6 Schreibzyklen das EEPROM bei max Temperatur noch die versprochenen Zeit die Daten hält.
Gerhard O. schrieb: > Wir hatten in der Firma damals einen "Junior" Designer dem das aus > Zeitdruck versehentlich passierte, daß das EEPROM bei jedem > Hauptdurchgang beschrieben wurde. EEPROM Variablen sollte man ja auch nicht überall verstreut im Code zugreifen. Ich lege dafür ein struct im RAM an, was beim Power-On vom EEPROM geladen wird. Zuerst wird aber eine CRC über den EEPROM geprüft und bei CRC-Fehler behält der RAM seine Vorbelegung aus dem Code. Ein Rückschreiben des EEPROM vom RAM erfolgt nur an einer Stelle, z.B auf Befehl vom Bediener oder per Remotebefehl. Das Rückschreiben erfolgt im Hintergrund, d.h. die EEPROM-Schreibzeit beeinflußt nicht den Programmablauf. Pech hat man bei den supergeizigen Sparfüchsen, die meinen, man könne ja im Flash EEPROM emulieren. Wenn dann 100ms Däumchen drehen oder mehr zum Flash-Bank löschen nötig werden, kackt die Anwendung mit Pauken und Trompeten ab. Als absoluten Notnagel kann man wichtigen Code in den RAM kopieren und beim Flash schreiben ausführen. Ist dann umständliches Gebastel mit Linkerskripten.
Peter D. schrieb: > Pech hat man bei den supergeizigen Sparfüchsen, die meinen, man könne ja > im Flash EEPROM emulieren. Wie wahr, wie wahr! Man kann ja soooooooo viel Geld sparen. Geld sparen, koste es was es wolle ....
Ich würde nicht davon ausgehen, dass ein EEPROM (oder ein fragilerer Flash-Speicher) nach 1E6 Schreibzyklen noch genauso lange die Daten hält wie nach 10 Schreibzylen. Hier mal ein entsprechender Ausschnitt aus einem MC9S12XEP100 Datenblatt.
Peter D. schrieb: > Pech hat man bei den supergeizigen Sparfüchsen, die meinen, man könne ja > im Flash EEPROM emulieren. Wenn dann 100ms Däumchen drehen oder mehr zum > Flash-Bank löschen nötig werden, kackt die Anwendung mit Pauken und > Trompeten ab. Als absoluten Notnagel kann man wichtigen Code in den RAM > kopieren und beim Flash schreiben ausführen. Ist dann umständliches > Gebastel mit Linkerskripten. Oder man hat einen uC mit elektrisch unabhängigen Flash-Speichersegmenten.
Gerhard O. schrieb: > Im Datenblatt auf der Übersichtsseite war es aber schon so formuliert: > "1,000,000 erase/write cycle Data EEPROM memory typical" > Die Datenhaltigkeit wird mit > "Data EEPROM Retention > 40 years" angegeben. Wenn die beiden Größen nicht aufeinander bezogen sind, dann sind sie voneinander unabhängig zu sehen. Sowas hat man gerne auf der ersten Seite mit dem Marketing-Geschwätz. Im worst-case bedeutet das dann, 40 Jahre data retention für die ersten 100 Schreibzyklen und nach 1 Mio Zyklen bleiben die Daten dann noch 24 Tage drin. Zehn mal soviele Schreibzyklen reduzieren die Haltezeit um den Faktor 5 - 10. Wenn der Hersteller also seriöserweise 20 Jahre nach 100k Zyklen angibt, hast Du nach 1 Mio Zyklen noch 2 - 4 Jahre, und selten beschriebene Zellen könnten theoretisch auch 200 Jahre halten (da werden dann andere Effekte die Grenze setzen). Totschreiben taugt als Test nur für einen Usecase: Logfile oder Swapfile, wo die Daten ständig aktualisiert werden und kurze Zeit später schon egal sind.
Gerhard O. schrieb: > Der Hersteller gibt mindestens 1E6 an. Ich schrieb ein kleines > Testprogramm um mehr zu erfahren. Der arme uC brachte es dann auf 14E6 > andauernde Schreibzyklen bis endlich Fehler auftraten. Du kommst "besser" an die 1E6 ran, wenn du den µC zwischendurch mal ausschaltest, einen richtigen Powerdownzyklus mit einigen Sekunden einlegst und nicht laufend neu schreibst. APW schrieb: > Ich würde nicht davon ausgehen, dass ein EEPROM (oder ein fragilerer > Flash-Speicher) nach 1E6 Schreibzyklen noch genauso lange die Daten hält > wie nach 10 Schreibzylen. Der hält dann nach 2E6 Löschzyklen nämlich nicht mal mehr die paar Sekunden für einen kurzen Aus- und Einschaltzyklus durch.
:
Bearbeitet durch Moderator
Soul E. schrieb: > Totschreiben (einer Speicherzelle) taugt als Test auch insofern nur bedingt weil damit nicht die Streubreite der Zuverlässigkeit einer einzelnen Zelle nicht ans Licht kommt. Wenn, dann müsste man erstens alle Zellen in den Blick nehmen und das zweitens am besten noch bei mehreren MCUs des gleichen Typs.
Rolf schrieb: > weil damit nicht die Streubreite der > Zuverlässigkeit einer einzelnen Zelle nicht ans Licht kommt nicht nicht nicht sondern einfach nur nicht :)
Deshalb baut man bei EEPROMS ja auch vor: Wichtige Daten werden mehrfach geseichert. So wird etwa die letzte Zufallszahl und Variablen des Zufallsgenerators z.B. in Chipkarten in nem Ringpuffer gehalten, da teilt sich dann die "Schreiblast" auf immer andere Zellen auf. Die Lebensdauer des EEPROMS wird dadurch verlängert. Sowas sollte man als Bastler in seine Projekte auch implementieren. mfg
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.