Wie verhält sich eine EEPROM-Zelle, die mit mehr als 100000 Write-Cycles ihr nominelles Verfallsdatum überschritten hat? Schlägt ein direktes Verify fehl? Werden die Daten nicht mehr die angegebenen 20-100 Jahre gehalten? Ich versuche das gerade mit einem Atmega168-20PU(8MHz RC, 5V) zu testen. Auch nach > 1 Mio. Writes ist ein Verify mit ca. 10ms Verzögerung immer noch positiv. Das Verify erfolgt dabei nicht direkt, sondern es wird ein Block Daten geschrieben und dann der komplette Block verifiziert. Die 100 Jahre Data Retention abzuwarten, ist mir aber irgendwie zu lang. Hat jemand Erfahrungswerte? mfg.
:
Bearbeitet durch User
Thomas Eckmann schrieb: > Werden die Daten nicht mehr die angegebenen 20-100 Jahre gehalten? Durch Materialmigration kann es passieren, das das Gate eben nicht mehr so perfekt isoliert. Du brauchst keine 20 oder 100 Jahre warten. Mit 85°C im Wärmeschrank läßt sich der Test im Zeitraffer durchführen, da die Leckströme dann stark ansteigen.
Jetzt sind es 1,3Mio. Zyklen und Verify OK. Die Erkenntnis daraus ist erstmal, dass dieser Test untauglich ist. Wenn ich Zeit habe, werde ich die 85°-Methode mal ausprobieren. mfg.
Thomas Eckmann schrieb: > Jetzt sind es 1,3Mio. Zyklen und Verify OK. Du musst zwischendurch unbedingt die Versorgung des EEPROMs abschalten...
Hallo Materialmigration: kann bitte jemand, in einfachen Worten, erklären was das im Bezug auf FET (gate) bedeutet? Ein Link ist auch i.O. Was findet da, warum statt? Bitte jetzt keine Vortragsreihe einer ETH oder ein Auszug aus einer Doktorarbeit ;-) mag Janus
@ Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase) >Jetzt sind es 1,3Mio. Zyklen und Verify OK. Die Erkenntnis daraus ist >erstmal, dass dieser Test untauglich ist. Wenn ich Zeit habe, werde ich >die 85°-Methode mal ausprobieren. Es nützt ja nix, die Daten zu schreiben und gleich wieder zu prüfen. Eher geht es darum, dass die Daten nicht mehr lange und sicher halten. Also muss man schreiben und danach fortlaufend prüfen (Minuten, Stunden, Tage), natürlich auch mit erhöhter Temperatur zu Beschleunigung.
Lothar Miller schrieb: > Du musst zwischendurch unbedingt die Versorgung des EEPROMs > abschalten... Ja, das wird es sein. mfg.
Thomas Eckmann schrieb: > Lothar Miller schrieb: >> ... die Versorgung des EEPROMsabschalten... > Ja, das wird es sein. Du tust es nicht? Dann ist es das. Ich habe den selben Test und den selben Fehler auch schon gemacht... ;-) Vor Allem: die Schaltung richtig spannungsfrei machen mit Kurzschluss und so...
:
Bearbeitet durch Moderator
Lothar Miller schrieb: > Du tust es nicht? Dann ist es das. Ich habe den selben Test und den > selben Fehler auch schon gemacht... Na gut, dann bin ich wenigstens nicht der einzige. 5 Minuten Aus hat er überstanden. Lothar Miller schrieb: > Vor Allem: die Schaltung richtig spannungsfrei machen mit Kurzschluss > und so... Hab den Controller jetzt rausgezogen und auf eine Alufolie gedrückt. Guck mir das in ein paar Stunden nochmal an. mfg.
Dann hast Du gute Changen den Controller mittels ESD zu zerstören. Warum nicht ein Relais in Steckfassung das entweder die Vrsorgung durchschaltet oder die Versorgungspins des Controllers kurschließt. Kannst auch mit FET realisieren.
Wikipedia erklärt die einzelnen Effekte recht gut: https://de.wikipedia.org/wiki/Elektromigration Besonders heikel sind halt die Floating Gates von EPROMs, EEPROMS und FLASH Zellen, da dort durch einen Isolator Ladungsträger durchgetunnelt werden müssen zum Laden und Entladen des Floating Gates. Dabei machen sich nicht nur Elektronen auf den Weg durch den Isolator, sondern auch langsamere Metallionen, die aber wie bei Hase und Igel irgendwann auch ankommen ;-)
Thomas Eckmann schrieb: > 5 Minuten Aus hat er überstanden. Ich meinte spannungsfrei für 2 sec nach jedem Schreibzyklus. Klar dauert der Test für 100000 Zyklen dann schon mal drei Tage... ;-)
> Ich meinte spannungsfrei für 2 sec nach jedem Schreibzyklus. Klar > dauert der Test für 100000 Zyklen dann schon mal drei Tage... ;-) Das verstehe ich nicht: im normalen Einsatz wird der Controller doch auch nicht nach jedem EEPROM-Schreiben abgeschaltet.
Thomas Eckmann schrieb: > Wie verhält sich eine EEPROM-Zelle, die mit mehr als 100000 Write-Cycles > ihr nominelles Verfallsdatum überschritten hat? > > Schlägt ein direktes Verify fehl? nein. > Werden die Daten nicht mehr die angegebenen 20-100 Jahre gehalten? Ja. Die data retention time sinkt ab. Fiktives Beispiel: die ersten 100k Zyklen bleiben die Daten 20 Jahre erhalten, nie nächsten 50k dann 5 Jahre, die nächsten 50k ein Jahr, etc. Parallel dazu können auch einzelne Zellen ausfallen, dh. konstant 1 oder 0 zurückliefern.
soul eye schrieb: > Fiktives Beispiel: die ersten 100k Zyklen bleiben die Daten 20 Jahre > erhalten, nie nächsten 50k dann 5 Jahre, die nächsten 50k ein Jahr, etc. Da befürchte ich auch. soul eye schrieb: > Parallel dazu können auch einzelne Zellen ausfallen, dh. konstant 1 oder > 0 zurückliefern. Genau das hatte ich eigentlich während des Schreibens erwartet. mfg.
Thomas Eckmann schrieb: > Wie verhält sich eine EEPROM-Zelle, die mit mehr als 100000 > Write-Cycles > ihr nominelles Verfallsdatum überschritten hat? > > Schlägt ein direktes Verify fehl? > > Werden die Daten nicht mehr die angegebenen 20-100 Jahre gehalten? Der Hersteller garantiert nicht mehr für die Einhaltung der im Datenblatt vorgegebenen Werte. Nicht mehr und nicht weniger. Es kann, muss aber nicht sein, dass ein Verify sofort fehlschlägt. Es kann, muss aber nicht sein, dass sich das Bauteil nicht mehr beschreiben/auslesen lässt Es kann, muss aber nicht sein, dass es nach 19 oder 99 Jahren (nicht wie im Datenblatt vorgegeben 20 oder 100Jahren) vergesslich wird Es kann sein, dass einzelne Bits irgendwann umkippen Am besten man vermeidet es einfach. Ein größeres EEPROM und ein vernünftiges Speichermanagement helfen hier. Alternativ kann man auch ein Ram nehmen und mit einer kleinen Batterie Puffern. Mit Lithiumbatterien kommt man so auch auf 20Jahre Haltbarkeit.
S. Landolt schrieb: > Das verstehe ich nicht: im normalen Einsatz wird der Controller doch > auch nicht nach jedem EEPROM-Schreiben abgeschaltet. Im normalen Betrieb ist es auch nicht das Ziel, das EEPROM kaputt zu bekommen...
Lothar Miller schrieb: > S. Landolt schrieb: >> Das verstehe ich nicht: im normalen Einsatz wird der Controller doch >> auch nicht nach jedem EEPROM-Schreiben abgeschaltet. > Im normalen Betrieb ist es auch nicht das Ziel, das EEPROM /kaputt/ > zu bekommen... Ja, zudem ist der Sinn des EEPROMs ist ja auch, dass die Daten nach einem Ausfall noch da sind - sonst könnte man ja den ganzen Spaß lassen
Es gibt keinen normalen Einsatz aber die Anwendungshinweise empfehlen ja einen Schreibzugriff möglichst nur vor dem Abschalten. Realistischer wäre vielleicht ein Verhältnis 10:1 (Schreiben:Abschalten) oder so.
dfgjgh schrieb: > alternativ FRAM > (https://de.wikipedia.org/wiki/Ferroelectric_Random_Access_Memory) Da muss man sehr genau hinschauen. FRAMs haben eine deutlich höhere Zyklenzahl als EEPROMs. Die 1T1C- Zellen werden aber destruktiv gelesen (wie bei einem DRAM) und müssen nach dem Lesen neu geschrieben werden. Das macht der Baustein automatisch ("refresh write"), aber so zählen die Lesezyklen zur Berechnung der Lebensdauer mit. D.h. als Parameter-Speicher, der morgens beim Booten gelesen und abends beim runterfahren geschrieben wird, hält ein FRAM 10 ^14 /2 Tage, also ewig. Als DRAM-Ersatz mit einem Lesezugriff pro 100µs ist der Baustein in drei Jahren durch.
Lothar Miller schrieb: > S. Landolt schrieb: >> Das verstehe ich nicht: im normalen Einsatz wird der Controller doch >> auch nicht nach jedem EEPROM-Schreiben abgeschaltet. > Im normalen Betrieb ist es auch nicht das Ziel, das EEPROM kaputt zu > bekommen... Ich war der Meinung, hier soll eine praxisrelevante Aussage erreicht werden bezüglich maximaler Zyklenzahl.
S. Landolt schrieb: > Ich war der Meinung, hier soll eine praxisrelevante Aussage erreicht > werden bezüglich maximaler Zyklenzahl. In absehbarer Zeit... Und zudem: wie ist hier "praxisrelevant" definiert? Wenn ich eine ein paar wenige Zellen nutze, die einmal pro Power-Up-Down-Zyklus schreibe, und deren Konsistenz prüfe, dann ist das für mich schon recht praxisnah.
S. Landolt schrieb: > Ich war der Meinung, hier soll eine praxisrelevante Aussage erreicht > werden bezüglich maximaler Zyklenzahl. Nein. Das Anliegen ist eigentlich, sicher festzustellen, dass eine Zelle kaputt oder heil ist. So wie sich das EEPROM verhält, scheint das allerdings nicht möglich zu sein. Zumindest nicht so, wie ich mir das gedacht hatte. mfg.
:
Bearbeitet durch User
Noch etwas komplizierter wird es mit MLC FLASH (Multilevel Cell), wo es nicht nur H und L sondern auch noch was dazwischen gibt. Die Gates liegen so dicht gepackt beieinader, so das es auch ein Übersprechen der benachbarten Floating Gates gibt. Einer Single Level Cell sind 20% Übersprechen herzlich egal, bei 3 Zuständen wird es dann schon verdammt enge. Dazu kommt, das es länger dauert, bis der Bus gültige Daten liefert, da die Leitungen zu den Zellen kleine parasitäre Kapazitäten haben. Bei SLC reicht es zu warten, bis die Entladekurve der parasitären Kapazität bei 40% liegt - bei 3 Zuständen eben nicht mehr! Um nun einen effektiven Prüfalgorithmus schreiben zu können, muß man wissen, wie der Chip designt ist, welches Bit welche anderen Bits zum Nachbarn hat, gegen deren Übersprechen es getestet werden muß. Dazu kommen dann noch Wearlevelling und Reserveblöcke, die bei einem toten Hauptblock bei den Tests im Backend dann per Fuse umgeroutet werden. Das alles zu berücksichtigen ist ohne genaue Kenntnis des Chipdesigns wie stochern im Nebel.
Deswegen liegt die garantierte data retention time eines USB-Memorysticks teilweise bei gerade mal einem Jahr. Um Daten zu transportieren ist das wunderbar, zum Archivieren völlig unbrauchbar. SSD-Laufwerke als Festplatten-Ersatz treiben eine Menge Aufwand, um die Integrität der Daten in ihren MLC-Zellen über die garantierte Zeit (5-10 Jahre) zu gewährleisten. Leider sind die vollständigen Datenblätter zu den Speichermedien meist nur gegen NDA zu bekommen (wer hat eins zu seinen privaten USB-Stick??), und komplette Erstmusterprüfberichte (PPAP) unterliegen erst recht der Geheimhaltung.
JESD22-A117C-2011 JEDEC electrically erasable programmable rom (eeprom) program/erase endurance and data retention stress test Die Norm kostet Geld, aber vielleicht findet sich im Netz irgendwo eine Diplonmarbeit, wo jemand einen entsprechenden Prüfaufbau gemacht hat. Oder ein indischer Server...
Gerald B. schrieb: > Noch etwas komplizierter wird es mit MLC FLASH (Multilevel Cell), wo es > nicht nur H und L sondern auch noch was dazwischen gibt. MLC und TLC gibts aber bisher nicht bei den EEPROMs hier im Thread. Oder? Und beim FLASH kommt dann ja noch die Wearleveling Geschichte dazu. Oder dass eigentlich unbeteiligte, aber benachbarte Speicherblöcke ebenfalls vom Löschen betroffen sind...
Von Microchip gibt es ein tool mit dem die Beständigkeit von Microchip EEPROMs berechnet werden kann. Das ganze nennt sich "Total Endurance". Dass das natürlich nicht für Atmel EEPROMs gilt ist klar. Was es aber Zeigt ist, welche Faktoren grundlegend für die Endurance eines EEPROMs ausschlaggebend sind. Zudem gibt es auf der Microchip Seite einige Application Notes die sich mit dem Thema beschäftigen.
Nach 25 Stunden keine Änderung. Erfährt die Ladung durch Anlegen der Spannung einen Refresh? mfg.
soul eye schrieb: > *JESD22-A117C-2011* > JEDEC electrically erasable programmable rom (eeprom) program/erase > endurance and data retention stress test > > > Die Norm kostet Geld, aber vielleicht findet sich im Netz irgendwo eine > Diplonmarbeit, wo jemand einen entsprechenden Prüfaufbau gemacht hat. > Oder ein indischer Server... Das ist falsch. Es ist lediglich nötig, sich bei der JEDEC zu registrieren (online Formular ausfüllen, kostenlos), dann erhält man freien Zugang zu den meisten Dokumenten, die man so im täglichen Leben eines Elektronikers braucht. U.A. auch zu dem von Dir genannten aber auch die vollständigen Standards zu eMMC, SD, DRAM.... Nur weil man sich irgendwo einloggen muss, ist es nicht gleich kostenpflichtig. http://www.jedec.org/standards-documents/results/endurance
Die Zahl der Zyklen die so ein EEPROM durchhält kann stark streuen, etwa weil die Zellen mal etwas besser oder schlechter sind. Die angegebenen 100000 Zyklen sind mehr ein Wert für die schlechteren Zellen - das ist normal das 90% (oder ein paar mehr) der Chips noch deutlich länger durchhalten. Die Zyklenfestigkeit kann auch von der Temperatur abhängen. Für die einzelnen Schreib-Zyklen sollte es nicht nötig sein die Spannung zu entfernen. Auch so werden die Speicherzellen gealtert. Das Ausschalten gibt noch einmal zusätzliche Störungen auf den Inhalt und könnte einen Fehler eher sichtbar machen. So ähnlich kann auch das beschreiben / lesen benachbarter Zellen ggf. eher zu Fehlern führen. Es sollte also reichen z.B. je 100K Zyklen zu fahren, dann ausschalten (ggf. auch mehrmals) und dann testen mit z.B. einigen 10000 Lesezyklen. Die Testphase darf auch schon etwas dauern. Das ganze dann wiederholen bis sich dann nach längerer Zeit erste Fehler zeigen. Um die Bedingungen zu erschweren und ggf. schon erste Anzeichen von Alterung zu erkennen, könnte man die Versorgungsspannung ggf. auch noch bis an die Grenzen fahren - also auch bei 5,5 V und 2,5 V (oder weniger) testen. Es ist durchaus möglich es mit dem gealterten EEPROM nicht mehr ganz so weit runter geht, wie mit dem neuen - aber nicht wundern wenn der µC auch mit deutlich weniger als dem garantierten unteren Limit noch läuft.
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.