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 läuft permanent im Schlafmodus und wacht nur einmal pro Sekunde (RTC) oder wenn eine der beiden externen Interrupt-Leitungen getriggert wird auf.

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

Die Geräte wurden mit internem Brown-out DEAKTIVIERT entwickelt, da dies den Stromverbrauch verdoppelt und eine lange Batterielebensdauer obligatorisch ist (ich denke, dass eine externe Brown-out-Erkennung verwendet werden sollte - ein Re-Design ist in Arbeit).

Problem:
Alle paar Monate funktioniert ein Gerät einfach nicht mehr, es wurden KEINE Firmware-Updates auf diesen Geräten durchgeführt. Nach weiterer Untersuchung scheinen die Flash-Inhalte dieser Geräte jedoch beschädigt zu sein. Außerdem waren die Batterien einiger dieser Geräte noch gut, aber ich möchte eine Art Unterspannungssituation nicht ausschließen.

Dies ist ein Vergleich der ursprünglichen Flash-Inhalte (links) mit den beschädigten Inhalten (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, nicht einzelne Bytes.
  • Beschädigter Inhalt liest die meiste Zeit 0xFF, kann aber auch einige andere Werte enthalten oder völlig "zufällig" sein.
  • Der kleine Balken auf der linken Seite des Bildes zeigt alle betroffenen Bereiche. Für dieses Gerät ist es etwa ein Zehntel des gesamten Flash-Inhalts.
  • Wir hatten ein Gerät, bei dem nur eine einzelne Seite betroffen war.

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

Möglicherweise startet der Controller aufgrund von Unterspannung zufällig neu 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 vom Flash ausgeführt, sondern auch zufällige Anweisungen (es gibt keine Garantie dafür, dass der Code vom Flash richtig gelesen und interpretiert wird). Außerdem verhalten sich andere Teile der MCU möglicherweise nicht wie vorgesehen, einschließlich des Schutzes Mechanismen."

Frage(n):
Glauben Sie, dass die Erklärung "zufälliges Verhalten bei Unterspannung und Ausführung einiger Anweisungen, die Daten in Flash-Seiten ändern" stichhaltig ist? Wenn das der Fall ist, warum sehen wir diese Art von Fehlern nicht ständig nur als Ursache für einige Softwareprobleme (Stapelüberlauf, ungültige Zeiger).

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

Sind im zweiten Block in Ihrem Beispiel irgendwelche Bits von 1-> 0 gegangen oder alle 0-> 1-Übergänge? Ich habe ein Skript, das dies berechnet, aber ich werde nicht alle Zahlen aus Ihrem Screenshot eingeben.
@markrages: Vom 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 gesetzt wurden. Danke für die Beobachtung.

Antworten (4)

Sie sollten feststellen, dass der Flash nicht geschrieben, sondern gelöscht wird. Ein gelöschter Flash ist voll mit 0xFF. Ihre ersten 256 Byte werden vollständig gelöscht, Ihre dritte 256-Byte-Region wird teilweise gelöscht (Sie haben nur 0 bis 1 Bitflips von korrekten Daten zu beschädigten).

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 von Page Erase by SPM ziemlich einfach.

Abschnitt 23.8.1 (Verhindern von Flash-Korruption) könnte Sie interessieren:

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 zum Flash eine Mindestspannung, um korrekt zu funktionieren. Zweitens kann die CPU selbst Befehle falsch ausführen, wenn die Versorgungsspannung zum Ausführen von Befehlen zu niedrig ist. Flash-Korruption kann leicht vermieden werden, indem Sie diese Designempfehlungen befolgen (eine reicht aus):

  1. Wenn im System keine Bootloader-Aktualisierung erforderlich ist, programmieren Sie die Bootloader-Sperrbits, um Aktualisierungen der Bootloader-Software zu verhindern.
  2. Halten Sie AVR RESET aktiv (low) während Perioden mit unzureichender Versorgungsspannung.
    Dies kann durch Aktivieren des internen Brown-Out-Detektors (BOD) erfolgen, wenn die Betriebsspannung dem Erkennungspegel entspricht. Falls nicht, kann eine externe Rücksetzschutzschaltung für niedrige VCC verwendet werden. Wenn ein Reset auftritt, während eine Schreiboperation im Gange ist, wird die Schreiboperation abgeschlossen, vorausgesetzt, dass die Stromversorgungsspannung ausreichend ist.
  3. Halten Sie den AVR-Core während Perioden mit niedriger VCC im Power-down-Schlafmodus. Dadurch wird verhindert, dass die CPU versucht, Anweisungen zu decodieren und auszuführen, wodurch das SPMCSR-Register und damit der Flash wirksam vor unbeabsichtigten Schreibvorgängen geschützt werden.
Ihre Beobachtung bezüglich der Teillöschung auf der dritten Seite erscheint plausibel. Bezüglich des Atmel-Textes: Wir stimmen alle darin überein, dass BOD 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 (aufgrund der niedrigen Spannung) diese spezielle Anweisung zum Löschen einer Flash-Seite einfach ausführt? Ich meine, das müsste sogar während der Ausführung des Bootloader-Codes passieren, da Flash nur von dort aus beschreibbar ist. Und es erfordert eine bestimmte Reihenfolge.
Es ist nicht möglich, die genaue Quelle der Korruption zu erklären: Wenn Ihre Vcc abfällt, wird sie 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 falsch verhält, von der Dotierung des ASIC-Wafers 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 er sich falsch verhält. Aber es erhöht die gesamten ASIC-Kosten.
Verwirrend, dass in der Application Note AVR180 External Brown-out Protection steht: „Beachten Sie, dass der Inhalt des AVR®-internen Flash-Programmspeichers niemals durch unzureichende Versorgungsspannung beeinträchtigt wird“. Weiter: "Da die AVR-CPU nicht in der Lage ist, in ihren eigenen Programmspeicher zu schreiben, wird der Inhalt des internen Flash-Programmspeichers niemals durch eine Stromausfallsituation beeinträchtigt." - IMO Atmel ignoriert einfach, dass es so etwas wie Bootloader gibt, die das Flash-Mem ändern müssen.
@Rev1.0 Nun ja, es ist ziemlich unwahrscheinlich ... deshalb sehen Sie es nur alle paar Monate auf einem Gerät und nicht ständig auf allen Geräten.
"Ich meine, das müsste sogar während der Ausführung des Bootloader-Codes passieren, da Flash nur von dort aus beschreibbar ist." - Das gilt nur, wenn die Bootlock-Bits ( BLB01und Co.) entsprechend gesetzt sind! Sind sie? "Verwirrend ... Anwendungshinweis ..." - Anwendungshinweise sind notorisch unzuverlässig. Verwenden Sie sie nur zur Inspiration; Verlassen Sie sich für Garantien auf die Datenblätter (die auch nicht unfehlbar sind, aber hey).

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

Selbstverständlich sollten Sie den Brownout-Schutz auf Mikrocontrollern immer aktivieren.

Haben Sie solide Hinweise darauf, WIE und WARUM "Speichersteuerungshardware einen Teil des Speichers unter Niederspannungsbedingungen beschädigt oder löscht"? Es gibt viele Forumsdiskussionen über Flash-Korruption, aber es kommt fast nie auf etwas Solides hinaus, weshalb ich hier gefragt habe.
Handelt es sich um ein Unterspannungsproblem im Chip oder hängt es mit der falschen/zufälligen Ausführung des Programms im Bootloader-Bereich zusammen, das AFAIK nur FLASH modifizieren kann? Wenn das zweite Problem ist, sollte das Deaktivieren der Bootloader-Ausführung über FUSE das Problem lösen.
Ich erinnere mich, darüber in den Errata von mindestens einem MEGA-Mikro gelesen zu haben.

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

Beachten Sie, dass der Prozessor umso empfindlicher auf Unterspannungsprobleme reagiert, je schneller er läuft. Wenn das Senken der CPU-Frequenz für Sie eine verfügbare Option ist, könnte es einen Versuch wert sein.

Danke für die Antwort. Wir haben schließlich einen externen Brownout-Detektor mit extrem niedrigem Stromverbrauch verwendet und hatten seitdem keine Korruptionsprobleme mehr.

EMV wird Ihr größter Feind sein, wenn man sich nicht an die Hauptregeln des PCB-Designs hält. Hier sind die wichtigsten aus meiner eigenen Erfahrung: - Sperrkondensatoren auf jedem IC, unabhängig davon, was die Hersteller in ihren Datenblättern über höllische Schaltpläne sagen, legen Sie mindestens einen zwischen 100 pF - 1 nF auf die Stromleitungen jedes ICs - Leitende Massebereiche an jede PCB-Schicht so weit wie möglich. Diese Bereiche sollen so oft wie möglich durch alle Lagen hindurch über Vias kontaktiert werden, ein Raster von 50mil ist ein guter Wert. Verbinden Sie diese Bereiche mit dem Massesignal. - Lassen Sie niemals unverbundenes (schwebendes, an kein Signal angeschlossenes) Kupfer in Ihrer Leiterplatte. Es wirkt wie eine Antenne und bringt elektromagnetische Strahlung auf göttliche Weise auf die Geräte - machen Sie die Spuren, die Taktsignale tragen, so kurz wie möglich

Finden Sie mehr Details durch Suchmaschinenanfragen wie "Leitfaden für EMV-sicheres Leiterplattendesign"

Beschädigung des AVR-Flash-Speichers
AntwortenHierDatenschutz-Bestimmungen1y, 0v