Datenverlust internes EEPROM AVR

Hi,

ich hatte die selben Probleme bei einem ATmega162 und Atmega32.

Erst nach genauem Studium des Atmega162-Datenblatt bin ich zur
Überzeugung gekommen das es doch mit der Brown-out Detection zu tun
haben muss.

Seit dem ich den brown-out entsprechen setze sind meine Progleme
verschwunden.

Lese mal beim Atmega162 nach, da ist der brown-out zwar etwas variabler
aber dafür besser beschrieben.

MfG
Ralph

Hallo Ralph,

beim 8535 kann ich keinen brown out
programmieren. Der hat sowas gar nicht.

Wenn ich so keine Lösung finde, so
müsste ich auf einen Controller mit
brown out umsteigen.

Kann das wirklich sein, daß Atmel so
wenig dabei gedacht hat?

Es muss doch mit dem externen Reset
gehen. Oder nicht?

Die eine Application note klang sehr
kompliziert. Da muss ich doch auch
einen integrierten Baustein nehmen
können.

Der Spannungsregler ist von TI, nicht
von LT. Das ist oben falsch.

Gruss
   Matthias

Hi

betrifft das Problem alle EEPROM-Addressen oder nur Address 0? Address
0 sollte man bei AT90S... nicht verwenden. Die kann bei denen sehr
leicht vernichtet werden.

Aber ein Umstieg auf Mega8535 ist bestimmt auch kein Fehler.

Matthias

@Matthias:
Danke für Deinen Hinweis.
Das Problem scheint auch andere Stellen zu betreffen.
Die Zeit 0min, die nun betroffen war liegt weiter hinten.
Es scheint eher zufällig
zu sein, welche Stelle da betroffen wird.
Aber Du hast recht, zunächst schien die Stelle 0
besonders stark betroffen zu sein.

Ist denn der Atmel wirklich so ein Schrott, daß noch
nicht mal das interne EEPROM zuverlässig genutzt werden kann?
Wenn ein externer Resetbaustein dran ist, sollte doch
so etwas sicher zu vermeiden sein.

Ich habe nun 3 weitere 8535 für 3 weitere Geräte gekauft
und hoffe, daß damit das Problem dann irgendwann einmal
Vergangenheit sein wird.

512 Byte, die keiner nutzen kann, welch Witz . . .

Gruss
   Matthias

Hi...

Ich hatte das Problem mit einem 2313 (mit 1200 sowiso). Ich nahm an,
dass jeweils die Zelle beschädigt wurde, auf die EEAR zeigte. Nachdem
ich hinter jedem EEPROM-(Read)-Zugriff EEAR wieder auf eine unbenutzte
Zelle setzte, trat das Problem nicht mehr auf. Das kann aber auch
Zufall gewesen sein... ;-))

...HanneS...

P.S.: Gibt es eigentlich einen Unterschied zwischen Matthias Weisser
und Mattwei?

In den Atmel Error Sheets steht geschrieben, dass an EEprom-Stelle 0
keine Daten hingeschrieben werden sollten. Ein bekannter Bug.
Vor allem bei unzureichender Resetbeschaltung. Die neuen AVRs
verhindern das mit dem Brown -Out Dedektor ;-). Mit den alten
AVRs hat es sich bewährt, Spannungsausfälle bereits lange vor der 5 V
Schwelle zu dedektieren (INT Eingang, vor dem V-Regler) und den AVR
nach nochmaliger Datensicherung im EE in den Powerdown Zustand zu
fahren.

Josef

Hi

@...HanneS...
Der eine schreibt sich mit 'ß' und der andere mit 'ss' :-)

Matthias (der mit 'ß')

Hi

@HanneS, Matthias:
Man schrieb mich bei der Geburt auch mal mit ß.
In den Ausweisen aber mit ss.
Und nach der Namensänderung wirklich mit ss.

@Peter:
anfangs verwendete ich einen TPS77450 von TI.
Dann baute ich einen TPS77250 oder einen
TPS77150 ein. Dummerweise habe ich die Geräte
verliehen, so daß ich nicht mehr sicher sagen
kann, ob nun der 150 oder 250 drin ist.

Sind diese Bausteine aus Eurer Sicht nicht
geeignet?

ich habe noch mal das Datenblatt der
TI-Regler angesehen.
Der TPS77150 löst unterhalb 95% der Ausgangsspannung RESET aus.
Erst nach 220ms wird der RESET wieder HI.

Der TPS77250 hat ein Power good Signal, das bei 82% der
Ausgangsspannung wirkt. Oberhalb 82% wird PG Hi-Z. Eine Verzögerung
gibt es dabei nicht.

Eigentlich müssten doch beide Bausteine gehen. Oder?
Kann es sein, daß die 220ms nötig sind, damit der Reset
innen genug Zeit hat Register und Speicher wieder zu definieren?

Gruss
   Matthias

ZITAT:

Ich hatte das Problem mit einem 2313 (mit 1200 sowiso). Ich nahm an,
dass jeweils die Zelle beschädigt wurde, auf die EEAR zeigte. Nachdem
ich hinter jedem EEPROM-(Read)-Zugriff EEAR wieder auf eine unbenutzte
Zelle setzte, trat das Problem nicht mehr auf. Das kann aber auch
Zufall gewesen sein... ;-))

...HanneS...

Danke HanneS, Problem gelöst.

War wohl doch kein Zufall.
Hatte das Prob. auch auf einem 2313 und mir schon den Wolf gesucht in
meinem Quelltext.
Das mit Adresse 0 wusste ich schon, aber dass die Adresse auf die EEAR
zeigt auch betroffen ist :(

Hallo Jürgen...

Danke für deine Bestätigung, bisher war es nur Vermutung aber nun kann
ich davon ausgehen, dass mein Verdacht stimmt.

Bit- & Bytebruch...
...HanneS...

Dieser Tip für den At90S2313 war wirklich gold wert :))

Grüsse,
Manfred

Diese Datenverluste haben mich damals tierisch aufgeregt und ich bin aus 
Frust zu einer anderen Controllerfamilie gewechselt :)

Hallo zusammen,

könnte es möglich sein, dass der selbe Effekt auch beim Tiny13 auftritt?
Ich habe bei einem Fahrtregler auch das Problem, dass sich das EEPROM 
manchmal "vergisst".

Gruß,
Christian

Hi,

wie wäre denn die empfohlene Methode z.B. mit AVRs neuerer Generation 
(mega88) um das EEPROM fehlerfrei zu verwenden?
Ich habe erst vor kurzem beim aktuellen Projekt erstmals auf das interne 
EEPROM zugegriffen und wollte es für ein paar Grundeinstellungen 
verwenden.

Ciao...

Ja, das Problem kenne ich auch zur Genüge.
Natürlich sollte man bei allen neuen AVRs den Brown-Out einschalten. 
Aber es hat sich gezeigt, daß auch dies nicht 100% gegen Datenverlust 
schützt. Deshalb habe ich zusätzlich die ersten beiden Speicherstellen 
des EEPROM nicht benutzt, da nur diese meist vom Datenverlust betroffen 
waren. Seidem habe ich weitgehend Ruhe. Den Tipp mit dem EEAR werde ich 
zusätzlich mal einbauen, das sollte eigentlich dann die 100% Lösung 
sein.

Erwin

Moin,

Ich hatte ebenfalls das Problem. EEAR nach jeder Nutzung auf die letzte 
existente EEPROM-Adresse zu setzen, hat meine Nutzdaten heile gelassen - 
aber ich habe beim Programmieren gesehen, dass er dafür eben am Ende des 
EEPROMs Mist gemacht hat. (ich lese vor dem Flashen das EEPROM aus und 
schreibe nach dem Chip Erase den alten Inhalt zurück)

Jetzt, mit BOD aktiviert, hatte ich bisher keine weiteren Probleme. 
"Echter" Praxistest am 12V-KFZ-Bordnetz kommt aber erst noch...

MfG, Heiko