EEPROM ändert sich manchmal von allein

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

Hast du in einer Laufschleife in EEPROM geschrieben?

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

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 Derix schrieb:
> Weil dein Programm fehlerhaft ist!

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

1

...

2

#define EEPROM_WRITE8(addr,x) eeprom_write_byte((uint8_t*)(addr),(x))

3

#define EEPROM_WRITE16(addr,x) eeprom_write_word((uint16_t*)(addr),(x))

4

...

5

#define EEADDR_WAS_AUCH_IMMER       (0x20)

6

7

...

8

9

  asm volatile("cli");

10

  EEPROM_WRITE8(EEADDR_WAS_AUCH_IMMER, was_auch_immer);

11

  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?

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

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

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

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

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?

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