Beschädigung des AVR-Flash-Speichers

Diese Frage bezieht sich auf die AVR-Deprogrammierung selbst .

Projektinfo:
Wir haben ein batteriebetriebenes Produkt mit einem ATMEGA644P. Die Anwendung wird permanent im Ruhemodus ausgeführt und wacht nur einmal pro Sekunde (RTC) oder wenn eine der beiden externen Interruptleitungen ausgelöst wird.

Das Gerät verfügt über einen ziemlich einfachen Bootloader, der über UART kommuniziert (über den RS232-Schnittstellen-IC). Es dient lediglich als bequeme Methode zum Aktualisieren der Firmware, sodass kein Hardware-ISP-Programmierer erforderlich ist. (Der Bootloader erwartet Prüfsummen-gesicherte Telegramme.)

Das Gerät wurde mit internem Brown-Out DISABLED entwickelt, da es den Stromverbrauch verdoppelt und eine lange Akkulaufzeit erforderlich ist (ich denke, dass eine externe Brown-Out-Erkennung hätte verwendet werden müssen - eine Neugestaltung ist in Arbeit).

Problem:
Alle paar Monate funktioniert ein Gerät nicht mehr. Auf diesen Geräten wurden KEINE Firmware-Updates durchgeführt. Nach weiterer Prüfung scheint der Flash-Inhalt dieser Geräte jedoch beschädigt zu sein. Außerdem waren die Batterien einiger dieser Geräte immer noch gut, aber ich möchte eine Unterspannungssituation nicht ausschließen.

Dies ist ein Vergleich des ursprünglichen Flash-Inhalts (links) mit dem beschädigten Inhalt (rechts):

Einige Beobachtungen:

• Ein beschädigter Block besteht immer aus mindestens einer Flash-Seite (256 Byte) und ist seitenausgerichtet. Mit anderen Worten: Es sind nur ganze Seiten betroffen, keine einzelnen Bytes.
• Beschädigter Inhalt liest die meiste Zeit 0xFF, kann aber auch einige andere Werte enthalten oder vollständig "zufällig" sein.
• Der kleine Balken auf der linken Seite des Bildes zeigt alle betroffenen Bereiche. Für dieses Gerät ist es ungefähr ein Zehntel des gesamten Flash-Inhalts.
• Wir hatten ein Gerät, auf dem nur eine Seite betroffen war.

Es ist durchaus plausibel, dass ein Unterspannungszustand beim Schreiben des Flash-Speichers den Flash-Inhalt beschädigen kann. Dies würde jedoch bedeuten, dass einige flashempfindliche Anweisungen ausgeführt werden müssen.

Möglicherweise wird der Controller aufgrund von Unterspannung zufällig neu gestartet, und der Bootloader-Code verhält sich während dieser Zeit völlig unvorhersehbar. Um einen Typen aus einem anderen Forum bezüglich Unterspannung zu zitieren:

"Es werden nicht nur zufällige Anweisungen von Flash ausgeführt, sondern auch zufällige Anweisungen (es gibt keine Garantie dafür, dass der Code von Flash korrekt gelesen und interpretiert wird). Außerdem verhalten sich andere Teile des mcu möglicherweise nicht wie vorgesehen, einschließlich Schutz Mechanismen. "

Frage (n):
Denken Sie, dass das "zufällige Verhalten bei Unterspannung und Ausführung einiger Anweisungen zum Ändern von Daten auf Flash-Seiten" - Erklärung ist richtig? Wenn dies der Fall ist, warum sehen wir diese Art von Fehlern nicht immer nur als Ursache für einige Softwareprobleme (Stapelüberlauf, ungültige Zeiger)?

Haben Sie andere Ideen, was diese Art von Korruption verursachen könnte? Könnte dies durch EMI / ESD verursacht werden?

Sie sollten beachten, dass der Blitz nicht geschrieben, sondern gelöscht wird. Ein gelöschter Blitz ist voll von 0xFF. Ihre ersten 256 Bytes werden vollständig gelöscht, Ihr dritter 256-Byte-Bereich wird teilweise gelöscht (Sie haben nur 0 bis 1 Bitflips von korrekten zu beschädigten Daten).

Laut Datenblatt ist dieser Flash seitenlöschbar (ich arbeite normalerweise mit Löschblöcken, die größer als die Seiten sind). Wie auf Seite 282 zu sehen ist, ist das Durchführen des Seitenlöschens mit SPM ziemlich einfach.

Sie könnten an Abschnitt 23.8.1 (Verhindern von Flash-Beschädigung) interessiert sein:

Eine Beschädigung des Flash-Programms kann durch zwei Situationen verursacht werden, in denen die Spannung zu niedrig ist. Erstens erfordert eine reguläre Schreibsequenz für den Flash eine minimale Spannung, um korrekt zu funktionieren. Zweitens kann die CPU selbst Befehle falsch ausführen, wenn die Versorgungsspannung zum Ausführen von Befehlen zu niedrig ist. Eine Flash-Beschädigung kann leicht vermieden werden, indem die folgenden Entwurfsempfehlungen befolgt werden (eine ist ausreichend):

1. Wenn im System kein Bootloader-Update erforderlich ist, programmieren Sie die Bootloader-Sperrbits, um Bootloader-Softwareupdates zu verhindern.
2. Halten Sie den AVR RESET während unzureichender Versorgungsspannung aktiv (niedrig).
   Dies kann durch Aktivieren des internen Brown-out-Detektors (BOD) erfolgen, wenn die Betriebsspannung dem Erkennungspegel entspricht. Wenn nicht, kann eine externe Schutzschaltung zum Zurücksetzen bei niedrigem VCC verwendet werden. Wenn während eines Schreibvorgangs ein Reset durchgeführt wird, wird der Schreibvorgang abgeschlossen, sofern die Versorgungsspannung ausreichend ist.
3. Halten Sie den AVR-Kern während Perioden mit niedrigem VCC im Energiesparmodus. Dies verhindert, dass die CPU versucht, Anweisungen zu dekodieren und auszuführen, wodurch das SPMCSR-Register und damit der Flash effektiv vor unbeabsichtigten Schreibvorgängen geschützt werden.

Dies ist ein bekanntes Problem und betrifft viele Mikrocontroller (nicht nur Atmel). Die Hardware zur Steuerung des Flash-Speichers beschädigt oder löscht einen Teil des Speichers unter Niederspannungsbedingungen. Die einfache Lösung besteht darin, einen Brown-Out-Schutz zu aktivieren.

Selbstverständlich sollten Sie bei Mikrocontrollern immer einen Brown-out-Schutz aktivieren.

Die Unterspannung ist eine sehr wahrscheinliche Ursache. Ich hatte zum Beispiel einmal ein Projekt, bei dem ein Brown-Out-Pegel von 1,8 V häufig zu Korruption führte und diese Korruptionen niemals mit einem Brown-Out-Pegel von 3,5 V reproduziert werden konnten.

Beachten Sie, dass je schneller der Prozessor läuft, desto empfindlicher ist er für Unterspannungsprobleme. Wenn Ihnen eine Verringerung der CPU-Frequenz zur Verfügung steht, ist es möglicherweise einen Versuch wert.

EMC wird Ihr größter Feind sein, wenn Sie die Hauptregeln des PCB-Designs nicht befolgen. Hier sind die wichtigsten aus meiner eigenen Erfahrung: - Blockieren von Kondensatoren auf jedem IC, unabhängig davon, was die Hersteller in ihren Datenblättern über höllische Schaltpläne sagen, setzen Sie mindestens einen zwischen 100 pF - 1 nF auf die Stromleitungen jedes IC - leiten Sie Erdungsbereiche an die Schicht jeder Leiterplatte so weit wie möglich. Diese Bereiche sind so oft wie möglich über Durchkontaktierungen durch alle Schichten zu erreichen. Ein Raster von 50 mil ist ein guter Wert. Verbinden Sie diese Bereiche mit dem Erdungssignal. - Lassen Sie niemals nicht angeschlossenes (schwebendes, an kein Signal angeschlossenes) Kupfer in Ihrer Leiterplatte. Es wirkt wie eine Antenne und setzt elektromagnetische Strahlung auf die Geräte - machen Sie Spuren, die Taktsignale übertragen, so kurz wie möglich

Weitere Details finden Sie in Suchmaschinenanfragen wie "Leitfaden für emc-sicheres Leiterplatten-Design".