Hallo liebe Gemeinde, ich hab hier einen kleinen Aufbau mit einer Funkbrücke mit RFM12, Benedikt sei Dank. Es wird zweimal ein ATmega8 verwendet. Beitrag "Re: bidirektionale RS232 Funkbrücke mit RFM12" Lief auch auf Anhieb gut, wenn man von dem Taktumschaltungsproblem mal absieht (was auch unerklärlich ist, denn der AVR ist voll statisch aufgebaut, f_min = 0 Hz). So, nun lag das alles eingebaut ca. 1/2 Jahr in der Kiste, vor einigen Tagen mal wieder spaßenshalber eingeschaltet, nix ging! ;-( Jeweils Sender und Empfänger blinkten, es wurden also Daten übertragen. In den Sender klimperten auch die richtigen Daten rein, 7 Byte in einem Paket, aus dem Empfänger kamen aber immer 11 oder 12 Nullbytes :-( Lange Rede, kurzer Sinn. Ein Verify des Flash vom Sender brachte Fehler, nach einem neuen Flashen lief das Ganze wieder! Ok, der Broun Out war NICHT aktiv, aber wieso killt es dabei den FLASH? Dass der EEPROM da ggf. Probleme hat ist bekannt, wird hier aber nicht genutzt. War der inaktive Brown Out die Ursache? Andere Möglichkeiten? Any Ideas? MFG Falk P S Die Suche im Forum brachte einige alte Threads zum Thema hervor, aber keine klare Information.
Vielleicht hättest Du die Kiste nicht zwischen Lautsprecher und Röntgengerät lagern sollen ;-)
Falk Brunner schrieb: > Any Ideas? Keine konkrete, ich will aber anmerken, dass nicht unbedingt der Betrieb das Problem gewesen sein muss, sondern auch während dem ursprünglichen Flashen etwas schiefgelaufen sein kann. Ziemlich aus der Luft gegriffen, aber zum Beispiel kurzer Versorgungsspannungseinbruch beim Flashen, dadurch gerade noch genug Ladung aufs Floating Gate für den anschließenden Verify, aber nicht genug für ein halbes Jahr. Erhöhte Betriebstemperatur? Funk könnte ja darauf schließen lassen, dass evtl. der Controller außer Haus gewesen sein könnte.
@ Maik Fox (sabuty) Benutzerseite >aber zum Beispiel kurzer Versorgungsspannungseinbruch beim Flashen, Kann man praktisch ausschliessen, Die Versorgung kommt aus einer 12V Batterie + 7805. >Erhöhte Betriebstemperatur? Nö. > Funk könnte ja darauf schließen lassen, dass >evtl. der Controller außer Haus gewesen sein könnte. Auch nicht wirklich, war alles Indoor Anwendung. Trotzdem Danke für das Feedback. MFG Falk
Ist da ein bootloader drauf, eventuell macht der bei schlechter / zu kleiner Spannung Probleme beim Einschalten....
@ bootloader (Gast)
>Ist da ein bootloader drauf,
Nein, so ein Teufelszeug nutze ich nicht ;-)
Das Flash wurde nur zum Programmieren beschrieben, nicht zwischendurch fuer Daten auch noch ? Spezifischer, die Befehle SPM und so werden vom Code nicht benutzt ?
@ Mini Nilp (hacky) >Das Flash wurde nur zum Programmieren beschrieben, Ja. >fuer Daten auch noch ? Spezifischer, die Befehle SPM und so werden vom >Code nicht benutzt ? Ja. MFG Falk
Hmmm, hab noch mal nachgesehen. Das Programm verwendet an einigen Stellen den Befehl LPM, um Daten aus dem Flash zu lesen. Der Op-Code von LPM unterscheidet sich nur in EINEM Bit von SPM! LPM 1001 0101 1100 1000 SPM 1001 0101 1110 1000 Wenn nun ohne Brown Out Detector gearbeitet wird und die Versorgungsspannung ausgeschaltet wird, könnte durchaus ein LPM als SPM ausgeführt werden. Auf den EEPROM wird auch zugegiffen, lesend wie schreibend. Aber das sollte bestenfalls zu EEPROM Fehlern führen, nicht Flash-Fehlern. MFG Falk
Falk Brunner schrieb: > Wenn nun ohne Brown Out Detector gearbeitet wird und die > > Versorgungsspannung ausgeschaltet wird, könnte durchaus ein LPM als SPM > > ausgeführt werden. Unwahrscheinlich. Da vorher SPMCSR gesetzt und innerhalb 4 Taktzyklen SPM ausgeführt werden muß. mfg.
Falk Brunner schrieb: > Keine weiteren Ideen? Naja, das ist eben eine Sache, die nicht auftauchen sollte, jedenfalls nicht nach 1/2 Jahr. Wenn so etwas häufiger auftreten würde, wäre es ein Desaster. Hast du zufällig irgendwelche alpha-Strahler in der Nähe? ;)
Es könnte schon mit der externen Taktumschaltung zu tun haben. Wenn diese einen Glitch erzeugt, kann das die CPU durcheinander bringen. Wenn man sich mal die Beschreibung des internen System Clock Prescaler des AVR (ATmega88) ansieht, wird extra drauf hingewiesen, daß die Umschaltung glitchfrei erfolgt. Auch wird beim Setzen des Oscillator Calibration Register empfohlen, es nur in kleinen Schritten zu ändern. Ich hab schonmal ne Trickschaltung gesehen, wo jemand für langsame Peripherie den Waitausgang mit dem CPU-Takt verUNDet hat, es lief nicht stabil. Erst mit nem 74HC112 als Teiler ging es. Das Wait wurde mit J und K verbunden, quasi als Count-Enable. Den CPU-Takt extern umzuschalten, dürfte also keine gute Idee sein. Eine Lösung wäre, Du nimmst nen ATmega88, setzt dort den System Clock Prescaler, z.B. auf 64, schaltest dann den externen Takt um und setzt danach den System Clock Prescaler wieder auf 1. Oder Du gibst Dir nen Ruck und spendierst die paar Cent für nen eigenen Quarz. Peter
@ Peter Dannegger (peda) >Es könnte schon mit der externen Taktumschaltung zu tun haben. Wenn >diese einen Glitch erzeugt, kann das die CPU durcheinander bringen. Ja, aber dann dürften keine Flash-Fehler entstehen, "bestenfalls" das Programm abstürzen. Ausserdem ist die Taktumschaltung nach allen Messungen glitchfrei. Alles merkwürdig. >Den CPU-Takt extern umzuschalten, dürfte also keine gute Idee sein. Warum? Der AVR ist "full static", das sollte da keinerlei Rolle spielen, solange die minimalen Pulsbreiten eingehalten werden. Erst mit den neueren AVRs ist dieser komische Nebensatz mit der "langsamen Taktänderung ins Datenblatt gekommen. Ist aber nicht nachvollziehbar, schließlich hat der AVR keine PLL oder so. (einige Exemplare ausgenommen). >Oder Du gibst Dir nen Ruck und spendierst die paar Cent für nen eigenen >Quarz. Das Problem als solches ist mit der stufenweisen Umschaltung 1,2,5,10 MHz damals gelöst worden. Das aktuelle Problem sind die Flash-Fehler. MFG Falk
Ich schalte grundsätzlich immer das BOD ein und hatte bisher keine Probleme. Kannst ja mal nen AVR an paar LEDs pappen und damit die Resetquelle anzeigen. Und dann mal mit dem Labornetzteil rumspielen. Das POR kommt nur, wenn es mal gute Laune hat. Nur das BOD funktioniert zuverlässig. Die alten AVRs ohne BOD habe ich schnell in die Mülltonne geschmissen, die hatten immer nur Ärger gemacht. Mein erster AVR, der es bis in den praktischen Einsatz geschafft hat, war der ATtiny26 (damals noch in Assembler). Der SPM-Befehl soll ja eigentlich nur im Bootsektor funktionieren. Ist Dein Programm so groß, daß es bis in den Bootsektor reicht? Die üblichen Verdächtigen wären dann noch: Ist der Resetpin mit 100nF gegen Störungen abgeblockt oder per Fuse disabled? Kann ein IO-Pin Spannung führen vor VCC? Peter
@ Peter Dannegger (peda) >Ich schalte grundsätzlich immer das BOD ein und hatte bisher keine >Probleme. Hab ich jetzt auch gemacht. >Dein Programm so groß, daß es bis in den Bootsektor reicht? Ja. >Ist der Resetpin mit 100nF gegen Störungen abgeblockt Ja. >oder per Fuse disabled? Nein. >Kann ein IO-Pin Spannung führen vor VCC? Nein. MFG Falk
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.