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?
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).
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 :-)
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...
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.
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
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
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
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
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
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!
>>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....
"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
@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.
@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
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
Wird diese Zeit eigentlich verlängert, wenn man ihn nach ein paar Jahren mit Strom versorgt?
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
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.
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.