Frage:
Was passiert, wenn Sie> 10000 Mal in den Flash-Speicher eines ATmega schreiben?
user8437812
2017-04-05 14:49:30 UTC
view on stackexchange narkive permalink

Ich habe festgestellt, dass ich alle 5 Minuten Code hochlade und eine relativ intensive Trial-and-Error-Entwicklung durchführe. Diese Angewohnheit kann später zu Problemen führen, insbesondere wenn ich an einem benutzerdefinierten Board (nicht von Arduino) arbeite ) wo der Chip nicht leicht austauschbar ist.

Was wird passieren?

Ich habe festgestellt, dass avrdude den geschriebenen Flash überprüft. Wird es also einfach anfangen, Fehler zu bemerken und möglicherweise nicht ohne Fehler schreiben zu können?

Oder wird es manchmal funktionieren, manchmal nicht?

Beispiel für starke Nutzung: Eine benutzerdefinierte Leiterplatte, bei der ein einfacher Austausch der MCU nicht möglich ist. 10.000 Schreibvorgänge entsprechen 100 Tagen, alle 8 Stunden Entwicklungszeit, mit Flash-Schreibvorgängen alle 5 Minuten.

Ich habe mehrere Gewohnheiten, die zu häufigem Flash-Schreiben führen: Ich füge Benchmarks in meinen Code ein und teste Geschwindigkeitsverbesserungen bei kleinen Optimierungen , Programmgrößenoptimierungen usw.

Ich versuche jetzt, mich davon abzuhalten, vor dem Testen zu häufig zu blinken und mehr Code-Revisionen durchzuführen, anstatt sofort zu testen.

In Fazit: Ja, es ist unwahrscheinlich, und wenn Sie beispielsweise ein Jahr lang weniger intensiv Vollzeit an einem Board arbeiten, können Sie es sich wahrscheinlich leisten, ein anderes Board zu kaufen, wenn das erste ausfällt die Flash-Überprüfung.

Soweit ich weiß, überprüft avrdude jedes geschriebene Byte. Sie werden wissen, wann es fehlgeschlagen ist. Einige haben Tests mit dem EEPROM durchgeführt, aber ich kenne keinen Test mit Flash. Der alte ATmega8 hat die gleichen Nummern für Flash (10k) und EEPROM (100k), aber die neueren Chips sind besser. Ich nehme an, es beginnt nach vielen 10k Schreiben zu scheitern.
@Jot, Ich bin mir immer noch nicht sicher, ob die Folge ein beschädigter Flash sein wird, ob avrdude allmählich häufiger ausfällt und es erneut versuchen muss oder ob der Flash einfach nicht richtig geschrieben werden kann, z. immer eine falsche Anzeige ergeben.
Die Datenblätter sind in der Regel konservativ, und die angegebenen Zahlen gelten normalerweise für einen weiten Temperaturbereich. Bei Raumtemperatur können Sie wahrscheinlich weit über die 10K-Zyklusgrenze hinausgehen. Sie können einfach nicht 100% sicher sein, da Atmel über 10K hinaus kein Versprechen abgibt.
Ich versuche festzustellen, wie es scheitern wird.
Eigentlich wird es undefiniertes Verhalten sein. Grundsätzlich könnte alles passieren und es sollte vermieden werden, dies zu tun.
@Paul, In extremen Fällen wäre es also relevant, die Anzahl der Flash-Schreibvorgänge separat zu verfolgen? Da würde sich der Fehlermodus nicht vorhersehbar verhalten? Z.B. ein wiederholter Fehler beim Flash-Schreiben
Soms Programmer-Boards oder IDEs tun dies tatsächlich. Aber oft programmieren Sie das Mikro nicht mehr als 10.000 Mal neu.
Fünf antworten:
dannyf
2017-04-06 05:37:49 UTC
view on stackexchange narkive permalink

Was wird passieren?

Möglicherweise wird die Paritätsprüfung nicht bestanden. Das Hochladen von Code wäre also nicht möglich.

Trotzdem hatte ich aufgrund der Ausdauer noch nie einen Flash-basierten MCU-Fehler. Soweit ich mich erinnern kann, sind das unzählige mcus.

Um Ihnen einen Eindruck von der Kopffreiheit des Designs zu vermitteln, habe ich über mehrere Stunden bei 10 ms pro Lese- / Schreibzugriff auf ein Bild geschrieben und es dann von eeprom zurückgelesen ohne einen Fehler. Dieses EEPROM hat eine Ausdauer von 1 Million.

Wenn Sie also keine seltsamen Teile erhalten oder über einen langen Zeitraum wiederholt darauf schreiben, ist ein Flash-Fehler wahrscheinlich kein praktisches Problem.

JRobert
2017-04-05 19:04:38 UTC
view on stackexchange narkive permalink

In diesem Wikipedia-Artikel über Flash-Speicher werden Fehlermechanismen einschließlich Verweisen auf relevante Artikel erläutert. Ein Punkt, der mich überraschte, war die "Lesestörung" benachbarter Zellen nach einer großen Anzahl (> 100.000) Lesevorgänge von einer Zelle seit dem letzten Löschen, was dazu führte, dass die benachbarten Zellen fehlerhaft zurückgelesen wurden. Es gibt wahrscheinlich mehr dort und in den Artikeln, auf die verwiesen wird, als Sie jemals über Flash-Fehlermechanismen wissen wollten.

Jedoch ...

Bei 5 Minuten pro Test benötigen 10000 Tests 35 Tage Arbeiten rund um die Uhr oder über 100 Tage bei 8 Stunden / Tag, wobei diese Testrate beibehalten wird. Mein Punkt ist, dass Sie wahrscheinlich keine 10K-Zyklen erreichen werden. Wenn Sie jedoch Bedenken haben, einen stark genutzten Chip ins Feld zu bringen (und in einigen Fällen auch ich), lohnt sich das Socket Board Nr. 1.

Tatsächlich. Mein Anliegen ist hauptsächlich die aktive Entwicklung auf einer kundenspezifischen Leiterplatte mit einem ATmega2560, dessen manueller Austausch nicht allzu viel Spaß macht, obwohl dies machbar ist (100 Stifte + Risiko eines schwer erkennbaren Kurzschlusses der Stifte). Oder alternativ mehrere Boards kaufen.
Der Grund für die hohe Anzahl von Schreibvorgängen ist, dass ich verschiedene Funktionen für Automatisierung, Erkennung usw. feinabstimme - vielleicht könnte ein Teil davon durch Schreiben in das EEPROM über serielle usw. usw. gemildert werden, aber das ist viel komplizierter als nur wieder aufzubauen / neu zu flashen;)
Mein erster Gedanke ist, ob eine dieser Funktionen außerhalb des Systems eingestellt werden könnte. Und wenn nicht, wie hoch sind die Kosten für einen Ausfall vor Ort im Vergleich zu den Schritten, die erforderlich sind, um einen Fehler zu verhindern? Kostet ein Ausfall einige Ausfallzeiten? Ein globaler Serviceabruf? Eine Kundenbeziehung? Einen Patienten töten? Einige Szenarien rechtfertigen einfach nur eine große Vorabinvestition, um sie zu vermeiden. Autsch - rede über den Felsen gegen den harten Ort ...
Michel Keijzers
2017-04-05 15:00:55 UTC
view on stackexchange narkive permalink

Obwohl dies keine direkte Antwort auf Ihre Frage ist, kann es eine Antwort auf Ihr Problem sein (die Notwendigkeit intensiver Versuche und Irrtümer.

Wahrscheinlich testen Sie hauptsächlich Ihr Programm (Änderungen) und nicht Ihre Hardware (Änderungen). Da ich nicht davon ausgehe, dass Sie Ihre Hardware (Steckbrett) alle 5 Minuten ändern.

Wenn das Programm ziemlich kompliziert ist, ist es wahrscheinlich am besten, eine bestimmte zu schreiben Offline-Testprogramm, und führen Sie es auf einem Computer anstelle eines Arduino aus. Sie müssen wahrscheinlich einige Klassen / Bibliotheken stubben, die Sie verwenden, aber es kann Ihnen viel Zeit sparen. Außerdem haben Sie den Vorteil einer besseren IDE und vieler Weitere Debug-Möglichkeiten. Nachdem die Tests im Offline-Testprogramm bestanden wurden, versuchen Sie es auf dem Arduino.

Auf diese Weise müssen Sie das Programm wahrscheinlich nur einige Male pro Tag auf das Arduino hochladen.

Nach meiner Erfahrung wäre dies eher als Kommentar als als Antwort geeignet.
Ich denke, es kommt darauf an, was wichtiger ist: die Antwort auf die Frage selbst oder die Lösung seines Problems.
Dies ist eine gute Antwort, da 10.000 Versuche zu viel sind und es besser ist, das zugrunde liegende Problem zu beheben. Möglicherweise werden Verzögerungen verwendet, die angepasst werden müssen (anstatt Millis zu verwenden). Möglicherweise kann mehr als ein Arduino-Board oder Arduino Due mit mehreren Aufgaben verwendet werden. Ich denke, dass nur ein Zufallsgenerator zum Erstellen von Arbeitscode so viele Versuche erfordern würde.
gilhad
2017-04-05 17:07:19 UTC
view on stackexchange narkive permalink

AFAIK der Hersteller sagt, dass die Anzahl der Schreibzyklen garantiert ist. Normalerweise kann der Chip wenig mehr aushalten (damit der Hersteller die Garantie sicher einhält), einzelne Chips können zufällig viel, viel mehr aushalten.

Auch der Ausfall kann zu zwei Arten von führen Probleme - das erste ist in gewisser Weise besser - das Schreiben schlägt einfach fehl, nach dem Lesen wird "etwas" zurückgegeben (normalerweise Teil des geschriebenen Werts, aber einige Bits werden immer auf die gleiche 0/1 gesetzt). Das zweite ist, dass das Tragen das Schreiben unzuverlässig macht - Sie schreiben es, Sie lesen es ist in Ordnung, aber nach einiger Zeit (wie Tage / Monate) wird der Inhalt geändert und wenn Sie es erneut lesen, erhalten Sie "etwas" "wie im vorherigen Fall.

Es ist besser sicherzustellen, dass Sie den Chip austauschen können, bevor Sie zum" normalen Gebrauch "gehen und dort einen neuen einsetzen - verwenden Sie einen Sockel / erstellen Sie eine neue Platine / entlöten Sie alter Chip und neuer Lötzinn. Verwenden Sie den abgenutzten Chip für weitere Tests / Entwicklungen, aber für die Produktion verwenden Sie einen neuen mit nur wenigen Zyklen des Nachblitzens. Auch Software-Emulatoren können Ihre Entwicklung erheblich beschleunigen und die Notwendigkeit / Anzahl des erneuten Flashens des Chips auf der Platine verringern.

crusader27529
2017-04-06 00:54:39 UTC
view on stackexchange narkive permalink

Angenommen, Sie müssen nicht jedes Board einzeln feinabstimmen, senden Sie das Board, das Sie testen / anpassen, einfach nicht an das Feld '..... behalten Sie es im Haus und verwenden Sie es nur neue Boards für den Feldeinsatz.

10k Schreibzyklen sind jedoch viel.


ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...