www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Flashverlust bei AVR wenn VCC zu niedrig wird


Autor: Björn Wieck (bwieck)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute

Auf einer Diskussion in de.sci.electronics habe ich gerade verfolgt
wie jemand mit diesem Satz kam:

Der AVR hat wenigstens einen BOR, den man aber explizit anschalten muss. 
Der ist auch dringend notwendig. Ohne versaut er sich nämlich beim 
"langsamen" Abschalten zuverlässig sein Flash und sogar die Fuses(!).

(BOR = Brown Out Reset)


Was ist davon zu halten ?
Habt Ihr schomal erlebt dass beim langsamen runterfahren von VCC der 
Flash zerschossen war ?
Ich noch nicht.
Wäre doch mal interessant weil ich ja doch teilweise AVR´s in 
Batteriebetrieb habe und die Batterie auch mal leer wird..



Ich habe den Autor mal gefragt wie er das mit "langsam" meint...

Falls Ich noch eine Antwort bekomme, hänge ich sie noch dran.

Grüße
Björn

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Björn Wieck (bwieck)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. wrote:
> Beitrag "Atmega8515 verlor plötzlich sein Programm?"

Den Fred kannt ich schon..

Scheint wohl mehrere Leute zu betreffen

Hier die Antwort aus de.sci.electronics:

|> kannst Du mir das mit dem "langsamen" Abschalten mal genauer erklären ?

Netzteil, dicke Elkos, sonst keine Verbraucher (mehr), Mega8515. Der 
Fall, wo man
fast noch das Dunklerwerden der Power-Led mitbekommt... Der "normale" 
Code
schreibt auch nicht ins Flash/EEPROM, und es gibt auch sonst nichts 
kritisches.
Daher habe ich da auch nicht an sowas gedacht. Ich habe es bei der 
Entwicklung
hunderte Male abgeschaltet, bei mir ist nie was passiert. In der 
Vorserie auch
nicht. Aber dann in der Serie natürlich...

Besonders übel war eben auch, dass mit dem vorhandenen Bootloader das 
oft
(temporär) gefixt werden konnte, aber nicht immer, es gab Verify-Errors. 
Nachdem
ich dann mal so ein paar Platinen wieder in das Hand hatte, konnte ich 
die Fuses
per ISP auslesen und sie waren verändert. Fast immer hat es die 
LOCK-Fuses
getroffen, sodass der der Bootloader auch nicht mehr das Flash lesen 
bzw.
schreiben durfte. Das mit dem notwendigen BOR war dann auch so eine 
Erfahrung,
die man vorher gebraucht hätte...



Grüße
Björn

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Kommt jetzt eine neue Hexenjagd ? Bis jetzt konnte niemand seinen 
plötzlichen
'Haarausfall bei ATMegaXXX oder AT90SXXX.....' reproduzierbar 
nachvollziehen. In den ganzen Diskussionen hat mich auch noch keiner 
überzeugt, daß er oder seine Zulieferer keine Fehler gemacht haben. Aus 
meiner Erfahrung haben sich AVRs als sehr rubust und zuverlässig 
erwiesen.

P.S. Vielleicht versuchen da einige ihre eigenen Fehler auf ATMEL 
abzuwälzen.

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Vergessen:

MfG Spess

Autor: Björn Wieck (bwieck)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Spess53 wrote:
> Hi
>
> Kommt jetzt eine neue Hexenjagd ? Bis jetzt konnte niemand seinen
> plötzlichen
> 'Haarausfall bei ATMegaXXX oder AT90SXXX.....' reproduzierbar
> nachvollziehen. In den ganzen Diskussionen hat mich auch noch keiner
> überzeugt, daß er oder seine Zulieferer keine Fehler gemacht haben. Aus
> meiner Erfahrung haben sich AVRs als sehr rubust und zuverlässig
> erwiesen.
>
> P.S. Vielleicht versuchen da einige ihre eigenen Fehler auf ATMEL
> abzuwälzen.

Jetzt habe ich da mal eben eine erklärende Antwort dazu bekommen.
Auszug aus der Antwort:

------------------------------------------------------------------------ 
--
|> Ist das irgendwo dokumentiert, bei ATmel habe ich dazu nicht viel
|> relevantes gefunden.

Ich habe Atmel geschrieben, gerade weil mich das mit der Zerstörung der
Lock-Fuses so irritiert hat. Auszüge:

"If the part gets outside spec it can begin executing erratically, and 
the
program couter could concievably jump to any code that is in flash, and
hence start programming the lockbits."

"If lockbit1 (LB1) is programmed, the fuses can not be changed.
The lockbits can be programmed from software, but to erase them the only 
way is to erase the device. The fuse bits can only be programmed over 
ISP or high voltage programming, not by the software. That means that 
brownout
detection has to be enabled during programming."

Heisst also: Brownout macht Zufallsbefehle, die können wiederum zufällig 
die Flash beschreiben UND Lock-Fuses setzen und das ist dann nicht 
mehr reversibel.

|> Deine Formulierung "zuverlässig" lässt schliessen, dass es sich um eine
|> Art verlässliches Problem, zuverlässig wiederholbar handelt. Ist das in
|> der Tat so, oder ist das Problem irgendwo in der Walachei unter unbekannten
|> Umständen irgendwann mal aufgetreten?

Bei ~500 Stück über ein paar Monate hinweg ca. 20mal. Ich habe es dann 
auch
selber reproduzieren können. Einfach mit dem Bananenstecker in der 
Netzteilbuchsewackeln. Dauert gar nicht lang.

|> Was genau ist unter "langsamen Abschalten" zu verstehen?

Siehe anderes Posting, halt einfach zuviel Elkos...

------------------------------------------------------------------------ 
--


Und BOR nicht gesetzt

Grüße
Björn

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
@Björn: Zuverlässig heisst bei mir, daß wir die Teile seit zig Jahren 
einsetzen und bis jetzt kein Fehler, der Zweifel an die Zuverlässigkeit 
von AVRs aufkommem lässt, aufgekommen ist.

MfG Spess

Autor: peter-neu-ulm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe in den letzten Wochen das Problem gehabt, dass das Daten-EEPROM 
beim Ausschalten ständig Werte verloren hat. Erst nach dem Einschalten 
des BOD war der Spuk vorbei. Anscheinend läuft beim langsamen Absinken 
der Spannung einiges Chaos ab, bei dem aich das EEPROM betroffen werden 
kann.

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eins ist ja mal logisch: Bei jedem Prozessor, wenn man ihn im 
Grenzbereich "läuft noch gerade so mit dieser Spannung" und "läuft nicht 
mehr" betreibt, führt die CPU recht willkürlich irgendwelche Befehle 
aus. Manche Speicherzelle wird noch korrekt gelesen, die nächste wieder 
nicht. Man kann also davon ausgehen, dass beliebige Befehle abgearbeitet 
werden.

Bei CPU's, die sich selbst flashen können oder Lockbits programmmäßig 
verändern können, kann das dann auch auftreten. Insofern kommt man da 
nicht um eine Brownout Überwachung herum.

Batteriebetrieb ohne Brownout halte ich sowieso für ziemlich zweifelhaft 
und auch bei Netzteilbetrieb kann man oft solche gefährlichen 
Zwischenzustände nie ganz vermeiden. Man muss ja auch mal die Schäden 
sehen, die entstehen können, wenn Ports irgendwo hin und her wackeln, 
also verrückt spielen.

Autor: Björn Wieck (bwieck)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Spess53 wrote:
> Hi
> @Björn: Zuverlässig heisst bei mir, daß wir die Teile seit zig Jahren
> einsetzen und bis jetzt kein Fehler, der Zweifel an die Zuverlässigkeit
> von AVRs aufkommem lässt, aufgekommen ist.
>
> MfG Spess

Jo, ich hatte auch noch nie Probleme, allerdings setze ich die BOD Fuse 
immer.

Die Probleme scheinen aufzutreten wen diese Fuse nicht gesetzt ist.

Grüße
Björn

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die Beschaltung des Resetpins könnte auch einen großen Einfluss haben, 
wenn der Resetwiderstand ziemlich groß ist und die VCC abfällt sollte 
der AVR doch erstmal fest auf Reset gehen und nichts mehr Unternehmen so 
würde die niedrige VCC auch nichts bewirken können. Wäre mal nen Versuch 
Wert. In einem anderem Beitrag wurde ja auch der Verdacht gebracht das 
die Löttemperatur beim Bestücker zu hoch war. Mit einem normalen 
Backofen kann man ja mit den Temperaturen nicht so hoch aber wenn jemand 
einen richtigen Ofen hat könnte er doch mal nen programmierten AVR 
außerhalb der Spezifikationen(im Backofen lassen) und danach auf 
Funktion prüfen.

Naja wenn das Projekt fertig ist und der AVR gesockelt könnte man ja 
auch die Fuses dahinsetzen das er sich nicht mehr Programmieren und 
dadurch selber löschen kann, was ja laut Atmel eine Abhilfe sein soll.

Aber genau das was hier beschrieben wird taucht ja auch haufenweise bei 
der ISP Programmierung mit Selbsbauadaptern auf und hier nutzt auch 
jeder eine abweichende Resetbeschaltung als sie Atmel empfiehlt und da 
zerhaut es auch sehr oft die Fuses obwohl man überhaupt nicht an den 
Fuses rumprogrammiert hat.

Ich glaube sehr stark das es mit der Resetbeschaltung zusammenhängt und 
das hohe Löttemperaturen dem Flashspeicher zusetzen(Isolationsschicht), 
da ja auch davon berichtet wurde das ein AVR nach dem Neuprogrammieren 
nach 12Std wieder leer war.

Autor: Björn Wieck (bwieck)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Winfried wrote:
> Eins ist ja mal logisch: Bei jedem Prozessor, wenn man ihn im
> Grenzbereich "läuft noch gerade so mit dieser Spannung" und "läuft nicht
> mehr" betreibt, führt die CPU recht willkürlich irgendwelche Befehle
> aus. Manche Speicherzelle wird noch korrekt gelesen, die nächste wieder
> nicht. Man kann also davon ausgehen, dass beliebige Befehle abgearbeitet
> werden.
>
> Bei CPU's, die sich selbst flashen können oder Lockbits programmmäßig
> verändern können, kann das dann auch auftreten. Insofern kommt man da
> nicht um eine Brownout Überwachung herum.
>
> Batteriebetrieb ohne Brownout halte ich sowieso für ziemlich zweifelhaft
> und auch bei Netzteilbetrieb kann man oft solche gefährlichen
> Zwischenzustände nie ganz vermeiden. Man muss ja auch mal die Schäden
> sehen, die entstehen können, wenn Ports irgendwo hin und her wackeln,
> also verrückt spielen.

Und dann noch die Sache mit den Ports selber, wie jemand in 
de.sci.electronics gerade noch orakelte, wenn z. B. ein Port als Eingang
Programmiert ist und durch der AVR das durch Demenz vergisst und dann
ein Eingang direkt auf VCC oder Masse liegt > Puff

Aber wer macht denn sowas ? Als wenn es keine Pull Up/Down Widerstände 
geben
würde.

Grüße
Björn

Autor: Björn Wieck (bwieck)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas O. wrote:
> die Beschaltung des Resetpins könnte auch einen großen Einfluss haben,
> wenn der Resetwiderstand ziemlich groß ist und die VCC abfällt sollte
> der AVR doch erstmal fest auf Reset gehen und nichts mehr Unternehmen so

Derwegen wurde ja auch die BrownOutDetection eingebaut.
Muss nur eingeschaltet werden.


> würde die niedrige VCC auch nichts bewirken können. Wäre mal nen Versuch
> Wert. In einem anderem Beitrag wurde ja auch der Verdacht gebracht das
> die Löttemperatur beim Bestücker zu hoch war. Mit einem normalen
> Backofen kann man ja mit den Temperaturen nicht so hoch aber wenn jemand
> einen richtigen Ofen hat könnte er doch mal nen programmierten AVR
> außerhalb der Spezifikationen(im Backofen lassen) und danach auf
> Funktion prüfen.


Wenn der Chip erst mal gegrillt wurde kann der alles mögliche machen..
Hatte ich mal mit einem FET der erst bei einer höheren Frequenz
anfing zu spinnen, offenbar wurde durch Hitze die Gatekapazität 
verändert.
Obwohl der dafür gemacht wurde. Nach Tausch war gut.

Fazit: Immer BOD Fuse setzen.
Gegen Hitzetod gib es leider keine Fuse ;)


Grüße
Björn

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ganze ist nichts neues: Dass der AVR wild umherspringt, wenn Vcc 
niedrig wird ist schon lange bekannt. Das fehlende Glied in dem Rätsel 
wiso der Flash verloren geht, war der Hinweis, dass ein Bootloader 
vorhanden ist, (also irgendwo im Flash der Befehl SPM steht). Ich wette 
das passiert nicht nur beim AVR, sondern auch bei anderen Controllern 
mit Bootloadern.
Das mit den Ports wird dasgleiche sein: Irgendwo im Programmcode steht 
halt, dass die Ports auf Ausgang geschaltet werden sollen.

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Wir hatten das gleiche Problem mit dem T89C51RD2 dieser hatte zu seiner
Zeit keinen eingebauten BOR. Nach und nach kamen alle Platinen wieder 
zurück, da sie das Programm verloren hatten oder es teilweise 
verstümmelt war.
Atmel hat auf Anfrage den Fehler eingestanden und auf ein Error 
Datasheet hingewiesen. Dieses würde aber erst veröffentlicht als wir den 
Prozessor schon 1 Jahr verwendet hatten.
Wir mussten alle Platinen mit einem externen BOR nachrüsten.
Der Nachfolger AT89C51RD2 hat dann einen eingebauten BOR von Atmel 
bekommen.

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.