Hatte noch jemand Fälle, in denen ein AVR nach mehreren Monaten auf mysteriöse Weise nicht mehr funktionierte, aber eine Neuprogrammierung ihn zurückbringen würde?
Ich betreibe eine Reihe von atmega328 in einem drahtlosen Sensornetzwerk. Ich hatte jetzt 3 Mal (in ungefähr einem Jahr), als einer von ihnen einfach aufgehört hat zu arbeiten. Ich werde das Programm neu brennen und es wird wieder funktionieren. Es ist nicht immer das gleiche Gerät, also scheint es kein defekter Chip zu sein.
Das scheint eine ziemlich katastrophale Sache zu sein, die die Leute davon abhalten würde, AVRs zu benutzen, also hat es offensichtlich etwas mit meinen besonderen Umständen zu tun. Ich habe mich nur gefragt, ob jemand anderes darauf gestoßen ist und vielleicht einige Hinweise hat.
Ich arbeite mit 3,3 V ohne Batterien, daher wird die Spannung zu niedrig, um sie alle paar Monate zu betreiben, und ich muss die wiederaufladbaren Akkus ersetzen. Die Module verwenden den Schlafmodus und den Watchdog-Timer, um 60 Sekunden lang zu schlafen, eine Messung vorzunehmen, sie per Funk an die Basisstation zurückzusenden und dann wieder zu schlafen. Die Module sind arduino-kompatibel, daher habe ich das Bit "Lass mich das nicht erneut brennen" nicht umgedreht.
Benutzt du BOD? Gelegentlich können unangenehme Dinge passieren, wenn ein Chip braun wird.
Wahrscheinlich ist die Brown-Out-Erkennung der richtige Weg, aber...
Ich hatte ein reines Softwareproblem , das sehr ähnliche Symptome verursachte, wenn auch viel schneller. Ich glaube, dass einiges an schlechtem C++ (Kompilieren?) zu einer Stack-Beschädigung führte und die Funktion außerhalb des eigentlichen Programms zurückkehrte und zufällige Anweisungen ausführte. Ich bin mir nicht sicher, was als nächstes passierte, aber die einzige Möglichkeit, das Problem zu beheben, bestand darin, das Programm neu zu brennen (anscheinend beinhalteten einige dieser zufälligen Anweisungen das Schreiben in den Programmspeicher).
Der Fehler war nur ein Destruktor, der zur falschen Zeit aufgerufen wurde. Die Variable global zu machen (damit sie nie zerstört wurde) hat das Problem behoben. Das Problem war sehr leicht reproduzierbar (es dauerte etwa eine Minute, bis es ausgelöst wurde) und bei sehr konstanter Stromversorgung. Das spezielle Setup war Arduino+WaveShield mit der WaveHC-Bibliothek, aber ich denke, das könnte jedem passieren, der C++ verwendet.
Wenn Sie Low-Level-Sprachen bevorzugen, habe ich versehentlich ungefähr dasselbe in Assembler gemacht, aber auf wundersame Weise verursachte dies nie etwas anderes als sporadische Timing-Probleme: Die meisten Befehle sind 2 Bytes lang, aber einige sind länger, und ich habe dummerweise die Sprungweite selbst berechnet und gesprungen in die Mitte eines 4-Byte-Befehls. Es wurde ziemlich schnell neu ausgerichtet, aber es ist nicht schwer, sich so etwas auf einem selten verwendeten Codepfad vorzustellen, der Wahnsinn verursacht.
Ich habe auch gesehen, dass unzureichende / schlecht platzierte / fehlende Vcc-Entkopplungskondensatoren ähnliche Effekte verursachen. Haben Sie eine lokale Entkopplung so nah wie möglich am IC? (100 nF - 1 uF Keramiktyp wird bevorzugt)
Ein weiterer Faktor, der dazu führen kann, dass Geräte ihren Speicher verlieren, sind elektrostatische Entladungen (ESD).
Das Anbringen einiger Varistoren an allen exponierten externen Anschlüssen kann dieses Problem lindern. Ich habe es zuvor in einigen kommerziellen Produkten gesehen, die auf Microchip PIC-Mikrocontrollern basieren, also ist es nicht unbekannt.
Es gibt einige praktische Varistoren, die auch als Filterkondensatoren dienen (in der Größenordnung von 10-150 pF). Sehen Sie sich diese unter http://www.tdk.co.jp/tefe02/e9c11_avr.pdf an
Sie sind klein, billig und schützen Ihr Gerät. Platzieren Sie sie so nah wie möglich an den Anschlüssen, die externe Signale auf die Platine bringen, und führen Sie alle Leiterbahnen sofort von den Anschlussstiften weg.
Rev