mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wie stirbt ein AVR nach häufigem Flashen?


Autor: Hans U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

habe hier ein Board mit atmega128, und sicherlich deutlich mehr als
1000 Code downloads.

Folgendes ist jetzt passiert: Code Download ganz normal. Danach
Funkstille, Stromaufnahme 0. Flashen nicht mehr möglich.

Ist das das übliche Abrauchen eines AVR's nach zu häufigem Flashen?

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist definitiv nicht normal, üblicherweise ist das ein schleichender
Prozess, bei dem das Flash-ROM einfach seine Zuverläsigkeit verliert
(aber erst nach vielen tausend Schreibvorgängen).

Autor: Hans U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na ja,

ich habe jetzt gerade den Prozessor getauscht, und alles läuft wieder
einwandfrei.

Vorher natürlich Spannungsversorgung etc. überprüft aber alles in
Ordnung.

Ich denke schon, das der Prozessor beim Flashen gestorben ist. Das
Board lief schliesslich schon über 1/2 Jahr ohne Probleme. Es lag
unberührt auf dem Tisch und ein Gewitter war gerade auch nicht :-)

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fuse Bits ?

Autor: Hans U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nee, fuse bits fallen aus.

Software lief, Kleinigkeit an SW geändert, neu runtergeladen - µC tot.
-> Darum denke ich tot-geflashed. Die Änderung an der SW hat ihn nicht
gehimmelt, denn die SW läuft ja jetzt und auch auf einem anderen
Board.

Ich schätze so ca. 5000-10000 downloads hatte der hinter sich...

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, nur himmelt sich so kein AVR, wenn sein FLASH Speicher dem Ende
zugeht.

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einen AVR kannst du häufiger Flashen als das du den Maustaste betätigen
kannst (so ein Taster hat eine Lebensdauer von nicht mal 1 Million
Betätigungen)...
Es haben schon einige Leute versucht AVRs totzuflashen. Nach x oder xx
Millionen Versuchen haben die es abgebrochen.

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

das ist so nicht richtig. Ich hab mal mit einem Mega8 einen Test
gefahren. Das EEPROM hat etwa 220k-Schreibzyklen ausgehalten bevor der
erste Bitfehler aufgetreten ist. Das Flash hat schon nach rund
53k-Zyklen den ersten Bitfehler aufgewiesen. Schädigungen der einzelnen
Zell treten natürlich schon weit vorher auf.

Matthias

Autor: rkhb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich dachte auch mal, dass ich oder das STK500 einen ATmega48 frühzeitig
totgeflasht haben. Mit dem STK500 war nichts mehr zu machen. Dann habe
ich per GALEP4 sämtliche Fusebits umgeflasht und wieder zurückgeflasht
- und nun geht er wieder wie früher. Ich denke, dass der Controller
irgendeine Einstellung falsch gemeldet hatte.

Im Datenblatt steht übrigens, wie oft der Controller geflasht werden
kann (ATmega128: "Endurance: 10,000 Write/Erase Cycles"). Irgendwo
bei Atmel habe ich gelesen, dass das die garantierten Werte sind und
die Controller in Wirklichkeit wesentlich häufiger geflasht werden
können.

viele grüße
ralph

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stromaufnahme 0 deutet darauf hin, daß Du versehentlich den externen
Clock aktiviert hast.

Totflashen bringt nur Ausführungs- oder Verify-Fehler, auf die SPI hat
es keinerei Einfluß, die muß immer gehen.


Peter

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar, vielleicht hast du mal einen Baustein erwischt, der schon an der
(garantierten) spezifizierten Untergrenze schlapp macht.

Flash Downloads kannst Du normalerweise in einer Entwicklungsphase
machen soviele wie du möchtest, viele garantieren heute auch 100000
Flash-Downloads anstatt 10000.

Hier mal eine zeitliche Betrachtung:

Machst du pro Tag konsequent 20 Downloads z.B. bei einem Demo-Board, so
kannst du es wenigstens 500 Tage verwenden. Da die Anwendung aber nicht
konsequent täglich erfolgt, kannst du das wenigstens 2 Jahre lang
machen.

Ich habe hier verschiedene Demo-Boards, ob PIC, Silabs für 8051, Keil
MCB2100, oder Prototypen mit Philips LPC2100-Controllern. Das gab noch
nie Probleme, obwohl ich es bei einigen Baugruppen absichtlich auf
extensiven Flash-Download angelegt habe.

Dietmar

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Zweifelsfall, wenn du die Flash Downloads mitgezählt hast, und diese
Zahl die angegebene Mindestanzahl im Datenblatt übertrifft, wird der
Baustein unzuverlässig.

Das ist dann per Definition so.

Dietmar

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HALLLOOOO??? Was erzählt ihr denn da?

>>Totflashen bringt nur Ausführungs- oder Verify-Fehler, auf die SPI
hat
es keinerei Einfluß, die muß immer gehen.

(Peter Dannegger)

So, und nicht anders. Der Flash kann nicht kaputt sein, da muss
mindestens noch was anderes kaputt sein!

Autor: SuperUser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Totflashen bringt nur Ausführungs- oder Verify-Fehler, auf die SPI
> hat es keinerei Einfluß, die muß immer gehen.

Na so einfach ist das nicht, dass hängt bestimmt von der
Flash-Architektur ab. Sicherlich wird das Flash-Memory Redundanz-Logik
haben. Was nun diese Logik macht, wenn sie am Ende der
Korrekturfähigkeit ist, weiss doch nur der Designer (und evtl. atmel
interne Specs)

Was, wenn der Baustein einfach im Reset bleibt, wenn nichtkorrigierbare
Fehler auftreten?

Aber offensichtlich hat sowas bisher noch niemand mit den AVR's
erlebt...

Zum 100'000 mal flashen: Das glaube ich nicht! Dafür ist der AVR in
einer viel zu alten Halbleiter Technologie. Die Flash-Die Grösse hängt
nämlich stark von der Zyklen-Zahl ab. In einer 5V Technologie sind das
erhebliche Chip-Flächen und damit Kostenfaktoren. Hier muss ATMEL
sparen was geht um konkurenzfähig zu sein. D.h. die Abstände und auch
die gespeicherte Ladung muss erheblich reduziert werden. Nach meiner
Einschätzung ist der Zellen-Leakage solcher Program-Flash spätestens
nach 10'000 Zyklen katastrophal schlecht.

Lösungsidee: (kenne den AVR zu schlecht um zu beurteilen ob das geht)
Wenn man mit einem Bootloader arbeitet, sollte es da nicht möglich
sein, das Programm immer wieder an andere Stellen im Speicher zu
schreiben und damit das Flash gleichmässig "abzunutzen"? Stellt sich
nur die Frage, wie man die richtige Stelle dann findet... Vielleicht
über eine EEPROM Zelle....

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Lösungsidee: (kenne den AVR zu schlecht um zu beurteilen ob das geht)
Wenn man mit einem Bootloader arbeitet, sollte es da nicht möglich
sein, das Programm immer wieder an andere Stellen im Speicher zu
schreiben und damit das Flash gleichmässig "abzunutzen"? Stellt sich
nur die Frage, wie man die richtige Stelle dann findet... Vielleicht
über eine EEPROM Zelle...."

Man kann auch direkt beim Proggen die Position des Codes festlegen.
Aber die Interruptvektoren zeigen halt nunmal immer auf die selbe
Adresse. Also kann man irgendwann keine Interrupts mehr verwenden.
Auch das Byte wo der MC anfängt ist ja immer das gleiche. Da währe
sinniger weise ein Sprungbefehl zum aktuellen Programmbeginn. Die Zelle
würde auch relativ bald ihren Geist aufgeben.

Aber so wie ich das beurteiele geht es ja garnicht darum den Chip 3
statt 2 Jahren zu verwenden. Was sind schon die paar euro. In der
Zwischenzeit wird ja fast mehr abgeraucht.
Ich glaub hier gehts nur darum was denn passiert, wenn das Flash nicht
mehr mitspielt bzw. was bei Hans sonst kaputt ist.

Sebastian

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@SuperUser:

Na gut dass du dich noch nicht mit denen beschäftigt hast, weil dann
kannst du ja so sichere Aussagen machen...

Facts: Ein Atmega8 (Datenblatt Stand 4.10.2005) lässt sich mindestens
(Hersteller garantiert) 10.000 mal im Flash benudeln (Aus mündlichen
Quellen habe ich schon mehr gehört. Diese Leute, die immer den Flash
mehrere tausend male Beörgeln, nur um zu testen, wie lange er hält)

Soweit ich weiß hat der AVR keine Kontrollfunktionen, ob irgndwo was im
Flash kaputt ist. Mit dem Programmiertool führt man idR ein
erase-write-verify durch um den Speicher zu überprüfen. Wenn der AVR
selbst scon den Speicher gefunden hätte, und sein SPI abschalten würde
ö.ä., dann bräuchte man garkein Verify anwenden, denn dann wär der
Controller garnichtmehr lesefähig.

Ich bin der Meinung, dass der Controller selbst nicht merkt, ob
Bits/Bytes/Pages im Flash kaputt sind, oder nicht. Das merkt erst das
Programmiertool und dann der Benutzer. Der AVR wird auch nicht im
Dauerreset bleiben.

Achja PS: Wenn der Baustein im Reset bleiben würde, müsste das
Programmieren ja noch gehen.

PPS: Deine Letzte Idee klappt schon aus obengenannten Gründen nicht.
Das ist aber bei den meisten Mikrocontrollern so, mit den
Interruptvektoren. Weiß garnicht wie du auf sowas kommst.

Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@SuperUser:

Immer kleinere Strukturen immer unzuverlässiger?

Ich glaube, das Gegenteil ist der Fall! Immer kleiner werdende
PN-Übergänge (in Transistoren) müßten demnach auch immer schneller
ausdiffundieren, und das mit Beschleunigungsfaktor bei höherer
Temperatur und mittlerweile unglaublich hoher Transistorendichte und
-anzahl auf einem µC-Chip.

Möglich ist auch ein Frühausfall, im Frühstadium ist die Ausfallrate
noch hoch, später wird der Baustein stabil. Aus diesem Grunde werden
Bausteine, die hoch zuverlässig sein sollen, vor der ersten
Inbetriebnahme Tage oder Wochen bei hohen Temperaturen "eingebrannt"
(Burn-In). Dann ist sozusagen die Frühausfallphase schon vorbei.

Zu dem Baustein gibt es sicher auch Herstellerdaten wie MTBF (Mean Time
between Failures) oder FIT (Failures In Time, Anzahl defekter Bausteine
in 10E9 Stunden).

@Hans U.:

So kann das doch auch sein, oder?

Gruß

Dietmar

Autor: Felix Ackermann (felack)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie stirbt ein Flash?

Die Lebensdauer des Flashspeichers wird durch folgende Kriterien
festgelegt:
Bei jedem Flashen einer Zelle erhöht sich der Leckstrom der
Speicherzelle. Die maximale Anzahl der möglichen Flashvorgänge wird nun
dadurch begrenzt, dass der Speicherinhalt trotz diesem erhöhten
Leckstrom  noch 20 Jahre ohne Stromversorgung erhalten bleiben muss.
Das heißt, dass die Speicherzellen sicher nicht nach 10000 Flashs
kaputtgehen, sondern dass die Daten dann nicht mehr 20 Jahre ohne Strom
erhalten bleiben. Es geht also nicht die Zelle kaputt, sondern der
Leckstrom wird zu hoch. Deshalb kann man den Flash auch 100000 mal
beschreiben, wenn er keine 20 Jahre ohne Stromzufuhr überstehen muss.

felack

Autor: Caruso (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wird diese Zeit eigentlich verlängert, wenn man ihn nach ein paar Jahren
mit Strom versorgt?

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

nein, da im normalen Betrieb keine Ladung auf das Floating Point
tunnelt. Was allerdings hilft ist neu programmieren.

Und wie ich oben schonmal geschrieben habe trat bei einem Mega8 der
erste Bitfehler nach 53k-Zyklen (löschen des gesamten Flash und
anschließendes befüllen mit 0x00) auf. Danach ist etwa jeder 100ste
Schreibvorgang an diesem einen Bit gescheitert. Weiter hab ich das
nicht mehr untersucht.

Matthias

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, 53000?
Ok, macht bei 30 mal neu programmieren täglich immerhin 4,83686 Jahre.

5 Controller habe ich zum Experimentieren, macht 24,2 Jahre.
Ich glaube, das reicht für's erste.
Ich denke, die meisten Controller sterben aus anderen Gründen oder
werden schlicht zerfust(falscher Clock und andere Spässe).
Zumindest hier im Forum habe ich den Eindruck, wenn was daneben geht,
dann ist es häufig die Takt/Quarzeinstellung.

Gruss
Jadeclaw.

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.