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??
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.
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.
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..
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...
Bitte 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.