www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR mit Datenverlust im Flash


Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: derdas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht hättest Du die Kiste nicht zwischen Lautsprecher und 
Röntgengerät lagern sollen ;-)

Autor: Maik Fox (sabuty) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: bootloader (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist da ein bootloader drauf, eventuell macht der bei schlechter / zu 
kleiner Spannung Probleme beim Einschalten....

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  bootloader (Gast)

>Ist da ein bootloader drauf,

Nein, so ein Teufelszeug nutze ich nicht ;-)

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Flash wurde nur zum Programmieren beschrieben, nicht zwischendurch 
fuer Daten auch noch ? Spezifischer, die Befehle SPM und so werden vom 
Code nicht benutzt ?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Keine weiteren Ideen?

Autor: Maik Fox (sabuty) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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? ;)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.