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.
Meine Kristallkugel sagt mir, dass Du wahrscheinlich debuggst. Während des Debuggens mit dem AVR-Studio wird dann das EEPROM gelöscht.
Sorry, die Kristallkugel liegt leider nicht richtig... Sondern das EEPROM wird irgendwann beim Kunden gelöscht...
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
gab's da nicht auch mal was mit eeprom-zugriff und brown-out-detection?!
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...
@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 ...
> Brown-Out sollte eigentlich auf 2.7V gesetzt sein, um hier save zu sein.
Prozessortakt zu schnell für 2.7V?
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...
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!
... 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.
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.
> ... der Kunde hat aber nichts mit ionisierender Strahlung in der Nähe?
die wäre aber auch für die flash nicht gut.
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.