www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik EEPROM in ATMEGA48 gelöscht


Autor: Pepe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
hab eine Schaltung mit einem ATmega48. Verwende das
EEPROM um die Seriennummer dieser Schaltung zu speichern.
Jetzt hatte ich es schon einige Male, dass das EEPROM komplett
leer war, sprich die Seriennummer weg.
Jetzt sieht es nur so aus, dass in den Bereich im EEPROM mit der
Seriennummer nicht geschrieben wird und auch die sonstigen
Schreibbefehle sollten eher harmlos sein, da ich nur auf feste
Adressen zu greife. ( Ohne Schleifen etc. )

Kann mir jemand helfen ?

Danke,
Pepe.

Autor: Tobias Hoffmann (obazda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Kristallkugel sagt mir, dass Du wahrscheinlich debuggst. Während 
des Debuggens mit dem AVR-Studio wird dann das EEPROM gelöscht.

Autor: Pepe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, die Kristallkugel liegt leider nicht richtig...
Sondern das EEPROM wird irgendwann beim Kunden gelöscht...

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

EESAVE-Fuse gesetzt?

MfG Spess

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Atmel Datasheet:

"5.3.6 Preventing EEPROM Corruption
During periods of low VCC, the EEPROM data can be corrupted because the 
supply voltage is
too low for the CPU and the EEPROM to operate properly. These issues are 
the same as for
board level systems using EEPROM, and the same design solutions should 
be applied.
An EEPROM data corruption can be caused by two situations when the 
voltage is too low. First,
a regular write sequence to the EEPROM requires a minimum voltage to 
operate correctly. Secondly,
the CPU itself can execute instructions incorrectly, if the supply 
voltage is too low.
EEPROM data corruption can easily be avoided by following this design 
recommendation:
Keep the AVR RESET active (low) during periods of insufficient power 
supply voltage. This can
be done by enabling the internal Brown-out Detector (BOD). If the 
detection level of the internal
BOD does not match the needed detection level, an external low VCC reset 
protection circuit can
be used. If a reset occurs while a write operation is in progress, the 
write operation will be completed
provided that the power supply voltage is sufficient."


Peter

Autor: mui (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gab's da nicht auch mal was mit eeprom-zugriff und brown-out-detection?!

Autor: Tobias Hoffmann (obazda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn die EESAVE nicht gesetzt wird, wird bei jedem chip Erase das EEPROM 
gelöscht. Kommt sowas bei Dir vor?? Z.B. beim SPI Programmieren beim 
Kunden, etc...

Autor: Pepe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@obazda:
Ich speichere nur 5 Byte weitere Statuswerte im EEPROM aus
der Firmware raus. Also kein SPI Programmieren beim Kunden ...

@mui & @Peter:
Brown-Out sollte eigentlich auf 2.7V gesetzt sein, um hier save zu sein. 
Kann allerdings gerade nicht sagen, ob dies bei den gelöschten ATmegas 
auch der Fall ist. Werd ich prüfen...

Hatte eigentlich gehofft, dass es noch etwas Bekanntes gibt ...

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Brown-Out sollte eigentlich auf 2.7V gesetzt sein, um hier save zu sein.

Prozessortakt zu schnell für 2.7V?

Autor: Pepe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
3,4...MHz sind laut Datenblatt noch im Rahmen.
Läuft mit 5V VCC. Haben die 2.7V nur, weil die Schaltung
an einem Bus hängt und beim Einstecken von weiteren
Schaltungen die Spannung auf 4-4.5V einbricht und somit
machen die 4.3V Brown Out manchmal Probleme...

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gibt es hier etwas Neues?

Ich habe leider ein ähnliches Problem bei einem M168! Einzelne Werte 
scheinen - recht unregelmäßig, aber doch - zu kippen!

Auch ich habe den BrownOut auf 2.V gesetzt, kann aber ebenfalls nicht 
sagen, ob es bei den Devices, bei denen es auftrat, auch schong gesetzt 
ist!

Ich betreibe die HW aber mit 16MHz und das ist wohl zu hoch für 2.V...
D.h. hier könnte das Problem liegen...
Allerdings schreibe ich nur zu definierten Zeitpunkten ins EEPROM und 
nicht in der Gegend des Abschaltens. Da EEPROM Zellen ja rein 
theoretisch nicht einfach so kippen, sondern nur wenn sie geschrieben 
werden, müsste es schon der schreibende Teil der HW sein, der 
empfindlich auf Unterspannung ist, und nicht der Speicher selbst...
Was für mich widerum heißt, dass der für 16MHz zu niedrige BrownOut 
eigentlich nicht das Problem sein kann, denn die Einschränkung "niedrige 
Spannung - niedrige Höchstfrequenz" kommt doch von der zur Verfügung 
stehenden Energie und so lange das Schreiben des EEPROMs nicht 
angestoßen wird, sollte da auch nichts passieren, außer die SFR - Bits 
beginnen frisch-fröhlich zu hüpfen und ChaChaCha zu tanzen!

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... der Kunde hat aber nichts mit ionisierender Strahlung in der Nähe? 
Wir hatte mal so einen Fall, wo das ganze bei einer Röntgenanlage 
verbaut war.

Autor: H.Joachim Seifert (crazyhorse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe dasselbe Problem mit einem ATMega88...
Ich dachte eigentlich, die EEPROM-Probleme bei Atmel seien erledigt. Mit 
Mega8/16/32 hatte ich auch nie Probleme, jetzt geht der Mist wieder los 
:-(
Bei den 90Sxxxx habe ich das gar nicht mehr verwendet, immer ext. 
drangebastelt, wenn eins erforderlich.
Es ist nicht nachvollziebar, wann und warum einzelne Zellen gelöscht 
werden. Passiert im ganz normalen Betrieb, nicht mal ein Reset 
zwischendurch.
Brownout ist gesetzt (4,5V), Betrieb mit 5V.
Da es meist die untersten Zellen betraf, habe ich einfach mal testweise 
10Bytes freigelassen. Wurde besser, aber nicht 100% sicher.
Hoffe jetzt mal, dass es mit dem 88PA besser ist, aber so richtiges 
Vertrauen habe ich nicht mehr :-(
Ja, ich weiss, meistens liegts doch an der eigenen Software. In dem Fall 
glaub ich das aber inzwischen nicht mehr.

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ... der Kunde hat aber nichts mit ionisierender Strahlung in der Nähe?
die wäre aber auch für die flash nicht gut.

Autor: Tolgra (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie oft wird Dein EEPROM gelesen?
Mir sind auch schon EEPROM durch permanentes Lesen einiger 
Speicherzellen im ms-Abstand gestorben. Das ging sogar deutlich 
schneller, als es theoretisch durch Kaputtschreiben möglich wäre.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.