Hallo alle miteinander :P Ich bin gerade am verzweifeln. Ich verwende den EEPROM des Xmega. Hierfür verwende ich die Bibliothek <avr/eeprom.h> mit den zugehörigen Befehlen. Dies funktierte auch so und lief reibungslos über mehrere Wochen. Inzwischen wurde meine Software allerdings schon häufig ergänzt. Ich habe jetzt einen seltsamen Fehler. Alle ein bis zwei Tage kommt es vor, dass ein Wert im EEPROM sich einfach so verstellt. Ich denke mit hoher Sicherheit, dass irgendwo in der Software ein Fehler sein muss, da ich anfangs dieses Problem auch nicht hatte. Bei einigen dieser Werten kann ich mit Sicherheit sagen, dass der Controller das jeweilige Unterpogramm zum neu beschreiben dieser Variable nicht ausgeführt haben kann, da dies nur gegangen wäre wenn ich ihm dies mittels serieller Schnittstelle erlaubt hätte und ich ihm einen neuen Wert zugewiesen hätte. An was könnte das legen? Das Programm ist leider zu groß um es hier zu zeigen. Kann man das EEPROM durch einen Programmierfehler ändern ohne zum Beispiel "eeprom_update_byte" zu benutzen? Sollte man zum ein und auslesen des EEPROM Interrupts vlt sperren oder ist das egal? Aber als alles noch ging hab ich das auch nicht gemacht. Ich hatte einmal den Fehler, das ich vergesesn hatte den Zähler eines Arrays zu begrenzen. Das hatte dann zur Folge, das sich andere Variablen, die damit gar nichts zu tun hatten auch verändert wurden. Aber selbst wenn ich so einen Fehler wieder gemacht hätte (was ich nicht denke) kann ich auf diese Art doch das EEPROM nicht ändern? Einen anderen Controller habe ich auch schon benutzt, aber ohne Erfolg. Ich weiß, dass es schwer nachzuvollziehen ist aber vlt hat ja doch jemand eine Idee. Gruß Matze
Hast Du die Errata zu dem entsprechenden XMEGA gelesen? Gruß, Holm
>An was könnte das legen? Bei den kleinen AVR kann sowas passieren wenn der BrownOutReset (BOD Fuse) nicht aktiviert wird. Ob das beim Xmega auch so ist weiss ich nicht.
holger schrieb: >>An was könnte das legen? > > Bei den kleinen AVR kann sowas passieren wenn > der BrownOutReset (BOD Fuse) nicht aktiviert wird. > Ob das beim Xmega auch so ist weiss ich nicht. hmm ok. Davon höre ich das erste mal. Aber was hat BrownOut mit EEPROM zu tun?
Der BOD würde bei schlechten Spannungsverhältnissen den Zugriff aufs EEPROM verhindern, so das Daten des EEPROM nicht beschädigt werden. Lies aber erstmal unbedingt die Errata. Beim XMegaA1/A3 ist m.E. der EEPROM so gut wie unbrauchbar, ich habe deswegen ein externes 93C46 anbauen müssen.
Matthias Sch. schrieb: > Der BOD würde bei schlechten Spannungsverhältnissen den Zugriff aufs > EEPROM verhindern, so das Daten des EEPROM nicht beschädigt werden. > Lies aber erstmal unbedingt die Errata. > Beim XMegaA1/A3 ist m.E. der EEPROM so gut wie unbrauchbar, ich habe > deswegen ein externes 93C46 anbauen müssen. Sowas ähnliches hatte ich auch gemacht (externes SPI EEPROM), dann aber wieder weg rationalisiert. Es gibt eine Appnote von Atmel die zwar teilweise unsinnigen Code enthält (Readonly Register beschreiben usw.) aber aufzeigt wie man das Problem umschiffen kann. Man muß den XMEGA vor dem schreiben schlafen schicken und danach wieder aufwecken, das funktioniert bei mir. der TO hat aber nicht angegeben mit welchen Prozessor er arbeitet. Glaskugel ist wie übelich gerade in der Werkstatt... Gruß, Holm
Holm Tiffe schrieb: > Man muß den XMEGA vor > dem schreiben schlafen schicken und danach wieder aufwecken, das > funktioniert bei mir. Ja, das hatte ich auch so verstanden, ist bei meiner Anwendung aber absolut nicht drin, da der XMega einen 4kW BLDC Motor steuert. Den kann ich nicht einfach mal fürs EEPROM blockieren.
Holm Tiffe schrieb: > Man muß den XMEGA vor > dem schreiben schlafen schicken und danach wieder aufwecken, das > funktioniert bei mir. Könntest du mir da mal ein Beispiel zeigen?
Aber anfangs hatte das EEPROM doch (meine ich) auch funktioniert^^ Dann kann das EEPROM des Xmega doch gar nicht so schlecht sein?
Vielleicht schreibst Du erst mal welchen Prozessor Du genau verwendest Matthias? Gruß, Holm
Matthias Frank schrieb: >> Man muß den XMEGA vor >> dem schreiben schlafen schicken und danach wieder aufwecken, das >> funktioniert bei mir. Trifft nur für die XMEGAs der ersten Generation und für die ersten Revisionen zu. Aktuell vertriebene XMEGAs haben das Problem nicht mehr.
Hi Mal eine ganz bescheidene Frage: wie oft beschreibst du den EEProm. Er verträgt keine unendlichen Schreibzyklen. Und wenn du schreibst, das er anfangs sauber gearbeitet hat, liegt der Verdacht nahe, das du die zulässigen Schreibzyklen (100000 sind es bei Atmegas) überschritten hast. Dann sind die Zellen nicht mehr sicher und können sonstwas enthalten. Auch ist beim Schreibzyklus soviel ich weiß unbedingt der Interrupt zu sperren. Auch diese Information bezieht sich auf Atmegas. Aber ich denke, das Datenblatt der XMegas gibt darüber Auskunft. Gruß oldmax
Hi Hab grad mal im Datenblatt unter "electrical caracteristics" nachgesehen. Ist so, 100000 Schreibzyklen sind garantiert. Möglicherweise beschreibst du den EEProm ungewollt. Der Fehler deutet jedenfalls darauf hin. Gruß oldmax
Knut Ballhause schrieb: > Matthias Frank schrieb: >>> Man muß den XMEGA vor >>> dem schreiben schlafen schicken und danach wieder aufwecken, das >>> funktioniert bei mir. > > Trifft nur für die XMEGAs der ersten Generation und für die ersten > Revisionen zu. Aktuell vertriebene XMEGAs haben das Problem nicht mehr. Du kanst mal raten warum ich die ganze Zeit darauf bestehe zu erfahren um welche CPU es sich genau dreht... "Aktuell vertrieben" ist auch was anderes als "aktuell produziert"m ich denke ich hätte keine Schwierigkeiten einen A1 odfer A3 zu kaufen ..aktuell. Gruß, Holm
oldmax schrieb: > Hi > Mal eine ganz bescheidene Frage: wie oft beschreibst du den EEProm. Das mit den Schreibzyklen hatte ich mir auch überlegt. Aber das EEPROM wird eigentlich nur selten beschrieben. Also auf die 10000 komme ich nicht. Ich werd aber am Montag nochmal schauen ob nicht doch irgendein Wert vielleicht doch ungewohlt zu oft beschrieben wird. Wenn das EEPROM zu oft beschrieben sein sollte wirkt sich das das auf den kompletten EEPROM speicher aus oder nur für den jeweiligen Adressbereich? >Auch ist beim Schreibzyklus soviel ich weiß unbedingt der >Interrupt zu sperren. Ok, dann werde ich das sperren der Interrupts noch in die Software miteinbringen. Holm Tiffe schrieb: > Du kanst mal raten warum ich die ganze Zeit darauf bestehe zu erfahren > um welche CPU es sich genau dreht... ich verwende den ATXmega128A1AU.
Hier werden die von mir verwendeten Funktionen erklärt: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#EEPROM Hier steht: Es ist darauf zu achten, dass die EEPROM Funktionen nicht durch einen Interrupt unterbrochen werden können. Einige Phasen des Zugriffs sind zeitkritisch und müssen in einer definierten Anzahl Takte durchgeführt werden. Durch einen unterbrechenden Interrupt würde diese Restriktion nicht mehr eingehalten. Auch dieses Detail wird von den avr-libc Funktionen berücksichtigt, so dass man sich als C Programmierer nicht darum kümmern muss. Innerhalb der Funktionen werden Interrupts vor der "EEPROM-Sequenz" global deaktiviert und im Anschluss, falls vorher auch schon eingeschaltet, wieder aktiviert. also kann es daran schon mal nicht legen
>ich verwende den ATXmega128A1AU.
..reicht nicht, ich will es noch genauer wissen, welche Revision?
Im Unterschied zu Dir möchte ich die dafür aktuellen Errata kennen.
Gruß,
Holm
Alle Controller sind Revision A. (ist A die älteste Version?) Im Datenblatt steht hierzu aber nur "Not Sampled"
Dann kannst Du davon ausgehen das Du den EEPROM nur im Sleep Mode beschreiben darfst da sonst die wunderlichsten Dinge passieren können. Oder hast Du eine andere Interpretation für Atmels Aussage "Writing EEPROM or Flash while reading any of them will not work."? Das ist genau das, was ich oben schrieb. Daran ändert die Tatsache das es manchmal oder auch mehrmals doch funktioniert hat eigentlich gar Nichts. Lies Dir die Atmel AppNote AVR1008 durch. Gruß, Holm
Warum bedeutet > Atmels Aussage "Writing > EEPROM or Flash while reading any of them will not work." > das Du den EEPROM nur im Sleep Mode > beschreiben darfst da sonst die wunderlichsten Dinge passieren können. ???
Holm Tiffe schrieb: > Lies Dir die Atmel AppNote AVR1008 durch. > In AppNote AVR1008 steht doch gar nichts vom Atxmega128A1U? Somit trifft das auf mich doch gar nicht zu? Moby schrieb: > Warum bedeutet > >Atmels Aussage "Writing >EEPROM or Flash while reading any of them will not work." > >das Du den EEPROM nur im Sleep Mode >beschreiben darfst da sonst die wunderlichsten Dinge passieren können. > > ??? Das ist in der AppNote AVR1008 erwähnt. holger schrieb: >>An was könnte das legen? > > Bei den kleinen AVR kann sowas passieren wenn > der BrownOutReset (BOD Fuse) nicht aktiviert wird. > Ob das beim Xmega auch so ist weiss ich nicht. Das hatte ich total vergessen zu versuchen. Brown Out ist bis jetzt deaktiviert. Ich werde dies morgen mal umstellen und testen. Ich verpasse den Controller beim einschalten auch mal eine kleine Wartezeit bevor er anfängt alle Daten aus dem EEPROM zu laden. Vielleicht hilft das was, falls die Spannung sich bis dahin noch nicht richtig aufgebaut hat.
Matthias Frank schrieb: > ich verwende den ATXmega128A1AU ^^ Matthias Frank schrieb: > In AppNote AVR1008 steht doch gar nichts vom Atxmega128A1U? ^ Also was jetzt?
Konrad S. schrieb: > Matthias Frank schrieb: >> ich verwende den ATXmega128A1AU > ^^ > Matthias Frank schrieb: >> In AppNote AVR1008 steht doch gar nichts vom Atxmega128A1U? > ^ > > Also was jetzt? Sory mein Fehler Atxmega128A1U
Seit dem ich das mit dem Brown Out versucht habe kam das Problem nicht wieder zum vorschein. Ich hoffe, dass es so bleibt :P
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.