ich habe einen AT90S8535. Und dazu einen Spannungsregler von LT mit Resetausgang und Resetverlängerung. Ich schreibe über die serielle Schnittstelle vom PC aus Daten ins interne EEPROM Dummerweise verändern sich diese Daten manchmal später. Am brown out sollte es nicht liegen, da habe ich ja den TI-Baustein. Was kann denn da noch falsch sein?
Hi, ich hatte die selben Probleme bei einem ATmega162 und Atmega32. Erst nach genauem Studium des Atmega162-Datenblatt bin ich zur Überzeugung gekommen das es doch mit der Brown-out Detection zu tun haben muss. Seit dem ich den brown-out entsprechen setze sind meine Progleme verschwunden. Lese mal beim Atmega162 nach, da ist der brown-out zwar etwas variabler aber dafür besser beschrieben. MfG Ralph
Hallo Ralph, beim 8535 kann ich keinen brown out programmieren. Der hat sowas gar nicht. Wenn ich so keine Lösung finde, so müsste ich auf einen Controller mit brown out umsteigen. Kann das wirklich sein, daß Atmel so wenig dabei gedacht hat? Es muss doch mit dem externen Reset gehen. Oder nicht? Die eine Application note klang sehr kompliziert. Da muss ich doch auch einen integrierten Baustein nehmen können. Der Spannungsregler ist von TI, nicht von LT. Das ist oben falsch. Gruss Matthias
Hi betrifft das Problem alle EEPROM-Addressen oder nur Address 0? Address 0 sollte man bei AT90S... nicht verwenden. Die kann bei denen sehr leicht vernichtet werden. Aber ein Umstieg auf Mega8535 ist bestimmt auch kein Fehler. Matthias
@Matthias: Danke für Deinen Hinweis. Das Problem scheint auch andere Stellen zu betreffen. Die Zeit 0min, die nun betroffen war liegt weiter hinten. Es scheint eher zufällig zu sein, welche Stelle da betroffen wird. Aber Du hast recht, zunächst schien die Stelle 0 besonders stark betroffen zu sein. Ist denn der Atmel wirklich so ein Schrott, daß noch nicht mal das interne EEPROM zuverlässig genutzt werden kann? Wenn ein externer Resetbaustein dran ist, sollte doch so etwas sicher zu vermeiden sein. Ich habe nun 3 weitere 8535 für 3 weitere Geräte gekauft und hoffe, daß damit das Problem dann irgendwann einmal Vergangenheit sein wird. 512 Byte, die keiner nutzen kann, welch Witz . . . Gruss Matthias
Du hast ja nicht gesagt, welchen Reset-IC Du nimmst. Wichtig ist, daß der Reset noch bis 1V gehalten wird, damit die CPU nicht verrückt spielt. Wichtig ist auch, daß der Reset erst dann zu Ende ist, wenn der Quarz richtig angeschwungen ist (>50ms) und die Betriebsspannung (4,5V) auch wirklich erreicht ist. Z.B. mit dem MAX690 sollte alles o.k. sein. Peter
Hi... Ich hatte das Problem mit einem 2313 (mit 1200 sowiso). Ich nahm an, dass jeweils die Zelle beschädigt wurde, auf die EEAR zeigte. Nachdem ich hinter jedem EEPROM-(Read)-Zugriff EEAR wieder auf eine unbenutzte Zelle setzte, trat das Problem nicht mehr auf. Das kann aber auch Zufall gewesen sein... ;-)) ...HanneS... P.S.: Gibt es eigentlich einen Unterschied zwischen Matthias Weisser und Mattwei?
In den Atmel Error Sheets steht geschrieben, dass an EEprom-Stelle 0 keine Daten hingeschrieben werden sollten. Ein bekannter Bug. Vor allem bei unzureichender Resetbeschaltung. Die neuen AVRs verhindern das mit dem Brown -Out Dedektor ;-). Mit den alten AVRs hat es sich bewährt, Spannungsausfälle bereits lange vor der 5 V Schwelle zu dedektieren (INT Eingang, vor dem V-Regler) und den AVR nach nochmaliger Datensicherung im EE in den Powerdown Zustand zu fahren. Josef
Hi @...HanneS... Der eine schreibt sich mit 'ß' und der andere mit 'ss' :-) Matthias (der mit 'ß')
Hi @HanneS, Matthias: Man schrieb mich bei der Geburt auch mal mit ß. In den Ausweisen aber mit ss. Und nach der Namensänderung wirklich mit ss. @Peter: anfangs verwendete ich einen TPS77450 von TI. Dann baute ich einen TPS77250 oder einen TPS77150 ein. Dummerweise habe ich die Geräte verliehen, so daß ich nicht mehr sicher sagen kann, ob nun der 150 oder 250 drin ist. Sind diese Bausteine aus Eurer Sicht nicht geeignet?
ich habe noch mal das Datenblatt der TI-Regler angesehen. Der TPS77150 löst unterhalb 95% der Ausgangsspannung RESET aus. Erst nach 220ms wird der RESET wieder HI. Der TPS77250 hat ein Power good Signal, das bei 82% der Ausgangsspannung wirkt. Oberhalb 82% wird PG Hi-Z. Eine Verzögerung gibt es dabei nicht. Eigentlich müssten doch beide Bausteine gehen. Oder? Kann es sein, daß die 220ms nötig sind, damit der Reset innen genug Zeit hat Register und Speicher wieder zu definieren? Gruss Matthias
ZITAT: Ich hatte das Problem mit einem 2313 (mit 1200 sowiso). Ich nahm an, dass jeweils die Zelle beschädigt wurde, auf die EEAR zeigte. Nachdem ich hinter jedem EEPROM-(Read)-Zugriff EEAR wieder auf eine unbenutzte Zelle setzte, trat das Problem nicht mehr auf. Das kann aber auch Zufall gewesen sein... ;-)) ...HanneS... Danke HanneS, Problem gelöst. War wohl doch kein Zufall. Hatte das Prob. auch auf einem 2313 und mir schon den Wolf gesucht in meinem Quelltext. Das mit Adresse 0 wusste ich schon, aber dass die Adresse auf die EEAR zeigt auch betroffen ist :(
Hallo Jürgen... Danke für deine Bestätigung, bisher war es nur Vermutung aber nun kann ich davon ausgehen, dass mein Verdacht stimmt. Bit- & Bytebruch... ...HanneS...
Dieser Tip für den At90S2313 war wirklich gold wert :)) Grüsse, Manfred
Diese Datenverluste haben mich damals tierisch aufgeregt und ich bin aus Frust zu einer anderen Controllerfamilie gewechselt :)
Hallo zusammen, könnte es möglich sein, dass der selbe Effekt auch beim Tiny13 auftritt? Ich habe bei einem Fahrtregler auch das Problem, dass sich das EEPROM manchmal "vergisst". Gruß, Christian
Hi, wie wäre denn die empfohlene Methode z.B. mit AVRs neuerer Generation (mega88) um das EEPROM fehlerfrei zu verwenden? Ich habe erst vor kurzem beim aktuellen Projekt erstmals auf das interne EEPROM zugegriffen und wollte es für ein paar Grundeinstellungen verwenden. Ciao...
Ja, das Problem kenne ich auch zur Genüge. Natürlich sollte man bei allen neuen AVRs den Brown-Out einschalten. Aber es hat sich gezeigt, daß auch dies nicht 100% gegen Datenverlust schützt. Deshalb habe ich zusätzlich die ersten beiden Speicherstellen des EEPROM nicht benutzt, da nur diese meist vom Datenverlust betroffen waren. Seidem habe ich weitgehend Ruhe. Den Tipp mit dem EEAR werde ich zusätzlich mal einbauen, das sollte eigentlich dann die 100% Lösung sein. Erwin
Moin, Ich hatte ebenfalls das Problem. EEAR nach jeder Nutzung auf die letzte existente EEPROM-Adresse zu setzen, hat meine Nutzdaten heile gelassen - aber ich habe beim Programmieren gesehen, dass er dafür eben am Ende des EEPROMs Mist gemacht hat. (ich lese vor dem Flashen das EEPROM aus und schreibe nach dem Chip Erase den alten Inhalt zurück) Jetzt, mit BOD aktiviert, hatte ich bisher keine weiteren Probleme. "Echter" Praxistest am 12V-KFZ-Bordnetz kommt aber erst noch... MfG, Heiko
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.