Beschädigung des AVR-Flash-Speichers

11

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):

Flash-Vergleich

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?

Rev1.0
quelle
Sind im zweiten Block in Ihrem Beispiel irgendwelche Bits von 1-> 0 oder alle 0-> 1-Übergänge gegangen? Ich habe ein Skript, das dies berechnet, aber ich werde nicht alle Zahlen aus Ihrem Screenshot eingeben.
Markrages
@markrages: Beim Betrachten nur 0-> 1. Eine Antwort wies auch darauf hin, dass es wie ein teilweises Löschen aussieht, bei dem nicht alle Bits auf 1 gedreht wurden. Vielen Dank für die Beobachtung.
Rev1.0

Antworten:

11

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.
Jacen
quelle
Ihre Beobachtung zum teilweisen Löschen auf der dritten Seite erscheint plausibel. Zum Atmel-Text: Wir sind uns alle einig, dass der BSB obligatorisch zu sein scheint. Aber ich bin mir immer noch nicht sicher über die GENAUE Ursache der Korruption. Ist es nicht ziemlich unwahrscheinlich, dass der Controller gerade (wegen Niederspannung) diese spezielle Anweisung ausführt, um eine Flash-Seite zu löschen? Ich meine, dies müsste sogar während der Ausführung des Bootloader-Codes geschehen, da Flash nur von dort aus beschreibbar ist. Und es erfordert eine bestimmte Reihenfolge.
Rev1.0
3
Es ist nicht möglich, die genaue Ursache der Beschädigung zu erklären: Wenn Ihr Vcc abfällt, wird es zu niedrig, um einen Transistor vollständig mit einem anderen zu sättigen. Eine MCU ist im Grunde eine sehr große logische Gleichung. Wenn sich Ihre Transistoren nicht mehr wie logische Schalter verhalten, ändern Sie diese Gleichung. Da der erste Transistor, der sich schlecht verhält, von der ASIC-Wafer-Dotierung und externen elektromagnetischen Störungen abhängt, können Sie nicht vorhersagen, was passieren wird. Um dieses Problem zu beheben, können Sie beim Entwerfen Ihres ASIC einen analogen Teil hinzufügen, der den digitalen Teil ausschaltet, bevor Sie sich schlecht benehmen. Aber es erhöht die gesamten ASIC-Kosten.
Jacen
Verwirrend, dass im Anwendungshinweis AVR180 External Brown-out Protection Folgendes angegeben ist: "Beachten Sie, dass der Speicherinhalt des internen AVR®-Flash-Programmspeichers niemals durch eine unzureichende Versorgungsspannung beeinträchtigt wird." Weiter: "Da die AVR-CPU nicht in den eigenen Programmspeicher schreiben kann, wird der interne Speicherinhalt des Flash-Programms niemals von einem Stromausfall beeinflusst." - IMO Atmel ignoriert nur, dass es so etwas wie Bootloader gibt, die Flash-Mem ändern müssen.
Rev1.0
@ Rev1.0 Nun ja, es ist ziemlich unwahrscheinlich ... deshalb wird es nur alle paar Monate auf einem Gerät angezeigt und nicht immer auf allen Geräten.
user253751
"Ich meine, dies müsste sogar während der Ausführung des Bootloader-Codes geschehen, da Flash nur von dort aus beschreibbar ist." - Das stimmt nur, wenn die Boot-Lock-Bits ( BLB01und Freunde) richtig gesetzt sind! Sind sie? "Verwirrend ... Anwendungshinweis ..." - Anwendungshinweise sind notorisch unzuverlässig. Verwenden Sie sie nur zur Inspiration. Für Garantien verlassen Sie sich auf die Datenblätter (die auch nicht unfehlbar sind, aber hey).
Marcelm
4

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.

Benutzer
quelle
3
Haben Sie solide Referenzen zu WIE und WARUM "Speichersteuerungshardware beschädigt oder löscht einen Teil des Speichers unter Niederspannungsbedingungen"? Es gibt viele Forumsdiskussionen über Flash-Korruption, aber es kommt fast nie auf etwas Festes an, weshalb ich hier gefragt habe.
Rev1.0
Handelt es sich um ein In-Chip-Unterspannungsproblem oder um eine falsche / zufällige Ausführung des Programms im Bootloader-Bereich, das AFAIK nur FLASH ändern kann? Wenn das zweite Problem das Deaktivieren der Bootloader-Ausführung über FUSE ist, sollte das Problem behoben sein.
TMa
Ich erinnere mich, dass ich in den Errata von mindestens einem MEGA-Mikro darüber gelesen habe.
Benutzer
3

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.

vsz
quelle
1
Danke für die Antwort. Wir haben letztendlich einen externen Brown-Out-Detektor mit extrem geringem Stromverbrauch verwendet und hatten seitdem keine Korruptionsprobleme mehr.
Rev1.0
0

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".

woodz
quelle