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!
alles über meinen Rasenmäherroboter (wer Tippfehler findet darf sie gedanklich ausbessern, nur für besonders kreative Fehler behalte ich mir ein Copyright vor.)
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 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.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
Strom fließt auch durch krumme Drähte !
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
雅思特史特芬
开发及研究
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
Strom fließt auch durch krumme Drähte !
Berechtigungen
Zitieren
Lesezeichen