Moin! Ich hab mal eine Frage ob jemand Erfahrungswerte dazu hat. Merkt man den bevorstehenden Ausfall irgendwie, etwa wenn das Programm den Flash als "großen EEPROM" benutzt? Oder wie oft kann man einen AVR neu flashen, also Änderungen am Programm vornehmen? Ich glaube zwar nicht, daß ich die 20.000mal, die im Datenblatt stehen, jemals erreiche... aber man weiß ja nie. Wenn man doch mal sehr viel an einem Programm testet und ihn dauernd neu beschreibt, wie sehr leidet der µC darunter und wie machen sich Ausfälle evtl. frühzeitig bemerkbar? Kann man einen µC mit 20.000 oder mehr Flash-Zyklen noch zuverlässig einsetzen oder besteht dann ein erhöhtes Ausfallrisiko durch Bitfehler im Programm?
Moin, 20.000 mal schreiben geht garantiert. Wenn du über die 20k Zyklen kommst, bist du außerhalb der Spec.. Da heisst es dann: kann funktionieren, muss aber nicht. Die Frage, wie viele male bei deinem Chip wirklich gehen, wird dir hier keiner beantworten können. Da hilft leider nur ausmessen (Brennen, Rücklesen Vergleichen), allerdings ist der Chip dann hinüber. Und du hast dann keine belastbare Aussage, wie oft das beim nächsten Chip funktinonieren wird. Vor allem dann nicht, wenn der aus einer anderen Prod.Charge stammt. Kurzum: bleib unter den 20k Zyklen, oder nimm' ein externes eeprom.
Ben B. schrieb: > Wenn man > doch mal sehr viel an einem Programm testet und ihn dauernd neu > beschreibt, wie sehr leidet der µC darunter und wie machen sich Ausfälle > evtl. frühzeitig bemerkbar? Wenn man beim AVRDUDE das Verify einschaltet, dann würde man irgendwann einen Fehler bekommen weil Programm != Flash. Fieserweise könnten die Flash Zellen auch "weich" werden, und so nach einiger Zeit den Inhalt verlieren. Aber Du kannst Dir mal ausrechnen wie lange das dauern würde, ehe Du beim normalen Entwickeln auf 20k Programmierzyklen kommst. Meistens geht vorher was anderes kaputt, z.B. der Programmierstecker... ;-)
Eventuell ist bei den üblicherweise angegbenen 10k-20k Zyklen ein gehöriger Sicherheitsaufschlag drauf (für 85°C Temperatur z.B). Im LPC1768 Datenblatt steht beispielsweise min 10k, typisch 100k Zyklen (bei 25°C) drin.
Hallo, Jim M. schrieb: > Aber Du kannst Dir mal ausrechnen wie lange das dauern würde, ehe Du > beim normalen Entwickeln auf 20k Programmierzyklen kommst. Meistens geht > vorher was anderes kaputt, z.B. der Programmierstecker... ;-) das sind doch bei täglich 10x neu flashen noch nicht mal ganz 5 1/2 Jahre... ;-) Gruß aus Berlin Michael
:
Bearbeitet durch User
Ben B. schrieb: > Kann man einen µC mit 20.000 oder mehr Flash-Zyklen noch zuverlässig > einsetzen oder besteht dann ein erhöhtes Ausfallrisiko durch Bitfehler > im Programm? Auf einem Infineon-Seminar wurde diese Problematik mal behandelt. Danach kann man den Flash-Speicher weit über die garantierten Zyklen hinaus programmieren aber die nötige Dauer zur Programmierung einer Zelle steigt mehr und mehr an und der Langzeitspeichererhalt sinkt. Das ist also ein schleichender Prozess. Lutz
Na wenn man das Programm für ein Teil entwirft und dieses oft auf dem Controller testet bzw. es für debug-Zwecke mit leichten Modifikationen immer neu schreibt, braucht man den Programmieradapter gar nicht erst abklemmen... Bei manchen Fehlern kommen da schnell einige Schreibzyklen zusammen. Ein Fehler beim Verify ist klar, das war's dann für den Controller... daß Zellen irgendwann "weich" werden ist meine Befürchtung und deswegen diese Fragen hier. Ob man so einen "ausgiebig getesteten" Controller hinterher (wenn das Programm fertig ist) durch einen frischen ersetzen sollte oder ob das egal ist.
Hallo Ben Vor vielen vielen Monden habe ich das mal ausprobiert: Ab Beitrag "Re: [ATMega] Programm aus externem EEprom laden" MfG
Ich verschleißtestete mal vor Jahren den internen EEPROM in einem PIC 18F452. Der soll dem Datenblatt nach 1e6 Schreib Zyklen aushalten. Der FLASH soll 1e5. Das Test Programm brachte es auf 14e6 Schreibzyklen im EEPROM bevor Fehler auftraten. Die Fehler betrafen auch links und rechts einige benachbarte unbeschriebene Speicherzellen. Langfristig würde ich mich bei Millionen von Schreibvorgängen dann auch nicht mehr darauf verlassen wollen auch wenn sie anfangs noch richtig funktionieren. FRAM ist da mit 1e15 Schreibvorgängen deutlich überlegener.
Ben B. schrieb: > Ob man so einen "ausgiebig getesteten" Controller > hinterher (wenn das Programm fertig ist) durch einen frischen ersetzen > sollte oder ob das egal ist. Ich sage ja... Auch wenn ich bei noch keinem AVR das Flash tot programmiert habe, kommen mir keine gebrauchten Test-AVR in die endgültige Schaltung.
Ich hab von meinen "Lieblingstypen" (t85, t44, m88) jeweils ein "Debuggingopfer". Das kommt in die zu entwickelnde Schaltung rein und frisst da die Schreibzyklen. Wenn das Proggi steht wird der Käfer getauscht und der "jungfräuliche" Controller einmalig gebrannt. Diesen Luxus kann man sich mit DIPs ja leicht gönnen. Bei SMD sieht das anders aus, aber da würde ich u.U. eh 1-2 Testplatinen planen, weil irgendwann im Entwicklungsverlauf kommt man mal mit einer höheren Spannung an einen Pin (z.B. wenn im Multi die Kabel noch im Amperebereich stecken) und dann ist der uC futsch.
Max D. schrieb: > Ich hab von meinen "Lieblingstypen" (t85, t44, m88) jeweils ein > "Debuggingopfer". Das kommt in die zu entwickelnde Schaltung rein und > frisst da die Schreibzyklen. Wenn das Proggi steht wird der Käfer > getauscht und der "jungfräuliche" Controller einmalig gebrannt. Das halte ich für wenig sinnvoll und mache es folglich auch anders. Selbst bei großen Programmen habe ich noch nie mehr als vielleicht 100 Flash-Zyklen gebraucht. Das ist so deutlich von den garantierten 10.000+ (und auch den früher nur 1000) Zyklen weg, daß ich genau gar keine Skrupel habe, den µC danach mit dem finalen Programm in der Schaltung zu lassen. Zumal es ja nur Hobby ist und demzufolge alles Einzelstücke. Ich hätte im Gegenteil Bedenken, das "Debuggingopfer" dann doch mal aus Versehen irgendwo zu verbauen. Oder ich würde mir bei einer Fehlfunktion meiner Schaltung Gedanken machen, ob vielleicht mein Opferchip jetzt gerade die Hufe hochgerissen hat. Der einzige Weg, wie man beim Entwickeln realistisch die Lebensdauer des Flash knacken kann, ist Debuggen per debugWIRE mit Breakpoints. Denn für einen Breakpoint wird da das Flash modifiziert. Und natürlich, wenn man das Flash als EEPROM mißbraucht. Aber das ist dann ja eigene Dummheit.
Ben B. schrieb: > Moin! > Kann man einen µC mit 20.000 oder mehr Flash-Zyklen noch zuverlässig > einsetzen oder besteht dann ein erhöhtes Ausfallrisiko durch Bitfehler > im Programm? Kannst ja mal eine Page 20k beschreiben und über die Winterzeit auf 'n Ölbrenner lagern..
Axel S. schrieb: >> Wenn das Proggi steht wird der Käfer getauscht >> und der "jungfräuliche" Controller einmalig gebrannt. > Das halte ich für wenig sinnvoll und mache es folglich auch anders. > Selbst bei großen Programmen habe ich noch nie mehr als vielleicht 100 Flash-Zyklen gebraucht. Meine Arduino-Software zähle ich hoch, die meldet sich mit Datum & laufender Nummer, entweder auf dem Display und / oder der seriellen Schnittstelle. Da ich es nicht von Beginn an so gemacht habe, ist es bei nur drei Projekten nachvollziehbar. Das eine ist bei 378, die anderen sind bei 152 und 162 angekommen. Egal, auch das ist weit genug weg von der Spezifikation und ich sehe keinen Grund, die ICs zu wechseln.
Hallo Die ATmegas und ATXmegas machen kein wear leveling im Flash, d.h. die Adress-Seitenzuordnung ändert sich nicht. Der Flash wird zudem seitenweise gelöscht und beschrieben (SPM_PAGESIZE) - es verschleißen also nur solche Seiten. Nutzt man Teile des Flash also als NVM und belässt die Adressbereiche gleich und PAGESIZE aligned, muss man keine Angst haben das der Programmcode korruped... Korruptionen im als "EEPROM" zweckentfremdenden Bereich kann man mit fehlererkennenden Codes / CRCs detektieren - ggf. dann auf andere freie Bereiche ausweichen... Ausserdem sind Bitdefekte im Flash nur 0-Werte die eigentlich mal 1-Werte waren - ggf. kann man mit dieser Information noch anders gegen mitigieren...
:
Bearbeitet durch User
Michael U. schrieb: > das sind doch bei täglich 10x neu flashen noch nicht mal ganz 5 1/2 > Jahre... ;-) Hast du da auch Freitag, Samstag, Sonntag, Krankheit, Feiertage, Urlaub, usw. mit beachtet :-)
Axel S. schrieb: > Das halte ich für wenig sinnvoll und mache es folglich auch anders. > Selbst bei großen Programmen habe ich noch nie mehr als vielleicht 100 > Flash-Zyklen gebraucht. Das ist so deutlich von den garantierten 10.000+ > (und auch den früher nur 1000) Zyklen weg, daß ich genau gar keine > Skrupel habe, den µC danach mit dem finalen Programm in der Schaltung zu > lassen. Zumal es ja nur Hobby ist und demzufolge alles Einzelstücke. Mein Aufwand den Käfer zu tauschen ist Sekunden und dafür bin ich beruhigt, dass ich die besten Chancen auf einen langen Erhalt der Programmierung habe. Zumal die Kombination 20k Zyklen + 10 Jahre lagern in der Praxis der Großkunden eher selten vorkommt und daher von dem Hersteller evtl. etwas stiefmütterlich behandelt werden könnte. > Ich hätte im Gegenteil Bedenken, das "Debuggingopfer" dann doch mal aus > Versehen irgendwo zu verbauen. Oder ich würde mir bei einer Fehlfunktion > meiner Schaltung Gedanken machen, ob vielleicht mein Opferchip jetzt > gerade die Hufe hochgerissen hat. Das "Opfer" ist dick mit weißen Edding markiert um Fehleinbau zu verhindern. Desweiteren dürfte es weit jenseits der 20k Zyklen eine "retention time" von den paar Minuten haben um das Proggi zu testen. Meistens verlier oder grill (wobei da AVRs ja echt hart im Nehmen sind) ich den Käfer eh lange bevor der auch nur 10k knacken dürfte.
Max D. schrieb: > Mein Aufwand den Käfer zu tauschen ist Sekunden Du bist aber wirklich gut im Auslöten. Ich bin da eher ungeschickt und reiß auch schon mal ein Pad ab. Daher vermeide ich das Tauschen von Chips. MfG Klaus
Klaus schrieb: >> Mein Aufwand den Käfer zu tauschen ist Sekunden > Du bist aber wirklich gut im Auslöten. Bei DIP mit Fassung muss man nicht löten...
S. R. schrieb: > Bei DIP mit Fassung muss man nicht löten... Meinst du jetzt DIP in Wackelkontakt ist besser als ein paar Tausend Programmierzyklen eingelötet? MfG Klaus
Das Problem an sich ist eigentlich nicht das flashen sondern die Datenerhaltung, mit jeder Programmierung nimmt die Lebensdauer weiter ab, die Chiphersteller spezifizieren wie lange die Daten auf dem Chip erhalten bleiben solange eine gewisse Anzahl an Flash-Cycles eingehalten wird. Wir führen im Labor regelmäßig Langzeit-Flash-Orgien durch (Loop „Flashen -> Verify“) und bis jetzt war noch nie ein Chip so stark zerflasht das er das darauf folgende Verify nicht bestanden hätte. In kritischen Bereichen wie der Automotive Industrie wird auch mit Margin Levels gearbeitet um die Programmierung zu bewerten.
Danke euch für die ganzen Antworten und Anregungen. Zeigt mir auf jeden Fall, daß doch einige Leute Überlegungen in die gleiche Richtung anstellen. Ich denke dann werd ich nach dem Testen auch einen frischen Controller in die Schaltung einsetzen. Auch wenn die AVRs wirklich hart im Nehmen sind, es nutzt mir nichts wenn der IC zwar das Verify übersteht, aber nach ein paar Monaten Alzheimer bekommt. Bei meinen Schaltungen (außer den "in der Produktion gebauten") sind auch alle µCs gesockelt. Erstens verstecke ich da gerne sowas wie Entstörkondensatoren im Sockel (da kommt man problemlos nahe an die Pins) und falls man doch mal einen µC zerbombt 40 Pins wieder rauspopeln... Nee!!
Ben B. schrieb: > Bei meinen Schaltungen (außer den "in der Produktion gebauten") sind > auch alle µCs gesockelt. Und da stellt sich mir die Frage, was passiert wahrscheinlicher: ein Bit im Flash kippt oder ein Pin vergammelt im Sockel. Und ein wirklich guter Sockel ist leicht teurer als der µC. MfG Klaus
Was ist eigentlich das ursprüngliche Problem? Nach der Entwicklung verwendet man sowieso immer jungfräuliche Chips für neue Boards. Ich habe eher die Befürchtung, dass du irgendwelche Daten in hohen Raten im Flash / EEprom abspeicherst und deswegen die Frage stellst. Das wäre der falsche Ansatz.
Klaus schrieb: > Meinst du jetzt DIP in Wackelkontakt ist besser als ein paar Tausend > Programmierzyklen eingelötet? Die wackeln erst nach einigen zig Steckzyklen, und so oft sollte man ein IC nicht auswechseln müssen. Wenn doch -> Textool Sockel. Ich habe mit den teureren runden "gedrehten" Fassungen schlechtere Erfahrungen gemacht, als mit den normalen.
Also normalerweise vergammeln keine Pins im Sockel. Da muß man sich schon Mühe geben und das Ding extrem schlecht behandeln, damit das passiert. Regelmäßig duschen oder so... Ich hatte noch nie Kontaktprobleme mit gesockelten µCs. Das ursprüngliche "Problem" geht dahin, daß ich bei meiner AlarmSau sehr viel auf dem Controller selber teste, da ich mich erst mit dem GSM-Modul anfreunden muß bzw. musste. Ich weiß nicht wieviele Tausend Schreibzyklen der µC durch die ganze Testerei und Fehlersuche beim Entwurf der GSM-Funktionen in die Fresse bekommen hat ... gefühlt waren es einige. Ich habe auch neue USART-Subroutinen für das Ding geschrieben (mehrere Puffer) damit ohne Flusssteuerung keine Daten verlorengehen. Die sind am Anfang auch nicht perfekt gelaufen. Assembler ist cool, aber zum Debuggen braucht man eben länger. Inzwischen ist das Grundgerüst von dem Programm aber fertig, das Ding kann mit der Hardware umgehen, SMS senden und empfangen (bzw. darauf mit einem Statusbericht reagieren). Die Hauptschleife mit der Verbindung zum Terminal läuft auch (z.B. periodische Statusmeldungen auf dem Terminal-Display). Die Programmierung des Terminals war ein Witz dagegen. Jetzt kommt "nur noch" die Benutzerführung bzw. menügesteuerte Konfiguration. Das ist nochmal eine Ecke Code und mehr Text, aber das wird der Controller schon noch überstehen.
Ben B. schrieb: > Das ursprüngliche "Problem" geht dahin, daß ich bei meiner AlarmSau sehr > viel auf dem Controller selber teste, da ich mich erst mit dem GSM-Modul > anfreunden muß bzw. musste. Ich weiß nicht wieviele Tausend > Schreibzyklen der µC durch die ganze Testerei und Fehlersuche beim > Entwurf der GSM-Funktionen in die Fresse bekommen hat ... gefühlt waren > es einige. Das ist ein "Problem", wegen der "gefühlten" Anzahl. Man neigt dazu, grob daneben zu schätzen. Ich finde es schade, daß avrdude die Anzahl der Programmierzyklen nicht mehr im EEPROM verwalten kann (Option -y). Wenn man das alles aus einem Makefile heraus macht, dann kann man sich abhelfen, indem man den Zähler in einem eigenen File hält und in der Regel für das Flashen hochzählt. Z.B. so:
1 | # Program the device. |
2 | flash: $(TARGET).hex cycles.txt |
3 | $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_WRITE_FLASH) |
4 | @expr `cat cycles.txt` + 1 > cycles.txt |
5 | @echo -n "number of flash cycles: " |
6 | @cat cycles.txt |
7 | |
8 | cycles.txt: |
9 | @echo 0 > cycles.txt |
Yep da hast Du höchstwahrscheinlich Recht. Vielleicht sinds real "nur" ein paar hundert Schreibzyklen. Schade, daß es da nirgendwo einen Zähler im AVR-Studio oder auf dem IC selber gibt. Vielleicht baue ich beim nächsten Programm bzw. nächsten frischen Controller mal eine Funktion an den Start, die eine Checksumme vom Programm errechnet und einen Zähler im EEPROM hochzählt wenn sich die Checksumme geändert hat.
Das gleiche Programm drüber Flashen zählt aber auch als 1 Zyklus.
Yep, aber das sollte verschwindend selten vorkommen. Selbst wenn man beim Debuggen nur ein einziges Register verändert oder eine einzelne Ziffer, fällt das schon bei einer einfachen Prüfsumme auf. Wenn ich mit dem Programmer einen Reset erzeugen möchte oder so, flashe ich auch nicht das gleiche Programm drüber, sondern lese die Chipsignatur aus. Das erzeugt auch einen Reset. Ich würde die Methode nicht "exakt" nennen, aber "genau genug".
Klaus schrieb: > Meinst du jetzt DIP in Wackelkontakt ist besser als ein paar Tausend > Programmierzyklen eingelötet? Ich weiß nicht, was du mit "DIP in Wackelkontakt" meinst - billige Breadboards vielleicht? Wir reden hier von vielleicht 3 Steckzyklen im Sockel (IC rein, Entwicklung, IC raus, neuer IC rein, fertig), das kann so ein Sockel problemlos ab.
Ben B. schrieb: > Also normalerweise vergammeln keine Pins im Sockel. Da muß man sich > schon Mühe geben und das Ding extrem schlecht behandeln, damit das > passiert. Regelmäßig duschen oder so... Ich hatte noch nie > Kontaktprobleme mit gesockelten µCs. Du kaufst anständige Sockel? Und da kommt der Grund: Klaus schrieb: > Und ein wirklich guter Sockel ist leicht teurer als der µC. Ich habe genug DIL-Sockel gesehen, die schon fast aus Tüte heraus Aussetzer fabrizieren, dafür aber billig sind. In ganz schlechter Erinnerung ist mir eine Commodore-Floppy 3040 für damals mehrere tausend DM, da habe ich tatsächlich alle Sockel gewechselt und danach keine Abstürze mehr gehabt.
Manfred schrieb: > In ganz schlechter Erinnerung ist mir eine Commodore-Floppy 3040 für > damals mehrere tausend DM, da habe ich tatsächlich alle Sockel > gewechselt und danach keine Abstürze mehr gehabt. Ahh, das waren noch Zeiten! Einzelfederkontakte mit Abstützung auf dem Plastikrahmen. Apple hat sowas auch verbaut, da musste man einmal im Jahr alle ICs in die Fassungen zurückdrücken. Die haben sich langsam rausgearbeitet. Damals gab es den "two inch quick fix": Das Gerät 5,08 cm anheben und auf den Tisch fallen lassen. Das hat die meisten Wackelkontakte behoben. Gerade mit den alten CBM-Kisten in ihren Gusseisen-Gehäusen machte das Freude.
soul e. schrieb: > Manfred schrieb: >> In ganz schlechter Erinnerung ist mir eine Commodore-Floppy 3040 für >> damals mehrere tausend DM, da habe ich tatsächlich alle Sockel >> gewechselt und danach keine Abstürze mehr gehabt. > > Ahh, das waren noch Zeiten! Einzelfederkontakte mit Abstützung auf dem > Plastikrahmen. Du kennst die Sockel also ... dieser Scheißdreck ist noch heute am Markt! > Damals gab es den "two inch quick fix": Das Gerät 5,08 cm anheben und > auf den Tisch fallen lassen. Das hat die meisten Wackelkontakte behoben. Habe ich nie gehört, aber nett :-) > Gerade mit den alten CBM-Kisten in ihren Gusseisen-Gehäusen machte das > Freude. Ich hätte es mich trotzdem nicht getraut.
> "two inch quick fix" > Das hat die meisten Wackelkontakte behoben. Oder für den vorzeitigen Feierabend gesorgt wenn danach gar nichts mehr geht. Also ich hatte ehrlich nie Problem damit, auch nicht bei meinem C64 und seiner Floppy. Allerdings kaufe ich für meine Platinen auch immer Präzisionssockel. Die paar Cent zu sparen macht für mich nicht so viel Sinn und in geprüften Schaltungen bzw. Serienproduktion würde ich den Controller aus Kostengründen vermutlich verlöten, bzw. dann ist es höchstwahrscheinlich sowieso eine SMD-Version. Andere Frage, die passt hier gerade: Gibts auch Testsockel für SO-8 oder TQPF-44 (oder wie das heißt) oder so, wo man einen AVR nur kurz zum Programmieren reinschmeißen und hinterher einfach wieder entnehmen kann, um ihn dann programmiert irgendwo aufzulöten?
Ben B. schrieb: > Andere Frage, die passt hier gerade: Gibts auch Testsockel für SO-8 oder > TQPF-44 (oder wie das heißt) oder so, wo man einen AVR nur kurz zum > Programmieren reinschmeißen und hinterher einfach wieder entnehmen kann, > um ihn dann programmiert irgendwo aufzulöten? Gibt es. Einfach mal nach "TQFP44 ZIF" in aliexpress suchen. Der Chinese will so 10-15€ haben. SOP8 kostet knappe 5.
Solche Sockel gibt es für die verschiedensten Bauformen, auch Kontaktierung von exposed Pads. Hersteller wären zum Beispiel Plastronics, Yamaichi und Enplas, Standardbauformen sind erschwinglich, exotischeres kann sehr schnell sehr teuer werden.
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.