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
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
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.
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
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
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.
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.
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
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.
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
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
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.
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.
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.