Archiv verlassen und diese Seite im Standarddesign anzeigen : ATMega328P EEPROM hat geänderte Werte ohne das geschrieben wurde
Ich hatte jetzt schon mehrfach mit verschiedenen Controllern der Baureihe ATMega328P Probleme mit dem EEPROM.
Der Controller greift auf Werte im EEPROM zurück, um sich z.B. seine ID zu holen, oder Grenzwerte auszulesen.
Nun kommt es vor, dass diese Speicherstellen irgendwann sporadisch andere Werte enthalten.
Hatte das Problem schon einmal jemand anderes, oder ist das ein generelles Problem bei dem Controller?
Eigenartigerweise werden nur punktuell Bytes verändert.
Vielen Dank schon einmal für Eure Hilfe
sast
Hallo!
Ich denke, dass es ein generelles Problem von EEPROM in µC ist. Ich habe deshalb immer wichtige Werte erfolgreich im Programspeicher ("flash") abgelegt der laut Datenblätter von µCs robuster ist. ;)
Da macht sich aber eine Änderung schlecht, wenn man nicht jedesmal neu programmieren will. Ich ändere Werte per UART und möchte die dann dauerhaft speichern.
Wenn das nicht viel Werte sind, könnte man neue laufend verschiebbare Speicherstellen in EEPROM beschreiben, was EEPROM virtuell vergrössert, falls die in Datenblatt (DB) garantierte Anzahl von Schreibzycklen zu schnell überschreitet wäre.
Erst einmal danke PICture das du dir die Zeit nimmst, dich mit dem Problem zu beschäftigen.
Das Problem ist nicht die Anzahl, sondern die Werte sind einfach irgendwann verändert. Vielleicht ist es ein EMV Problem, aber es betrifft auch nicht alle Controller am selben Gerät.
Ich hatte das Verhalten jetzt zweimal kurz hinter einander. Zuerst in einer Eincontrollerlösung, da dachte ich noch an einen Einzellfall und jetzt aktuell spinnt einer von 3 Controllern am Gerät. Hier tritt allerdings auch statische Aufladung auf, welche durch die Verarbeitung von PP und PE Folie entsteht. Der erste Fall war einfach nur in einer Funksteuerbox eingesetzt. In beiden Fällen habe ich noch je zwei gleichwertige Geräte und bei denen tritt zur Zeit (klopfe dreimal auf Holz) noch kein EEPROM Problem auf.
Dann müsste die Ursache der Veränderungen gefunden werden um sie beseitigen zu können. Ich würde gegen statische Aufladung die µCs mit an GND angeschlossener Alufolie umwickeln um sie davor zu schützen versuchen, usw. :confused:
Die Controller befinden sich bereits separat in Alugehäusen. Allerdings ist eine Ableitung nicht möglich, da sich das Gerät auf einem Plastikrohr bewegt.
Vielleicht könnte man auf dem Rohr geerdete Metallrige (z.B. aus Draht) plazieren, weil es nicht permanenter Kontakt nötig ist, sondern nur die schon vorhandene Ladung ab und zu ableiten. :confused:
Das Flash soll laut Datenblatt für zehntausend Zyklen und das EEPROM für hunderttausend gut sein. Und die Daten sollen sogar bei 85° noch 20 Jahre halten, bei 25° sogar 100. Das da ein generelles Problem vorliegt und das dann nicht in einem Erata dokumentiert ist, kann ich nicht glauben. Eine typische Amerkanische Schadensersatzklage z.B. von einem großen Autohersteller hätte Atmel sonst schon längst in den Ausguß gespült.
ESD direkt wird es auch nicht sein, da kippt das RAM schneller und der Rechner stürzt ab. Um ein EEPROM Byte zu ändern braucht man schon etwas Energie, deswegen dauerts ja auch länger als das Schreiben ins RAM. Aber ein Absturz könnte es schon sein, ein Interrupt zum falschen Zeitpunkt, der Watchdog oder ähnliches. Und wenn man bei mehreren Controlern gleiche Codeteile verwendet, erklärt das auch das gehäufte Auftreten.
MfG Klebwax
Hi Klebwax, das mit dem Interrupt versteh ich noch nicht so ganz. Meinst du, dass während des Schreibens auf den EEPROM eine Unterbrechung stattfindet? Das Brennen selbst kann dann wohl auch durch den Interrupt gestört werden?
Geschrieben wird grundsätzlich nur wenn das Gerät steht. Da könnte ich theoretisch auch die Interrupts deaktivieren, solange die write Routine auf das EEPROM schreibt.
Im Normalfall lese ich beim Start des Controllers nur den EEPROM aus und danach wird da nichts mehr dran gemacht. Schreiben geschieht nur, wenn etwas drin steht, was ich nicht erwarte, oder wenn ich etwas ändere über die Schnittstelle.
Das macht aber beim Einsatz des Gerätes niemand. Und schon gar nicht wird die ID verändert ohne Zugriff über UART. Das bereitet mir Kopfzerbrechen.
PICture das Gerät fährt auf jedem Rohr nur einmal. Da macht es keinen Sinn etwas aufs Rohr zu machen.
Hi,
im Datenblatt steht dass man Interrupts ausschalten soll wenn man ins EEPROM schreibt.Ob das die Lib selber macht ist mir unklar, einmal steht es wird automatisch erledigt, an anderer Stelle dass man selbst die Interrupts ausschalten muss.
Ebenso werden bei Unterspannung und gleichzeitigem Schreiben ins EEPROM die Daten verändert.
LG!
Hier mal einen Codeausschnitt
#define EEPROM_VNULL 230
uint8_t get_eeprom(uint8_t *eeprombuf, uint16_t eepromaddr, uint8_t buflength)
{
eeprom_read_block((void*)eeprombuf, (const void*)eepromaddr, buflength);
return strlen((char*)eeprombuf);
}
uint8_t set_eeprom(uint8_t *eeprombuf, uint16_t eepromaddr, uint8_t buflength)
{
eeprom_write_block((const void*)eeprombuf, (void*)eepromaddr, buflength);
return get_eeprom(eeprombuf, eepromaddr, buflength);
}
for(i = 0; i<11; i++) hilfstext[i] = 0;
get_eeprom((unsigned char*)hilfstext, EEPROM_VNULL, 10);
if((atoi(hilfstext) > 5000) || (hilfstext[0] == 0xFF))
{
for(i = 0; i<11; i++) hilfstext[i] = 0;
hilfstext[0] = '2';
hilfstext[1] = '7';
hilfstext[2] = '6';
hilfstext[3] = '5';
set_eeprom((unsigned char*)hilfstext, EEPROM_VNULL, 10);
for(i = 0; i<11; i++) hilfstext[i] = 0;
get_eeprom((unsigned char*)hilfstext, EEPROM_VNULL, 10);
}
SERVO_NULL = atoi(hilfstext);
Wenn der EEPROM einmal geschrieben wurde, sollte eigentlich bei jedem Controller Neustart nur noch gelesen werden.
Konkret stand beim Auslesen des EEPROMs vor Ort 0x322C3635 im EEPROM statt des erwarteten 0x32373635. Es war also auch nur ein Byte verändert.
Das Gerät ist aber bereits seit November im Einsatz und hatte bis dahin keine Schwierigkeiten.
Habe ich eventuell ein grundlegend falsches Konzept bei der Verwendung des EEPROMs? Wo liegt mein Denkfehler?
Danke
sast
oberallgeier
02.03.2015, 16:41
... Habe ich eventuell ein grundlegend falsches Konzept bei der Verwendung des EEPROMs? Wo liegt mein Denkfehler? ...Gute Fragen, die musste ich mir nicht nur bei EEPROMS häufig stellen - auch wiederholt.
Das Datenblatt ATmega48A/PA/88A/PA/168A/PA/328/P 8271G–AVR–02/2013 gibt im Beispielcode Seite 14 an, dass vor dem Schreiben das Interruptregister gesichert wird, danach werden Interrupts verboten, EEPROM schreiben, Interruptregister zurücklesen.
Auf Seite 19, Punkt 8.4.1 wird auch über mögliche Fehlerursachen diskutiert...
Ich selbst kenne aktuell keine EEPROM-Probleme obwohl bei meinen Controllern immer wieder mal z.B. zulässige Grenzwerte geändert, im EEPROM gespeichert und im Programmablauf auch wieder ausgelesen werden.
Hallo oberallgeier, mal davon abgesehen, dass ich das Interruptabschalten mal noch in meine Betrachtung aufnehmen muss, wurde ja seit November nichts neues mehr an diese EEPROM Stelle geschrieben. Der Wert wurde ja bereits beim ersten Start gesetzt und lief bis letzte Woche ohne Probleme. Speziell diesen EEPROM Speicherbereich habe ich im aktuellen Code noch nicht einmal per UART änderbar gemacht. Genau diese Änderung gibt mir am meisten zu denken.
oberallgeier
02.03.2015, 17:11
... wurde ja seit November nichts neues mehr an diese EEPROM Stelle geschrieben ...Klar. Ich hatte mir einigermassen ordentlich diesen Thread durchgelesen, weil ich selbst schon bei meinen ersten EEPROM-Versuchen unerklärliche Dinge sah. Hier sehe ich - als Möglichkeit, nicht als Diagnose - die oder jene Fehlerquelle aus dem Datenblatt als möglich an. Und zumindest vorstellbar ist, beispielsweise, ein zu langsames Ansteigen der Versorgungsspannung bzw. eine zu kurze start up time des Controllers.
...
8.4.2 Preventing EEPROM Corruption
...
An EEPROM data corruption can be caused by two situations ... Secondly, the CPU itself can execute instructions incorrectly, if the supply voltage is too low ...
Andere Möglichkeit: vor einigen Monaten gabs Drabbel mit den FTDI-232-Bausteinen. FTDI hatte zur Unterscheidung der Clone von den eigenen Bausteinen die unterschiedliche EEPROM-Reaktionszeit genommen - die Clone waren angeblich langsamer. Vielleicht ist Dein Controller in diesem PUnkt etwas ausserhalb der Spezifikation geraten. Alterung, wiederholte Nutzung, wegen irgendeines unverständlichen Grundes.
Vor dem ersten Lesen des EEPROMs wird nach der Initialisation der Ports, des ADC usw noch ca. 1000ms gewartet. Dann lese ich ca. 10 andere Speicherbereiche des EEPROMs aus und komme danach erst zu VNULL. Ich lese auch irgendwie nicht so richtig heraus, dass die data corruption auch beim Lesen auftritt. Es kann natürlich sein, dass die Jungs genau in dem Moment abgeschaltet haben, als das Lesen auf VNULL passieren sollte. Das kann ich nicht ausschließen.
Ist Brownout gesetzt? Das sollte verhindern dass bei zu niedriger Spannung der µC etwas macht. Es steht ja oben dass der µC bei zu niedriger Spannung irgendetwas macht, das muss mit dem Code nichts zu tun haben.
Ich hatte einmal in den weiten des www zu EEPROM Problemen gelesen das bevorzugt die Stelle 0 falsche Werte liefert. Da wurde empfohlen einfach ab Speicherstelle 1 zu schreiben.
Eine weitere Vermutung gab es: es wird im Fehlerfall die Speicherstelle falsch beschrieben, die als letzte geschrieben/gelesen wurde. Als Abhilfe sollte man daher immer nach EEPROM Operationen eine Speicherstelle auslesen die man garantiert nicht benötigt.
Bei mir hatte Brownout die Probleme behoben.
LG!
BOD ist bei mir eigentlich immer an und auf 4V gestellt, da ich mit stabilisierten 5V arbeite.
Ich schreibe auf den EEPROM erst ab 150 da ich immer vergesse ab wann es sicher geht. Die letzte geschriebene Speicherstelle sollte ja spätestens nach einem µC Reset uninteressant sein.
Wenn ich mir überlege, dass der Leseprozess schief gelaufen ist und dadurch der Vergleich wahr wird, dann kann ich mir das fehlerhafte Schreiben nur erklären, in dem der Lese und der anschließende Schreibprozess gestört abgelaufen sind. Dazu müsste dieser Controller eine falsche Fuse Einstellung haben. Das muss ich bei nächster Gelegenheit mal auslesen lassen. Da sollte dann eventuell der Akku zusammengebrochen sein. Das ist ein 13,2V LiFe. Die brechen am Ende der Ladung sehr schnell zusammen.
Aber das das dann mehrmals hintereinander so auftritt gibt mir zu denken.
Noch mal danke an alle die mitdenken. Drüber reden hat mich schon häufig Fehler finden lassen. Man muss zum Erklären häufig intensiver darüber nachdenken als man es allein gemacht hätte.
sast
Ich hatte einmal in den weiten des www zu EEPROM Problemen gelesen das bevorzugt die Stelle 0 falsche Werte liefert. Da wurde empfohlen einfach ab Speicherstelle 1 zu schreiben.
Ach ja, die alte Geschichte. Das Internet vergisst halt nicht. Die wirkliche Sache war die: bei einem ganz bestimmten Atmel Prozessor (bin jetzt zu faul, den genauen Typ rauszusuchen) und von dem bei einer ganz bestimmten Hardware Revision (siehe vorherige Bemerkung, hab ich aber schon mal in einem anderen Thread geposted) gab es einen Bug. Wenn während einer Schreib- oder Löschoperation ins EEPROM ein Reset ausgelöst wurde, wurde das Adresregister auf Null gesetzt, die Schreiboperation aber nicht abgebrochen. So konnte es passieren, daß der EEPROM Inhalt auf Adresse Null zerstört wurde. Dieser Fehler wurde von Atmel in einem Errata beschrieben und in der nächsten Hardware Revision korrigiert. Wieviel von diesen Chips jemals in den Handel gekommen sind und wieviele davon in die Hände von Hobbybastlern gelangt sind, ist mir unbekannt. Das ganze ist mindestens 10 Jahre her, stammt aber eher aus dem vorigen Jahrtausend.
Ein EEPROM ist ein stabiler Speicher. Dieses hält laut Datenblatt zwanzig oder auch hundert Jahre die Daten, wenn man alles richtig macht. Es gibt keine Magie, die Daten verändert. Ich hab den Bug oben so ausführlich beschrieben, um zu zeigen daß auch da keine Magie im Spiel war. Wenn das nicht so wäre, würden sie nicht gebaut werden, für einen professionellen Einsatz wären sie unbrauchbar.
Ich schreibe auf den EEPROM erst ab 150 da ich immer vergesse ab wann es sicher geht.
Da klingt auch so was von Magie oder Handauflegen durch. Es geht auf jeder Adresse gleich sicher.
Es wird also ein Problem in der Software, möglicherweise ausgelöst durch Hardware, sein. Ich würde als erstes mal das Schreiben, wenn ein unplausibler Wert gelesen wird, weglassen. Es wird danach ja sowieso mit den Default-Werten aus dem Programm weitergearbeitet. Und wenn ich damit rechnen muß, daß mir meine Versorgung zusammenbricht, würde ich überhaupt nicht schreiben. Ein gängiges Verfahren ist, die Batteriespannung vor dem Regler zu überwachen, und ein Schreiben nur dann zuzulassen, wenn sie hoch genug ist. Einen Wackelkontakt bekommt man damit aber nicht in den Griff.
MfG Klebwax
Nochmal zum Anfangsproblem. Ich will ja eigentlich gar nicht neu schreiben. Im Normalfall 99,9% der Anwendung wird der Controller gestartet und liest den EEPROM nur aus. Das Überprüfen auf 0xFF habe ich eingebaut, um ein initiales Beschreiben der Speicherstellen sicher zu stellen. Der Controller wird über einen Bootloader programmiert und hat zu Beginn noch nichts im Speicher stehen. Das war der Hauptgrund der Überprüfung. Nun habe ich im konkreten Fall ja bereits seit Monaten mit den Werten gearbeitet und alles war gut.
Ich möchte herausbekommen, was schief läuft. Dabei ist mir egal ob das Magie oder Fehlverhalten genannt wird. Ich schließe nicht aus, dass ich der Verursacher des Fehlers bin, aber wenn ich nicht weiß was da verkehrt läuft, kann ichs nicht ändern.
Was muss passieren, dass mein Programm mit dem gezeigten Codeschnipsel der Meinung ist, dass es den Wert neu schreiben soll, oder was passiert "magisches" das EEPROM Stellen ihre Werte ändern.
Als Beispiel habe ich einen Controller in der zu betrachtenden Box gehabt, bei dem das 0x2C falsch für den VNULL stand und die ID von vorher 01 auf 99 geändert war. Den Controller haben wir getauscht und einen neuen auf 01 adressiert. Nun trat nach einem Einsatz von 1,5 Tagen wieder ein Fehler auf und zwar wurde die ID zu 00 geändert. Mein Code überprüft auf >99 und 0xFF und schreibt bei true die ID auf 99. Das kann also beim ersten Fall passiert sein. Warum auch immer. Aber die ID 00 kann er nicht einfach schreiben. Das hab ich nirgends so programmiert. Jetzt könnte ich sagen, vielleicht hat ja der 2. Controller sowieso einen weg und ich sortiere den mal aus. Dann bleibt immernoch Controller 1 mit dem Fehler in VNULL. Was muss da passieren, dass das auftritt?
Zur Info für alle die es interessiert.
Hatte jetzt die Möglichkeit alle Informationen zusammenzutragen. Das Ganze rundet sich zusammen mit den Aussagen hier im Forum zu einem Bild.
Der BODLEVEL in den FUSES war bei dem entsprechenden Controller disabled.
Der angeschlossene 4,1Ah LiFe Akku wurde nach dem Benutzen auf 4548mAh laut Ladegerätanzeige aufgeladen. Was zwar jetzt augenscheinlich mehr ist, als der Akku eigentlich fasst. Mir aber auf der anderen Seite zeigt, dass er runter war.
Wenn ich jetzt davon ausgehe, dass die Spannung abgesunken ist bei Belastung, dann macht das Verhalten einen nachvollziehbaren Eindruck.
Der BOD ist jetzt auf 4,3V eingestellt und nun bin ich mal gespannt, ob ab jetzt Ruhe ist.
Noch einmal vielen Dank an euch alle.
sast
Wenn ich jetzt davon ausgehe, dass die Spannung abgesunken ist bei Belastung, dann macht das Verhalten einen nachvollziehbaren Eindruck.
Der BOD ist jetzt auf 4,3V eingestellt und nun bin ich mal gespannt, ob ab jetzt Ruhe ist.
Das Problem könnte sich so ergeben: Wenn Vcc zu niedrig ist, wird etwas falsches aus dem EEPROM gelesen. Das alleine ist eigentlich noch kein Problem für die Datenintegrität des EEPROMS, wenn die Spannung wieder ok ist, sollte alles wieder in Ordnung sein. Wenn ich aber das Programm richtig verstanden habe, wird in diesem Fall, bei weiter fallender Spannung, ins EEPROM geschrieben. Das zerstört dann irgendwelche Daten.
Als erstes sollte also das Schreiben vermieden werde, solange nicht gerade eine Konfiguration statt findet. Ob die BOR Spannung ok ist, hängt von der Clockfrequenz ab. Der Prozessor läuft, abhängig von der Clock, bis 1,8V . Im Datenblatt stehen auch einige Anmerkungen über den sicheren Umgang mit dem EEPROM, sicher nicht ganz umsonst.
Viel Erfolg
MfG Klebwax
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.