|
Anzeige
|
AVR EEPROMS, wieso Datenverlust bei LESE-Zugriffen?
Gast
#5188904
Ich will es nur verstehen. Ich hatte schon bei mehreren kleinen AVR-Batterieprojekten das Problem, daß die Atmels ihre internen EEPROMS korrumpieren, wenn beim Start mit unsauber ansteigender Ub, z.B. beim Einlegen von Batterien, aus dem EEPROM gelesen wird. Gerüchteweise beschränkt sich das Problem auf Adresse 0 und kann mit BOD halbwegs umgangen werden aber mal grundsätzlich: Wieso schreiben die Dinger, wenn sie nur lesen sollen??
Gast
#5188913
batman schrieb: > Ich will es nur verstehen. > > Ich hatte schon bei mehreren kleinen AVR-Batterieprojekten das Problem, > daß die Atmels ihre internen EEPROMS korrumpieren, wenn beim Start mit > unsauber ansteigender Ub, z.B. beim Einlegen von Batterien, aus dem > EEPROM gelesen wird. > Gerüchteweise beschränkt sich das Problem auf Adresse 0 und kann mit BOD > halbwegs umgangen werden aber mal grundsätzlich: Wieso schreiben die > Dinger, wenn sie nur lesen sollen?? Genau kann dir das nur Atmel erklären. Es ist ein Fehler im Design. Vermutung: Das EEPROM hat intern eine Statemachine mit den States Idle, Lesen und Schreiben. Beim zu langsamen Anstieg von Ub kommt das EEPROM in den falschen State (Schreiben) und korrumpiert die Daten.
Gast
#5188921
Warum das so ist, weiß ich nicht. Ich bin allerdings auch schon bei anderen Chips mit EEProm darauf gestoßen, und zwar wenn während des Lesens die Spannungsversorgung absackt (aber nicht so weit, dass der µC ausfällt). Der Datenverlust hat aber nichts mit einem Lesezugriff zu tun, der Benutzer muss da gar nichts machen. Es ist ein Problem der Schreiblogik (kippelt anscheinend ein Signal, vor allem bei langsamen Anstieg von Vcc), und da die Adresszähler ja nach Reset auf 0 stehen, trifft es diese Adresse. Ich benutze die Adresse nie und setze da ein Dummy drauf. Mit BOD habe ich noch nie ein Problem mit veränderten EEPROM- oder Flash-Daten gehabt. Ohne BOD (bis jetzt) nur dann, wenn der Code Schreibzugriffe für EEPROM oder Flash enthielt. Ich habe mir das so erklärt, dass sich der Programmzeiger beim Brownout zufällig ändert und so irgendwann auch mal der Code für die Schreibzugriffe ausgeführt wird.
Gast
#5189007
Aha also ob mit oder ohne Lesezugriff im Programm ändert nix an der Korruption des 1.EE-Bytes? Ok, werde mal darauf achten. Dann müßte der Fehler aber immer nur Nullen toggeln (erase), so daß es bei unbenutztem EE nicht auffällt!? Was wiederum zu der Frage führt, wie er das auf 1 Byte der Page beschränken kann..
Gast
#5189121
batman schrieb: > Ich hatte schon bei mehreren kleinen AVR-Batterieprojekten das Problem, > daß die Atmels ihre internen EEPROMS korrumpieren, wenn beim Start mit > unsauber ansteigender Ub, z.B. beim Einlegen von Batterien, aus dem > EEPROM gelesen wird. Nicht, wenn man den BOD einschaltet und auf eine sinnvolle Schwellspannung konfiguriert... > Gerüchteweise beschränkt sich das Problem auf Adresse 0 Das ist Schnee von übervorgestern. Das war tatsächlich mal ein Bug beim historischen Mega8 einer Revision, die so alt ist, dass Jesus selber sie fast noch benutzt haben könnte. Nicht mehr relevant, weil du einfach schon sehr lange keine (neue) Hardware mehr kaufen kannst, die ihn hat. > und kann mit BOD > halbwegs umgangen werden aber mal grundsätzlich: Wieso schreiben die > Dinger, wenn sie nur lesen sollen?? Weil ein abstürzender µC halt so ziemlich alles macht. Garantiert ist nur eins: es ist nicht das, was der Programmierer beabsichtigt hatte... Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
