Atmel Flash-Lebensdauer

Hallo,

Ja.
Ja.
Nein.

Gruß aus Berlin
Michael

Danke euch für die Antworten.

>Schaffst Du es, deinen Controller jeden Tag 10 mal neu zu programmieren
>und das über 3 Jahre lang durchzuhalten?

Naja. :-)
Ich sehe das dann so:
Ich programmiere ihn 27x pro Tag, dann hab ich nach einem Jahr, kurz 
bevor er stirbt, genug Geld zusammengespart um mir einen neuen leisten 
zu können...

Die Frage kann interessant werden, wenn man Debugging mit 
Software-Breakpoints macht. Da gibt es nämlich wesentlich mehr 
Flash-Zugriffe.

Debugging mit softwarebreakpoints ist eine schlechte idee. Irgendwann 
sollte man erkannt haben, dass Debugging ein Konzept ist, das bei der 
Entwicklung eingebaut werden muss, sodass die laufenden Prozesse nicht 
gestoppt werden muessen.

Hi

Als ich mit AVRs angefangen habe wurden 1000 Programmierzyklen 
garantiert.
Den ATMega103 vom STK300 habe ich mindestens 2-3000 mal programmiert. 
Der läuft heute noch.

MfG Spess

In der Realität wird man mit normalem Gebrauch (keine Datenspeicherung 
jede Sekunde für ein ganzes Jahr) solche Flashspeicher nicht killen 
können! Atmel garantiert 10k Zyklen, d.h. in der Regel, ihre 
pessimistischsten interenen Abschätzungen lauteten auf mindestens das 
Doppelte! In der Realität bei Zimmertemperatur denke ich - und das ist 
eine rein gefühlsmässige Aussage - dürfte man locker Faktor 10 
erreichen, bis Bitfehler auftreten...

Gruss
rayelec

ASUS-Boards (Pentium-II 400MHz) hatten mal ATMEL-Flash als BIOS-Speicher 
drauf, die hielten ca. 500 Schreibvorgänge, dann tauchten erste 
Fehlermeldungen auf.
Mein Mega32 (16MHz) der seit 2 Jahren auf 'nem Steckbrett zum 'Quälen' 
steckt, hat ca. 2500 Programmiervorgänge hinter sich. Wenn der kaputt 
ist melde ich mich wieder, falls das Forum bis dahin noch besteht! ;-))

scheint wohl recht unterschiedlich zu sein. Daß ich das Modem Flash 
nicht jeden Tag neu beschreibe, ist doch wohl klar. Erst nachdem der 
Fehler auftrat und ich neu upgedatet hatte, trat der Fehler an anderer 
Stelle auf.
Bei meinem IDE Flash hatte ich zwar FAT 16, aber nur eine Datei 
geschrieben. Fehlermeldung war, kann von C: nicht lesen. War also die 
FAT oder Partition defekt. Da ist wohl deutlich zu sehen, daß beim 
Schreiben der FAT immer an die gleiche Stelle geschrieben wird.
Ich will jetzt als Alternative immer 2 Flashs gleichzeitig beschreiben 
für die Datensicherung. Dann gehen die Daten wenigstens nicht verloren, 
wenn 1 Flash defekt wird. Transsend gibt übrigens 30 Jahre Garantie auf 
die Flash Speicher. Weiß jemand die näheren Bedingungen der Garantie? 
Wenn ich den Stick erst auf meine Kosten einsenden muß, dann kann ich 
gleich einen neuen kaufen. Aber sonst bekomme ich dann immer einen 
Neuen, wenn einer defekt geht. Wäre ja auch nicht schlecht. Beim AVR 
geht das nicht ganz so einfach. Darum fange ich mit dem Testen erst an, 
wenn alles richtig programmiert erscheint und nochmal trocken 
durchgegangen wurde. Und dann beim Testen gleich mehrere Fehler auf 
einmal suchen. So könnte man die Anzahl der Schreibvorgänge vermindern.

mfg

Habe projektmäßig bei meiner Arbeit das untersucht. Nach ca dem neuzig 
bis 100 Fachen der garantierten Lebensdauer traten bei Atmel die ersten 
Bitfehler reproduzierbar bei Labortemperatur auf.

abwechselnd auch nicht. Wenn eine Datei gesichert werden muß, dann 
schreibe ich die erst auf einen Flash und dann auf einen 2. Flash. So 
sind immer 2 Kopien vorhanden. Wenn das Programm auf einen Lesefehler 
stößt, gibt es eine Fehlermeldung und es wird vom 2. Flash gelesen. Der 
defekte wird dann ausgetauscht und am nächsten Tag hab ich wieder 2 
Sicherungen.

mfg

Hallo,
die Angaben des Datenblattes beziehen sich nur darauf, dass für 10000 
Schreib-/Löschvorgängen die Spezifikation (Prog.-Timing) des µC 
eingehalten wird. D.h. nach 10000 Schreib-/Löschvorgängen ist der µC 
nicht kaputt, Atmel gibt halt keine Garantie für weitere Vorgänge. Also 
keine Sorge, nur durch die reine Anzahl der Programmierungen wird der µC 
nicht sterben. Um ihn Umzubringen gibt es wesentlich mehr und einfachere 
Möglichkeiten :-)

Wäre doch mal ein schönes Projekt für jemand der was machen will, aber 
nicht weis was:

Einen AVR nehmen und einen anderen Todflashen. Danach ausgabe der Anzahl 
der Schreibzyklen, Durchschnittstemperatur, Spannung etc.

;-)

>Wäre doch mal ein schönes Projekt für jemand der was machen will

Hat schon jemand gemacht. ATMEL nämlich. So kommen die zu den Angaben im 
Datenblatt.

Jo, zu den Angaben + Sicherheitsreserve

Mich würde interessieren wies in echt aussieht.

Aber auch nicht so stark das ichs umsetzt, habe sinnigere Projekte auf 
meiner Liste...

ich hab einen Slim DVD Brenner von Panasonic vor gut 2 Jahren gekauft. 
Kaum benutzt und schon kaputt.
Auf der Cebit 2009 habe ich einen 7" Fernseher gekauft. War nach kurzer 
Zeit defekt. Auf der IFA umgetauscht, lief dort auch schon nicht richtig 
und jetzt gibt es schon wieder Störungen.
Ich habe den Eindruck, daß auch beim Lagern schon Defekte auftreten und 
nicht erst beim Beschreiben.

Wenn man einen ATmege168 über debugWIRE debuggt dann wird bei jedem 
Programmstart auf den Anfang von main() eine break Instruktion geflasht. 
Da main() immer an der gleichen Stelle liegt, also immer in die gleiche 
Speicherzelle bzw. Page.

Wenn man 30 Programmänderungen pro Tag annimmt und für das Debuggen 
jeweisl 30 mal break gefasht wird dann sind 10-tausend Programmierungen 
nach 11 Tagen erreicht.

Wenn sich der AVR gar nicht meldet, dann liegt es aber nicht am defekten 
Flash.
Einfache Tests wie z.B. pro Sekunde hundert mal die gleiche 
Speicherzelle beschreiben, gleich wieder auslesen und vergleichen ist 
aber auch nicth umbedingt aussagekräftig. Die Isolierende Sicht des 
Floating Gates wird bei jedem Löschvorgang beschädigt, dadurch kann sich 
die Ladung des Gates unbeabsichtigt ändern. Wenn Atmel also 10k 
Schreibvorgänge angibt, dann bedeutet das, dass der Flash auch nach 
dieser Anzahl von Schreibvorgängen die Daten noch für XX Jahre sicher 
speichert. Nach 20k Schreibvorgänge ist das evtl schon nicht mehr 
gegeben. Da können Lesefehler vielleicht schon nach ein paar Tagen 
auftreten. Und genau diese Tatsache wird bei einem normalen 
Schreiben-Lesen-Vergleichen-Marathon nicht berücksichtigt. Nur weil die 
Daten 1ms nach dem Schreiben korrekt sind, kann das nach ein paar Tagen 
ganz anders aussehen.
Anwendungen wo jede Sekunde Datenüberschieben werden sollten vielleicht 
besser mit FRAM ausgerüstet werden. (Wenn es die Kapazität zulässt)