EEPROM ändert sich manchmal von allein

[Jonathan K. (Gast)]

Hallo,

von Zeit zu Zeit werden die Daten im EEPROM meines ATmega8 verändert. 
Durch das Programm kann dies nicht geschehen, da ich teilweise Daten 
ausgelesen habe, die das Programm so unter keinen Umständen 
reinschreibt. Was sind mögliche Ursachen dafür? Alle Lese- und 
Schreibzugriffe sind in einem cli/sei-Block.

Danke schon mal

[Joe (Gast)]

irgendwann ist das EEPROM tot, wenn es 100000 Schreibzugriffe hatte.

Hast du in einer Laufschleife in EEPROM geschrieben?

[Teo D. (teoderix)]

Jonathan K. schrieb:
> Durch das Programm kann dies nicht geschehen, da ich teilweise Daten
> ausgelesen habe, die das Programm so unter keinen Umständen
> reinschreibt.

Wetten doch!

[Ralph S. (jjflash)]

Joe schrieb:
> irgendwann ist das EEPROM tot, wenn es 100000 Schreibzugriffe hatte.

Ich hab's erst ein einziges mal "erreicht", den EEPROM (müßte es nicht 
eigentlich DAS EEPROM heißen?) zu "töten" und hier war dann nur noch der 
letzte geschriebene Wert permanent leßbar, EEPROM lies sich da halt 
einfach nicht mehr beschreiben !

Ich glaube eher, dass irgendwas im Programm eben DOCH in den/das EEPROM 
schreibt !

------------------------

DAS Memory / DER Speicher

[Noch einer (Gast)]

Nur damit die Standardfrage nicht fehlt...
Hast du den Brown Out Reset eingeschalten?

[Konrad S. (maybee)]

Jonathan K. schrieb:
> Hallo,
> Durch das Programm kann dies nicht geschehen,

Prima, dass du den Fehler schonmal soweit einkreisen konntest. Das spart 
schonmal die unnötige Suche im Code. Könnte es evtl. sein, dass jemand 
aus deinem Bekanntenkreis den Controller mit einem Fluch belegt hat? ;-)

[Jonathan K. (Gast)]

Joe schrieb:
> irgendwann ist das EEPROM tot, wenn es 100000 Schreibzugriffe hatte.

Hmm, der uC ist noch relativ neu, maximal ein Monat. In der Zeit wurde 
insgesamt - wenns hoch kommt - 2000x schreibend auf das EEPROM 
zugegriffen.


Joe schrieb:
> Hast du in einer Laufschleife in EEPROM geschrieben?

Nein.


Teo Derix schrieb:
> Wetten doch!

Okey, habe mir den Code nochmal angeguckt, eine bestimmte Stelle im 
EEPROM wird definitiv nicht so beschrieben, wie ich es ausgelesen hab. 
Ich verwende feste Adressen, also kann da auch nix durcheinander kommen.


Noch einer schrieb:
> Hast du den Brown Out Reset eingeschalten?

Hmm daran hab ich noch gar net gedacht, muss ich gleich mal gucken. 
Wahrscheinlich ist er auf der Standarteinstellung (deaktiviert).


Konrad S. schrieb:
> Könnte es evtl. sein, dass jemand
> aus deinem Bekanntenkreis den Controller mit einem Fluch belegt hat? ;-)

Wenn das nur so einfach wäre :/


Mir ist auch aufgefallen, dass der gesamte "Inhalt" mit einem Offset von 
0x0100 nochmal exakt gleich auftaucht. Warum ist das so?

EDIT: Habe grade irgendwo gelesen, dass man den EEPROM nicht an der 
Adresse 0x0000 beschreiben soll, was hat es damit auf sich?

[Teo D. (teoderix)]

Jonathan K. schrieb:
> Mir ist auch aufgefallen, dass der gesamte "Inhalt" mit einem Offset von
> 0x0100 nochmal exakt gleich auftaucht. Warum ist das so?

Weil dein Programm fehlerhaft ist!

[Jonathan K. (Gast)]

Teo Derix schrieb:
> Weil dein Programm fehlerhaft ist!

Okey, dann guck dir mal folgendes an (vielleicht steh ich ja aufm 
Schlauch):

...
#define EEPROM_WRITE8(addr,x) eeprom_write_byte((uint8_t*)(addr),(x))
#define EEPROM_WRITE16(addr,x) eeprom_write_word((uint16_t*)(addr),(x))
...
#define EEADDR_WAS_AUCH_IMMER       (0x20)

...

  asm volatile("cli");
  EEPROM_WRITE8(EEADDR_WAS_AUCH_IMMER, was_auch_immer);
  asm volatile("sei");

Alle Schreibvorgänge geschehen exakt nach dem Schema. Ist da irgendwas 
nicht korrekt? Gibt es sonst irgendwas besonderes, was beim Zugriff auf 
das EEPROM beachten muss?

[Jonathan K. (Gast)]

Noch einer schrieb:
> Hast du den Brown Out Reset eingeschalten?

Hab mich da jetzt nochmal genauer informiert und es trifft alles auf 
meinen Fall zu, was ich dazu gelesen habe (z.B. großer Elko an der 
Versorgungsspannung). Werde morgen mal den BOD aktivieren und dann das 
ganze mal etwas testen und gucken, ob die Daten dann ganz bleiben.

[Konrad S. (maybee)]

Jonathan K. schrieb:
> Konrad S. schrieb:
>> Könnte es evtl. sein, dass jemand
>> aus deinem Bekanntenkreis den Controller mit einem Fluch belegt hat? ;-)
>
> Wenn das nur so einfach wäre :/

Wenn die Jungs vom Nachbarn deinen Controller nicht heimlich mit ihrer 
selbstgebauten Neutronenkanone beschießen, was soll es denn sonst sein - 
dein Code ist ja schließlich richtig? ;-)

Wie sieht es mit dem RAM-Verbrauch aus? Evtl. überschreibst du dir dein 
"was_auch_immer" durch sonst_was.

[Oliver S. (oliverso)]

Konrad S. schrieb:
> was soll es denn sonst sein -

BROWN OUT

Oliver

[Jonathan K. (Gast)]

Konrad S. schrieb:
> Wie sieht es mit dem RAM-Verbrauch aus? Evtl. überschreibst du dir dein
> "was_auch_immer" durch sonst_was.

Es sind maximal 256 Byte. Es kommt auch nur ein Zeiger vor, der 
überschreibt hier aber auch nix.


Oliver S. schrieb:
> BROWN OUT

Das denke ich auch, hab den jetzt mal aktiviert, mal gucken, obs jetzt 
nicht mehr passiert.

[Jonathan K. (Gast)]

Bis jetzt ist nix mehr an Daten verloren gegangen -> der zuvor 
deaktivierte BOD war also Schuld.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Ralph S. schrieb:
> Ich hab's erst ein einziges mal "erreicht", den EEPROM zu "töten"
Oh, das geht ganz leicht. Du musst bei deinem Schreibtest einfach 
zwischendurch auch mal die Spannung abschalten...

Jonathan K. schrieb:
> der zuvor deaktivierte BOD war also Schuld.
Ohne BOD wird dir das EEPROM u.U. schon gelöscht, auch wenn dein 
Programm nur lesend darauf zugreift.
Denn sonst wird beim Abfallen zufällig die Lösch-Ladungspume 
eingeschaltet und ein paar Bits im Adressregister kippen um und voila: 
schon ist irgendeine Zelle irgendwie korrupt (naja, nicht irgendwie, 
sondern in der Art, dass die betroffenen Bits nach '1' umkippen)...

[Stefan F. (Gast)]

Ein Ausfall der Spannungsversorgung kann sogar bei Lesezugriffen Daten 
verändern. Ist mir mal passiert, ausgelöst durch ein verpoltes Ethernet 
Kabel.

[Gregor O. (zappes)]

Das mit dem BOD kannte ich noch nicht, und nachdem ich neulich auch 
Probleme mit unerklärlichen gekippten Bits im EEPROM hatte, klingt das 
nach etweas, was ich echt mal ausprübieren könnte. Muchas Gracias.

[Bernd K. (prof7bit)]

Stefan Us schrieb:
> Ein Ausfall der Spannungsversorgung kann sogar bei Lesezugriffen Daten
> verändern. Ist mir mal passiert, ausgelöst durch ein verpoltes Ethernet
> Kabel.

Ich zitiere das nochmal unter Zuhilfenahme von Fettdruck damit dieser 
höchst überraschende Umstand etwas deutlicher wird. Genau das selbe ist 
mir auch schon passiert und ich bin schon fast vom Glauben abgefallen, 
ich hatte nirgendwo Schreibzugriffe und andauernd sind mir irgendwelche 
Bits im EEPROM gekippt bis ich irgendwann BOD aktiviert habe, seither 
ist Ruhe.

[Georg (Gast)]

Bernd K. schrieb:
> bis ich irgendwann BOD aktiviert habe, seither
> ist Ruhe.

Das mag ja sein, aber was sind das für Stromversorgungen, bei denen 
Brown Outs zum Normalbetrieb gehören? Sowas dürfte doch höchstens wenige 
male pro Jahr vorkommen. Ich würde mich nicht damit zufriedengeben, dass 
jetzt mit BOD alles in Ordnung ist.

Georg

[Peter D. (peda)]

Georg schrieb:
> Das mag ja sein, aber was sind das für Stromversorgungen, bei denen
> Brown Outs zum Normalbetrieb gehören?

Das sind sämtliche Stromversorgungen, denn es gibt keine, bei der die 
Spannung in 0ns ansteigt oder abfällt.

Bei jedem Ein- oder Ausschalten arbeitet daher ein MC zeitweise mit 
Unterspannung, wenn das BOD nicht aktiviert ist.

Und im AVR-Datenblatt steht das auch klar drin, Abschnitt "7.4.2 
Preventing EEPROM Corruption".

[Georg (Gast)]

Peter Dannegger schrieb:
> Bei jedem Ein- oder Ausschalten arbeitet daher ein MC zeitweise mit
> Unterspannung, wenn das BOD nicht aktiviert ist

Meinetwegen mag das bei AVR so sein, ein Grund mehr einen solchen 
Prozessor nicht für professionelle Zwecke zu verwenden. Allgemein ist 
die Behauptung aber unsinnig, weil der Reset die Programmausführung erst 
freigibt wenn die Spannung ausreichend ist, und dazu gibt es hunderte 
ICs zur Spannungsüberwachung und Reseterzeugung, die das auch 
sicherstellen - das Signal bei PC-Netzteilen heisst nicht umsonst "Power 
Good". Seit den Zeiten von Z80 & Co laufen Systeme zuverlässig ohne dass 
man spezielle Schaltungen dazu aktivieren müsste. Wenn das so ist, dann 
ist das eine katastrophale Designschwäche von AVR-Prozessoren.

Ob ein Netzteil in 0 ns oder x ms hochläuft, war schon immer völlig 
irrelevant. In einem 5V-System z.B. wird Reset erst freigegeben 100 ms 
nachdem 4,5 V erreicht sind. Wozu braucht man da einen extra Schutz vor 
Unterspannung?

Georg

[Jonathan K. (Gast)]

Georg schrieb:
> Wozu braucht man da einen extra Schutz vor
> Unterspannung?

Wenn du z.B. Kondensator an der Versorgungsspannung hast und du diese 
dann entfernst/ausschaltest.


Was würdert ihr empfehlen, BOD auf 2.7V oder 4.0V? Hab ihn momentan auf 
4.0V und bis jetzt hat so alles funktioniert.

EDIT: Kann es sein, dass BOD 2.7V dafür gedacht ist, wenn man den AVR 
mit 3.3V betreibt?

[Peter D. (peda)]

Georg schrieb:
> Meinetwegen mag das bei AVR so sein, ein Grund mehr einen solchen
> Prozessor nicht für professionelle Zwecke zu verwenden.

Das ist nicht AVR-spezifisch. Bei vielen MCs kann man Funktionen 
abschalten, wenn man sie nicht benötigt.

Das BOD beinhaltet eine Spannungsreferenz und einen Komparator, zieht 
also ständig einige µA. Ist das zuviel, aber man braucht den EEPROM, 
schaltet man es ab und nimmt einen externen Reset-IC mit <1µA.

[Georg (Gast)]

Jonathan K. schrieb:
> Wenn du z.B. Kondensator an der Versorgungsspannung hast und du diese
> dann entfernst/ausschaltest.

Wieso? Bei weniger als 4,5 V (Beispiel) wird Reset wieder aktiv. Wird 
seit den 70er Jahren voriges Jahrhundert so gemacht. Alles inzwischen 
verlernt?

Georg

[Bernd K. (prof7bit)]

Georg schrieb:
> Wieso? Bei weniger als 4,5 V (Beispiel) wird Reset wieder aktiv.

Ja, nennt sich Brown-Out Detection.

Kann man bei AVR konfigurieren mit den Fuses und sollte man auch wenn 
man keinen externen Resetgenerator auf seinem Board hat. Der AVR hat 
sowas eingebaut und man kanns aktivieren oder bleiben lassen.

Genau darum gehts hier. Was war nochmal Dein Punkt?

[Heiner (Gast)]

Bernd K. schrieb:
> Georg schrieb:
>> Wieso? Bei weniger als 4,5 V (Beispiel) wird Reset wieder aktiv.
>
> Ja, nennt sich Brown-Out Detection.
>
> Kann man bei AVR konfigurieren mit den Fuses und sollte man auch wenn
> man keinen externen Resetgenerator auf seinem Board hat. Der AVR hat
> sowas eingebaut und man kanns aktivieren oder bleiben lassen.
>
> Genau darum gehts hier. Was war nochmal Dein Punkt?

bitte keine Trolle fuettern.

lg Heiner