Druckbare Version
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
Wenn der EEPROM einmal geschrieben wurde, sollte eigentlich bei jedem Controller Neustart nur noch gelesen werden.Code:
#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);
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
Gute Fragen, die musste ich mir nicht nur bei EEPROMS häufig stellen - auch wiederholt.Zitat:
... Habe ich eventuell ein grundlegend falsches Konzept bei der Verwendung des EEPROMs? Wo liegt mein Denkfehler? ...
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.
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.Zitat:
... wurde ja seit November nichts neues mehr an diese EEPROM Stelle geschrieben ...
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.Zitat:
Zitat von Datenblatt m328
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
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.Zitat:
Zitat von damfino
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.
Da klingt auch so was von Magie oder Handauflegen durch. Es geht auf jeder Adresse gleich sicher.Zitat:
Ich schreibe auf den EEPROM erst ab 150 da ich immer vergesse ab wann es sicher geht.
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?