Hallo zusammen, Ich wollte mal in die Runde fragen, ob ihr schon mal ein SPI EEPROM (512 kBit M95512 von ST oder ähnlich) durch Lesen kaputt gemacht habt? Gibt es da ein Limit wie beim Schreiben? Sowas müsste ja im Datenblatt stehen, aber da schweigen sich die gesichteten Datenblätter aus. Kann man das so interpretieren, das EEPROMS 20 Jahre / 365 Tage kontinuierlich mit 5 MBit/s gelesen werden können? Gruss, Udo
Udo K. schrieb: > Ich wollte mal in die Runde fragen, ob ihr schon mal ein SPI EEPROM (512 > kBit M95512 von ST oder ähnlich) durch Lesen kaputt gemacht habt? Praktisch unmöglich. > Gibt > es da ein Limit wie beim Schreiben? Nein. Bei FRAM gibt es sowas. (Oder war's MRAM?) > Sowas müsste ja im Datenblatt > stehen, aber da schweigen sich die gesichteten Datenblätter aus. Weil nicht vorhanden. > Kann > man das so interpretieren, das EEPROMS 20 Jahre / 365 Tage > kontinuierlich mit 5 MBit/s gelesen werden können? Sicher.
Udo K. schrieb: > Sowas müsste ja im Datenblatt > stehen, aber da schweigen sich die gesichteten Datenblätter aus. data retention time > Kann > man das so interpretieren, das EEPROMS 20 Jahre / 365 Tage > kontinuierlich mit 5 MBit/s gelesen werden können? Nein. Das kann man vielmehr so interpretieren: Es ist vollkommen scheissegal, wie oft und wie schnell du die Dinger liest. Entscheidend ist allein die Zeit, die seit dem Schreiben vergangen ist. Schreib-/Löschvorgange haben allerdings als Nebenwirkung auch eine signifikante Verringerung der data retention time zur Folge. D.h.: wenn man nur einmal beschreibt und nachfolgend nur noch liest, erreicht man i.d.R deutlich längere Zeiten, denn angegeben wird die data retention time für die garantierte Zahl von Schreib-/Löschzyklen.
Udo K. schrieb: > Ich wollte mal in die Runde fragen, ob ihr schon mal ein SPI EEPROM (512 > kBit M95512 von ST oder ähnlich) durch Lesen kaputt gemacht habt? Ja. Ein paar W25Q128 WIMRE. Vielleicht ist es denen in meiner Applikation auch zu warm gewesen. Im Betrieb (24/7) wurden dabei nur wenige Byte pro Sekunde gelesen, dafür dauerhaft. Seit der verbesserten Kühlung sind aber seit über fünf Jahren keine mehr ausgefallen. Udo K. schrieb: > Kann > man das so interpretieren, das EEPROMS 20 Jahre / 365 Tage > kontinuierlich mit 5 MBit/s gelesen werden können? Theoretisch schon. Praktisch würde ich es drauf ankommen lassen. Und wenn es sicher funktionieren muß, dann die Daten evtl. in einen RAM kopieren oder einen zweiten EEPROM für die Redundanz vorsehen.
Die Frage ist, ob da drin wirklich ein EEPROM steckt! Bei Flash können durch zu häufiges Lesen durchaus Daten verloren gehen. Das nennt sich „Read Disturbance“ und kann z.B. bei sekündlichem Zugriff schon nach Wochen auftreten, vielleicht auch erst nach Jahren. Wir haben da sehr schmerzliche Erfahrungen machen müssen!
Udo K. schrieb: > durch Lesen kaputt gemacht Was soll das heißen? Wenn Du meinst, daß Daten geändert wurden. Das ist möglich, wenn durch Störungen oder versehentlich ein Schreiben erfolgte. Allerdings muß vorher ein Write-Enable erfolgt sein und der WP Pin entsprechend stehen, d.h. die Gefahr ist gering. Beim Lesen sollte immer Write-Disable gesetzt sein.
„Read Disturbance“ gibt es nur bei MLC Flash als Datenspeicher. Bei Flash als Programmspeicher oder EEPROM ist ein permanentes Lesen vorgesehen und daher unproblematisch.
Wir hatten mal ein Projekt, bei dem Kalibrierdaten in einem externen EEEPROM 25LC512 abgelegt wurde und nur beim Einschalten gelesen wurden. Bei einigen Geräten waren neu geschriebene Daten nach ca. 30 Minuten ohne Versorgungsspannung wieder verloren !!! Ursache immer noch unbekannt. Haben darauf hin auf das interne EEPROM der MCU gewechselt. Keine Probleme mehr.
:
Bearbeitet durch User
Dirk F. schrieb: > Haben darauf hin auf das interne EEPROM der MCU gewechselt. Wie habt ihr dieses Kunststück geschafft? Udo K. schrieb: > ob ihr schon mal ein SPI EEPROM durch Lesen kaputt gemacht habt? Ich habe zweimal mit internen EEPROMs von Mikrocontrollern die Erfahrung gemacht, dass sie Daten verlieren können, wenn beim Lesezugriff die Versorgungsspannung instabil ist. In beiden Fällen lief die CPU dabei ohne Probleme weiter, sie hat den gelesenen Müll auf einem Display bzw. einer seriellen Konsole angezeigt.
Dirk F. schrieb: > Bei einigen Geräten waren neu geschriebene Daten nach ca. 30 Minuten > ohne Versorgungsspannung wieder verloren !!! Da würde ich stark auf HW- oder SW-Fehler tippen. Die Pins dürfen niemals floaten, z.B. wenn der µC noch in Reset ist. Mindestens /CE und SCK müssen einen Pullup haben. Wir setzen schon lange AT24C512 ein und hatten nie Probleme damit.
Sherlock 🕵🏽♂️ schrieb: > Ich habe zweimal mit internen EEPROMs von Mikrocontrollern die Erfahrung > gemacht, dass sie Daten verlieren können Bei den AVRs ist zwingend erforderlich, die Brownout-Fuse zu enablen.
Sherlock 🕵🏽♂️ schrieb: > Dirk F. schrieb: >> Haben darauf hin auf das interne EEPROM der MCU gewechselt. > > Wie habt ihr dieses Kunststück geschafft? Lern lesen! Dirk F. schrieb: > Wir hatten mal ein Projekt, bei dem Kalibrierdaten in einem externen > EEEPROM 25LC512 abgelegt wurden ... > Haben darauf hin auf das interne EEPROM der MCU gewechselt
Peter D. schrieb: > Bei den AVRs ist zwingend erforderlich, die Brownout-Fuse zu enablen. Harmoniert leider nicht so gut mit (langzeit-) Batteriebetrieb.
Axel S. schrieb: > Lern lesen! Hast Recht, ich habe das Wort "auf" überlesen. Dadurch bekam der Satz eine völlig andere Bedeutung.
Sherlock 🕵🏽♂️ schrieb: > Peter D. schrieb: >> Bei den AVRs ist zwingend erforderlich, die Brownout-Fuse zu enablen. > > Harmoniert leider nicht so gut mit (langzeit-) Batteriebetrieb. Z.B. beim ATmega328P/PA kann man das BODS Bit vor dem Schlafen setzen.
Christoph Z. schrieb: > Bei Flash können durch zu häufiges Lesen durchaus Daten verloren gehen. > Das nennt sich „Read Disturbance“ und kann z.B. bei sekündlichem > Zugriff schon nach Wochen auftreten ... Frag die ganzen Mikrocontroller, die schon nach ein paar Stunden ausfallen, weil sie in ihrer nur einige Millisekunden dauernden Hauptschleife das Programm aus dem Flash-Speicher nicht mehr lesen können. ;-) „Read Disturbance“ tritt nur bei MLC NAND Flash auf. Deine Verallgemeinerung gilt in dieser Form ganz sicher nicht.
:
Bearbeitet durch User
Rainer W. schrieb: > Frag die ganzen Mikrocontroller, die schon nach ein paar Stunden > ausfallen, weil sie in ihrer nur einige Millisekunden dauernden > Hauptschleife das Programm aus dem Flash-Speicher nicht mehr lesen können. Für mich klingt das nach einer vogelwilden Urban Legend. Hast du da auch ein konkretes Beispiel, welchen "ganzen Mikrocontroller" man da fragen müsste?
Andreas H. schrieb: > ;-) beachten! Hölle auch, das ging unter... :-o Rainer W. schrieb: > „Read Disturbance“ tritt nur bei MLC NAND Flash auf. Und verstärkt bei den nachfolgenden Technologien TLC und QLC.
Lothar M. schrieb: >> „Read Disturbance“ tritt nur bei MLC NAND Flash auf. > Und verstärkt bei den nachfolgenden Technologien TLC und QLC. Naja, wer digitale Informationen analog speichert, muss sich da nicht wundern . . .
Rainer W. schrieb: > Christoph Z. schrieb: >> Bei Flash können durch zu häufiges Lesen durchaus Daten verloren gehen. >> Das nennt sich „Read Disturbance“ und kann z.B. bei sekündlichem >> Zugriff schon nach Wochen auftreten ... > > Frag die ganzen Mikrocontroller, die schon nach ein paar Stunden > ausfallen, weil sie in ihrer nur einige Millisekunden dauernden > Hauptschleife das Programm aus dem Flash-Speicher nicht mehr lesen > können. ;-) > > „Read Disturbance“ tritt nur bei MLC NAND Flash auf. Deine > Verallgemeinerung gilt in dieser Form ganz sicher nicht. Das habe ich so explizit auch nie behauptet. Leider ist es aber heute so, dass bei vielen Produkten gar nicht mehr so klar ist, welche Technologioe denn wirklich drinsteckt. Als uns damals das Problem kalt erwischte, war das noch noch viel weniger bekannt als es heute immer noch ist.
Christoph Z. schrieb: > Als uns damals das Problem kalt > erwischte Magst Du uns auch den konkreten EEPROM/Flash nennen, der dieses Problem bereitet?
:
Bearbeitet durch User
Lothar M. schrieb: > Und verstärkt bei den nachfolgenden Technologien TLC und QLC. "Multi" steht im allgemeinen Sprachgebrauch für "mehrere"/"viele" und umfasst damit eigentlich auch "Triple" und "Quad". Da hat die Welt bei Einführung der ersten Flash-Speicher mit mehreren Pegeln wohl verschlafen, einen spezifische Begriffe zu wählen. Das alte "MLC" steht für "Dual" - da hast du wohl Recht. Abgesehen davon sind diese Akronyme sowieso irreführend, da ein "TLC" Flash natürlich nicht drei Level (TL=Triple Level), sondern 8 Level unterscheiden muss, ein "QLC" (QL=Quad Level) 16 Level. Eigentlich müsste es also nicht SLC/MLC/TLC/QLC, sondern SBC(single Bit Cell)/DBC/TBC usw. heißen. Aber das Kind ist wohl in den Brunnen gefallen.
:
Bearbeitet durch User
Rainer W. schrieb: > "Multi" steht im allgemeinen Sprachgebrauch für "mehrere"/"viele" und > umfasst damit eigentlich auch "Triple" und "Quad". Das mag "allgemein" schon so sein, bei Flash wird da aber ganz genau unterschieden. Rainer W. schrieb: > Abgesehen davon sind diese Akronyme sowieso irreführend, da ein "TLC" > Flash natürlich nicht 3 (wie es das T suggeriert), sondern 8 Level > unterscheiden muss, ein "QLC" 16 Level. Ich finde das (abgesehen von dem "Multi"-Ausrutscher) eher logisch: es ist 1 Bit bei "Single", es sind 2 Bits bei "Multi" (="Dual"), 3 Bits bei "Triple" bzw. 4 Bits bei "Quad", die in 1 Speicherzelle gespeichert werden können: - https://www.corsair.com/de/de/explorer/diy-builder/storage/how-qlc-tlc-and-more-supercharge-your-ssds/
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Rainer W. schrieb: >> "Multi" steht im allgemeinen Sprachgebrauch für "mehrere"/"viele" und >> umfasst damit eigentlich auch "Triple" und "Quad". > Das mag "allgemein" schon so sein, bei Flash wird da aber ganz genau > unterschieden. Eben nicht. Wenn die Begriff nicht aus irgendwelchen kurzsichtigen Technologiehypes entstehen würden, sondern eine genaue Beschreibung darstellen würden, dürfte es nie "MLC" heißen und das "L" hat da schon gar nichts zu suchen - soviel zum Thema "ganz genau". Lothar M. schrieb: > Ich finde das (abgesehen von dem "Multi"-Ausrutscher) eher logisch Wenn da nicht auch noch der "Level"-Ausrutscher wäre. Ein QLC enthält Zellen mit 4 Bit und nicht Zellen mit 4 Leveln.
:
Bearbeitet durch User
Lothar M. schrieb: >> Abgesehen davon sind diese Akronyme sowieso irreführend, da ein "TLC" >> Flash natürlich nicht 3 (wie es das T suggeriert), sondern 8 Level >> unterscheiden muss, ein "QLC" 16 Level. > Ich finde das (abgesehen von dem "Multi"-Ausrutscher) eher logisch: es > ist 1 Bit bei "Single", es sind 2 Bits bei "Multi" (="Dual"), 3 Bits bei > "Triple" bzw. 4 Bits bei "Quad", die in 1 Speicherzelle gespeichert > werden können: Ja, aber das sind Bits und nicht Level, so wie es der Name und die Abkürzung behaupten. Anzahl Level = 2^Bits Klingt bekannt, oder?
Falk B. schrieb: > Anzahl Level = 2^Bits > > Klingt bekannt, oder? Und was bitte hat in dem Akronym dann das 'L' zu suchen?
:
Bearbeitet durch User
Rainer W. schrieb: > Eben nicht. Wenn du das so beharrlich sagst... Aber wenn ich mit unseren Flash-Lieferanten spreche, dann haben die ein sehr festes Bild von dieser Einteilung. Und "Multi" bedeutet bei denen **immer** 2 Bit pro Zelle. > Ein QLC enthält Zellen mit 4 Bit und nicht Zellen mit 4 Leveln. Ja, lies nochmal ganz in Ruhe, was ich schrieb. Und sieh dir das Bild in meinem Link an. Aber hier nochmal als Tabelle:
1 | Single = 1 Bit pro Zelle = 2 zu speichernde Pegel |
2 | Multi = 2 Bits pro Zelle = 4 zu speichernde Pegel |
3 | Triple = 3 Bits pro Zelle = 8 zu speichernde Pegel |
4 | Quad = 4 Bits pro Zelle = 16 --"-- |
5 | |
6 | Und eine Prognose für die Zukunft: |
7 | |
8 | Penta = 5 Bits pro Zelle = 32 --"-- |
9 | Hexa = 6 Bits pro Zelle = 64 --"-- |
10 | usw.usf. |
Allerdings ist nach Aussage der Flashhersteller mit QLC Schluss, danach kommt 3D-QLC. Rainer W. schrieb: > Und was bitte hat in dem Akronym dann das 'L' zu suchen? Schon bei den Single-Level-Cell geht das schief. Denn was ist das für ein Speicher, der nur 1 Pegel speichern kann? Speichert der dann nur '0' oder nur '1'?
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Ja, lies nochmal ganz in Ruhe, was ich schrieb. Und sieh dir das Bild in > meinem Link an. Die 2er-Potenzen brauchst du mir nicht aufzuschreiben ;-) Wofür steht denn deiner Meinung nach das 'L', wenn nicht für "Level", was ja offensichtlich nicht passen kann? > Denn was ist das für ein Speicher, der nur 1 Pegel speichern kann? > Speichert der dann nur '0' oder nur '1'? Ganz meiner Meinung - die Bezeichnung bezieht sich eben NICHT auf die Pegel (engl. Level) sondern auf die Bits und folglich müsste es logischerweise SBC, DBC,TBC und QBC (BX = Bit Cells) heißen und nicht wie in deinem Link.
:
Bearbeitet durch User
Rainer W. schrieb: >> Anzahl Level = 2^Bits >> >> Klingt bekannt, oder? > > Und was bitte hat in dem Akronym dann das 'L' zu suchen? L wie Lapsus ;-)
Rainer W. schrieb: > die Bezeichnung bezieht sich eben NICHT auf die Pegel Ja, das kann ich aber jetzt auch nicht mehr ändern, dass das irgendwann mal wer verbockt hat. Ich kann nur versprechen, das beim nächsten Treffen mit unserem Distri mal anzusprechen. Allein: ich glaube, mein Hebel ist zu klein, um das jetzt noch geradezuziehen. Aber zum Glück geht es hier im Thread ja um EEPROMs, die eine völlig andere Struktur haben.
Es geht hier um EEPROM und kleine uC, und nicht um Flash MLC/TLC/QLC. Danke für die Erfahrungen aus der Praxis. Ich nehme mal mit dass es mit Dauerlesen keine Probleme gibt wenn VCC stabil ist und Pullups an den wichtigen Leitungen dran sind. @Rick und W25Q128: War warm == heiss ( > 85°C )?
Udo K. schrieb: > @Rick und W25Q128: War warm == heiss ( > > 85°C )? Das klingt nach Latch Up. Da ist was beim Einschalten schief gegangen. Oder deine Versorgungsspannung wurde mal kurz und stromstark verpolt, damit kann man EEPROMs auch löschen.
Lothar M. schrieb: > Ja, das kann ich aber jetzt auch nicht mehr ändern, dass das irgendwann > mal wer verbockt hat. Das gibt es öfter, als einem lieb ist. Vor allem die Unsitte, die wesentliche Information wegzulassen und nur einen an sich nachrangigen Bestandteil zu benennen, die sorgt immer wieder für viel Freude. "Oh, das ist ein NAND". "Ein 74HC00?" "Nein, 2 GByte". Ähnlich wird mit den Begriffen "Kartusche" oder "Aggregat" umgegangen. Gerade die Amis sind da besonders klasse, die haben sogar auf diesem Konzept aufbauende Maßeinheiten: "Micron", "Thou" und "Mil".
Warum heisst jedes zweite Kunststoffteil "bezel"? Und die Fertigung nennt jedes selbstgebaute Dingsbums "jig".
Udo K. schrieb: > W25Q128: War warm == heiss ( > 85°C )? Schwer zu sagen. Eher so zwischen 60°C und 75°C. Falk B. schrieb: > Das klingt nach Latch Up. Da ist was beim Einschalten schief gegangen. > Oder deine Versorgungsspannung wurde mal kurz und stromstark verpolt, > damit kann man EEPROMs auch löschen. Das mit der Versorgungsspannung kann ich ausschließen. Die waren auch nicht gelöscht, sondern da muß ein Bit gekippt sein und die Prüfsumme (FPGA-Bitstream) stimmte nicht mehr. Auf einen Neustart im Rack hatten die dann keine Lust, aber auf dem Labortisch ging es z.T. wieder. Manche konnte man neu programmieren und es ging noch mal eine Weile. Inzwischen lasse ich den Flash aber tauschen und habe dann Ruhe.
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.