AVR EEPROMS, wieso Datenverlust bei LESE-Zugriffen?

[batman (Gast)]

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

[Peter (Gast)]

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.

[Stefan F. (Gast)]

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).

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

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.

[Daniel V. (danielv2)]

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.

[batman (Gast)]

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

[c-hater (Gast)]

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