Habe ein kleines Problem mit meinem ATmega644 und zwar wen ich ihn länger (über nacht) aus lasse kippen mir immer wieder mahl bits im eeprom um! Der sitzt auf so einem AVR-NET-IO Board als Netzteil ist da ein eher Reuiges Steinzeit Trafo Netzteil (aber schon mit einem recht tutem gabs das problem, zudem hat die platime ja e'h nen eigenen gleichtichter, elko und linearregler). Ne idee woran das liegen kann? oder gibts wo ein code sample das mir paritätzdaten fürs eeprom errechnet speichert und im flipp fall wiederherstellt?
>Habe ein kleines Problem mit meinem ATmega644 und zwar wen ich ihn >länger (über nacht) aus lasse kippen mir immer wieder mahl bits im >eeprom um! brown out eingeschaltet? Oliver
>lasse kippen mir immer wieder mahl bits >Reuiges Steinzeit Trafo Netzteil >recht tutem gabs das problem >e'h nen eigenen gleichtichter >paritätzdaten >flipp fall wiederherstellt Mann, wie sieht denn der Programmcode aus, so ähnlich? Oder ist da ein "beknateter Combiler" am Werk, der alles in lesbare Form "pringt". Es wird immer kolportiert, daß über die Einstellungen zum brown-out alles machbar ist. Forsch doch mal in dieser Richtung.
>brown out eingeschaltet?
emm... nö
wäre aber besser oder?
Prog code ist der SmartWebserver aus der Codesammlung
>wäre aber besser oder? Wenn Atmel das schon von sich aus so ins Datenblatt schreibt, könnte es einen Grund dafür geben :-) brwon out ist bei AVR-eeprom-Nutzung ein Muss. Ohne geht es nicht. Oliver
Brown-out wurde ja schon genannt. Ich zurre das aber trotzdem immer schön mit CRC fest und nehme "Best-3-of-5". Zum Schluß dann noch den EEPROM-Zeiger auf eine ungenutzte Stelle versetzen. Also: 1.) Brown-Out 2.) CRC bilden 3.) Mehrfach speichern und dann die Mehrheit gewinnen lassen 4.) EEPROM-Zeiger auf ungenutzte Zelle zeigen lassen Dann kann man sich auch recht gut auf die Daten verlassen :-) Chris
>Dann kann man sich auch recht gut auf die Daten verlassen :-)
Du hast doch sicherlich auch gemessene statistische Daten, die
nachweisen, wie oft Maßnahme 2.) und 3.) fehlerhafte Daten korrigieren.
Also, wie häufig kommt das vor?
Oliver
Oliver wrote: >>Dann kann man sich auch recht gut auf die Daten verlassen :-) > > Du hast doch sicherlich auch gemessene statistische Daten, die > nachweisen, wie oft Maßnahme 2.) und 3.) fehlerhafte Daten korrigieren. > Also, wie häufig kommt das vor? > > Oliver Naja, ich habe hier meine, zugegebenermaßen geringe, Erfahrung. Wirkliche statistische Daten gibt es bei mir (leider) nicht. Meine AVRs müssen in recht stark verseuchten Umgebungen (Industriemaschinen) zurechtkommen und nicht immer kann für eine korrekte Schirmung und Abblockung der Eingänge/Stromversorgung gesorgt werden. Zu 2.): Ja, es kommt durchaus schon vor, dass die CRC eines Blocks angesprochen hat, weil ein Bit gekippt war. Da ist man froh, wenn man noch Sicherheitskopien (bei mir vier) hat, auf die man zurückgreifen kann. Bei entsprechenden Updates der Steuerungen hat man über ein bis zwei Jahre hinweg immer mal wieder so etwas im Fehlerspeicher (ja, der ist auch mit CRC im EEPROM ;-) Noch zu 3.) CRC ist schön, hilft mir aber nicht so viel. Denn die Erkennung eines Fehlers ist eine schöne Sache. Die Anlage benötigt aber die Daten. Was auch oft vergessen wird: Redundanz ist gerade beim Schreiben des EEPROMS wichtig. Was mache ich, wenn mir der AVR beim Schreiben des Blocks abschmiert? Mit den Backups habe ich zumindest die alten Werte in korrekter Form. Ist natürlich auch eine Frage der Menge der Daten, schon klar. Genau deswegen hat man immer zwei Sicherungskopien. Murphy schlägt nämlich immer dann zu, wenn gerade das Backup gefahren wird und nimmt (in meinem Fall) beide Festplatten mit ins Nirvana. Da freut man sich dann ehrlich über die dritte im Bankschließfach ;-) Zu 4.) Da hatte ich mal Probleme mit AVRs, die oft ein und ausgeschaltet wurden. Irgendwie zerschoss es immer die Stelle, auf die der Zeiger nach der letzten Operation gezeigt hatte - warum auch immer. Nach Verlegung des Zeigers ganz ans Ende war Ruhe. Seitdem baue ich das ein - schaden kann es wohl nicht. Seit ich diese Punkte beachte, gab es keinen einzigen (teuren) Ausfall wegen falscher EEPROM-Daten mehr. Letztlich zählt bei mir das. Chris
HAbe mal broun out an gemacht, wie kannn ich den "EEPROM-Zeiger auf ungenutzte Zelle zeigen lassen "? Ich mache die zugriffe mit eeprom_read_byte, oder _word oder so. Ich brauche die ganzen 2K oder zumindest das meiste mit 1K keine chanse, die ganzen labels/LCD screans/roules meines webservers sind etwas platzhungrig, 512 byte für redundanz könnte ich entberen wens da nen fertigen code gäbe.
> und zwar wen ich ihn länger (über nacht) aus lasse > kippen mir immer wieder mahl bits im eeprom um! Das "Umkippen" ist ein uralter AVR-Fehler, und zwar kippen dir nur Bits in Richtung '1' um (vereinfacht gesagt: die werden gelöscht). Das passiert aber nicht im ausgeschalteten Zustand, sondern genau beim Ausschalten (die Ladungspumpe wird eingeschaltet und der EEPROM-Zeiger kippt um). Nur merkst du es erst beim nächsten Wiedereinschalten. Abhilfe wie gesagt: Brown-Out einschalten. > wie kannn ich den "EEPROM-Zeiger auf ungenutzte Zelle zeigen lassen"? Das hilft nichts. Denn genau dieser Zeiger geht als erstes in die Binsen, wenn die Spannung wegbricht.
>Zu 2.): Ja, es kommt durchaus schon vor, dass die CRC eines Blocks >angesprochen hat, weil ein Bit gekippt war. Da ist man froh, wenn man >noch Sicherheitskopien (bei mir vier) hat, auf die man zurückgreifen >kann. >Bei entsprechenden Updates der Steuerungen hat man über ein bis zwei >Jahre hinweg immer mal wieder so etwas im Fehlerspeicher (ja, der ist >auch mit CRC im EEPROM ;-) Danke für die Info. Oliver
Wenn die Gefahr besteht, daß Daten gerade geschrieben werden, wenn die Betriebsspannung wegbricht, muß man die Spannung überwachen, genug Leistung für das Wegspeichern einiger Bytes in einem Kondensator puffern und das Schreiben von Daten unterbinden, wenn die Spannung nicht mehr reicht. Dann kann man auch davon ausgehen, daß die geschriebenen Daten richtig sind. Bei Schaltungen, die von einem Netztrafo versorgt werden, kann man auch die Impulse der Wechselspannung mitzählen. Hören sie auf, muß das EEPROM-Schreiben gezielt abgebrochen werden, also das angefangene Speichern gegebenenfalls beenden und dann den Controller anhalten oder was auch immer.
Lothar Miller wrote: >> wie kannn ich den "EEPROM-Zeiger auf ungenutzte Zelle zeigen lassen"? > Das hilft nichts. Denn genau dieser Zeiger geht als erstes in die > Binsen, wenn die Spannung wegbricht. Wie oben geschrieben: meine Erfahrungen sehen da anders aus. Wenn der Controller abschmiert, ist die Zelle, auf die der Zeiger zeigt, besonders gefährdet. Wenn die Spannung komplett wegbricht, tut einem eh nix mehr weh ;-) Chris
Travel Rec. wrote: > Wenn die Gefahr besteht, daß Daten gerade geschrieben werden, wenn die > Betriebsspannung wegbricht, muß man die Spannung überwachen, genug > Leistung für das Wegspeichern einiger Bytes in einem Kondensator puffern > und das Schreiben von Daten unterbinden, wenn die Spannung nicht mehr > reicht. Dann kann man auch davon ausgehen, daß die geschriebenen Daten > richtig sind. Bei Schaltungen, die von einem Netztrafo versorgt werden, > kann man auch die Impulse der Wechselspannung mitzählen. Hören sie auf, > muß das EEPROM-Schreiben gezielt abgebrochen werden, also das > angefangene Speichern gegebenenfalls beenden und dann den Controller > anhalten oder was auch immer. Alles richtig. Das hilft einem aber nur nix, wenn der Controller direkt mit abstürzt. Und eine halb geschriebene Konfiguration hilft zumindest in meinen Fällen nicht viel. Da ist die alte dann besser. Ein "Dann kann man auch davon ausgehen" reicht zumindest bei mir nicht - ich muss mich darauf verlassen können und das war bisher öfter nicht der Fall. Chris
Thread beobachten
Seitenaufteilung abschaltenBitte 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.