Backups und Snapshots in Embedded Systemen

Backups und Snapshots in Embedded Systemen

Die Notwendigkeit eines System-Snapshots

In der Welt der eingebetteten Systeme ist die Stromversorgung selten konstant. Ob es sich nun um einen unerwarteten Stromausfall, einen geplanten Batteriewechsel oder die Notwendigkeit handelt, in Modi mit extrem geringem Stromverbrauch zu wechseln, um die Lebensdauer des Geräts zu verlängern – Systeme verlieren häufig ihren Betriebskontext. Ohne einen Mechanismus zur Aufzeichnung des zuletzt bekannten fehlerfreien Zustands des Systems wird jeder Neustart zu einem Kaltstart, der eine zeitaufwändige Neuinitialisierung erfordert und den Verlust wichtiger Fortschritte bei laufenden Aufgaben zur Folge hat. Die Erstellung eines System-Snapshots mithilfe von Backup-Registern ermöglicht es einem Gerät, einen Warmstart durchzuführen und den Betrieb sofort an der Stelle fortzusetzen, an der er unterbrochen wurde, während historische Daten erhalten bleiben, die andernfalls im flüchtigen Speicher verloren gingen.

Definition des Snapshots: Was soll gespeichert werden?

Ein Snapshot ist mehr als nur eine Kopie des RAM. Es handelt sich um eine sorgfältig zusammengestellte Sammlung von Parametern, die für die Betriebskontinuität unerlässlich sind. Je nach Anwendung umfassen diese Daten in der Regel:

• Zustand des übergeordneten Systems: Embedded-Geräte sind in der Regel in ein größeres System eingebettet. Im Allgemeinen kann davon ausgegangen werden, dass das Subsystem zwar eigenständig arbeiten kann, aber dennoch die Konfiguration oder den Betriebszustand des übergeordneten Systems kennt. Ein unerwarteter Neustart könnte das Subsystem unvorbereitet und ohne Kontext treffen. Daher ist es entscheidend, den Zustand des übergeordneten Systems zu speichern, damit das Subsystem nach einem Neustart direkt einsatzbereit ist.
• Zustand des Subsystems: Dieser umfasst den aktuellen Betriebsmodus, den Fortschritt bei langlaufenden Algorithmen sowie spezifische Flags, die angeben, ob das vorherige Herunterfahren ordnungsgemäß erfolgte oder auf einen Stromausfall zurückzuführen war. Dazu gehören Zähler für die Gesamtlaufzeit, Fehlerprotokolle aus früheren Sitzungen und Kalibrierungskoeffizienten, die sicherstellen, dass das Gerät unmittelbar nach dem Aufwachen innerhalb definierter Toleranzen arbeitet.
• Geräteidentifikation: Gerätespezifische Kennungen oder Sicherheitsschlüssel, die vom Supersystem bereitgestellt wurden, müssen nicht erneut übertragen werden. Da die Neustartzeiten von STM32-basierten Embedded-Geräten beträchtlich kurz sind, sollten deren Neustarts den Betrieb des Supersystems nicht beeinträchtigen.
• Thread-Nutzung: RTOS-bezogene Merkmale können zur späteren Analyse gespeichert werden und sollten generell im Falle von Ausfällen im Feld für die Ursachenanalyse aufbewahrt werden.

Stromversorgung der Backup-Domäne

Um sicherzustellen, dass diese Daten auch dann erhalten bleiben, wenn die Hauptspannung (Vdd) wegfällt, nutzt der STM32 den Vbat-Pin zur Stromversorgung der Backup-Domäne.

1. Geplante Abschaltung: Systeme, bei denen Neustartroutinen in die Software integriert sind, benötigen in der Regel keine zusätzliche Stromversorgung. Die Abschaltroutine muss lediglich eine zusätzliche Verzögerung einbauen, damit die Backup-Register vor dem Neustart beschrieben werden. Dies ist nur bei Soft-Resets sinnvoll.
2. Kondensatoren zur Datenspeicherung bei Neustarts: Bei Systemen, die nur kurze Stromunterbrechungen (Sekunden bis Tage) überstehen müssen, kann ein Superkondensator an den Pin angeschlossen werden. Diese laden sich über eine einfache Widerstands- und Diodenschaltung schnell auf und können die RTC und die Backup-Register während vorübergehender Ausfälle mit Strom versorgen.
3. Batterien zur Datenspeicherung: Für eine zuverlässige Datenspeicherung über Jahre hinweg sind Lithium-Knopfzellen (wie die CR2032) die Standardwahl. Die MCU verfügt über einen internen Stromschalter, der den Backup-Bereich automatisch auf Batteriestrom umschaltet, sobald die Netzspannung ausfällt, und so eine kontinuierliche Datenspeicherung ohne manuelles Eingreifen gewährleistet.
4. Flash-Speicher für zuverlässige/permanente Speicherung: Backup-Register sind zwar praktisch, aber dennoch flüchtig in dem Sinne, dass sie die Versorgungsspannung Vdd benötigen, um aktiv zu bleiben. Für geschäftskritische Daten, die auch bei Ausfall der Pufferbatterie erhalten bleiben müssen, sollte der interne Flash-Speicher verwendet werden. Obwohl Flash-Speicher eine begrenzte Anzahl von Schreibzyklen und einen langsameren Zugriff als Register aufweist, bietet er einen wirklich dauerhaften Speicher. Der Hauptnachteil dieses Ansatzes ist eine aufwendige alternative Stromversorgungsschaltung, die darauf ausgelegt ist, die Anforderungen für den Betrieb des FRAM zu erfüllen.

Software-Implementierung

Die Implementierung eines Snapshots in der Software erfordert die Berücksichtigung der mehrschichtigen Schutzmechanismen des STM32.

1. Entsperren der Domäne: Standardmäßig ist die Backup-Domäne schreibgeschützt, um parasitäre Schreibvorgänge während des Hochfahrens oder eines Resets zu verhindern. Um Zugriff zu erhalten, muss man zunächst den Takt der Power-Schnittstelle (PWR) aktivieren und das Bit „Disable Backup Domain Protection“ im PWR_CR-Register setzen.
2. Schreiben des Snapshots: Bei Verwendung der standardmäßigen 128 Byte an Backup-Registern können Sie die STM32-Hardware-Abstraktionsschicht (HAL) nutzen. Der Vorgang umfasst:
   • Aufruf von HAL_PWR_EnableBkUpAccess(), um Änderungen zu ermöglichen.
   • Verwenden von HAL_RTCEx_BKUPWrite(&hrtc, RTC_BKP_DRx, Data), um Ihre 32-Bit-Snapshot-Werte in einem bestimmten Register zu speichern.
   • Nach dem Schreiben die Domäne erneut schützen, um die Datenintegrität sicherzustellen.
3. Verwendung des Backup-SRAM: Für größere Snapshots (typischerweise bis zu 4 KB) kann das Backup-SRAM verwendet werden. Dies erfordert eine etwas andere Abfolge:
   • Aktivieren des Backup-SRAM-Takt im Register RCC_AHB1ENR.
   • Aktivieren des Backup-Regler über LL_PWR_EnableBkUpRegulator() und Warten auf das BRR-Flag (Ready).
   • Nach der Initialisierung kann auf das Backup-SRAM über direkte Zeigermanipulation an der Adresse BKPSRAM_BASE zugegriffen werden.
     Hinweis: Wenn das System physische Manipulationen an bestimmten Pins feststellt, werden diese Backup-Register automatisch gelöscht, um sensible Snapshot-Daten zu schützen.

SRAM als Backup

Die Verwendung von Backup-SRAM bietet gegenüber herkömmlichen Backup-Registern zur Speicherung von Systemdaten mehrere wesentliche Vorteile, die vor allem die Kapazität, das Reset-Verhalten und die Sicherheitshandhabung betreffen.
Deutlich größere Speicherkapazität
Der unmittelbarste Vorteil ist die Menge an Daten, die gespeichert werden kann.

• Backup-Register: Bieten in der Regel nur 128 Byte Speicherplatz, aufgeteilt auf zweiunddreißig 32-Bit-Register.
• Backup-SRAM: Bietet eine wesentlich größere Kapazität, meist 4 KB. Dadurch eignet es sich für komplexere System-Snapshots wie Kalibrierungstabellen oder umfangreichere Fehlerprotokolle und kann bei konstanter Backup-Stromversorgung ähnlich wie ein internes EEPROM fungieren.

Verbesserte Persistenz und Reset-Resilienz
Backup-SRAM ist gegenüber bestimmten Arten von System-Resets widerstandsfähiger als die Backup-Register.

• Backup-Domain-Resets: Ein Backup-Domain-Reset setzt alle RTC-Backup-Register auf ihre Reset-Werte zurück. Das Backup-SRAM ist von diesem Reset jedoch nicht betroffen.
• Löschmethode: Die einzige Möglichkeit, das Backup-SRAM zu löschen, besteht über die Flash-Schnittstelle, indem die Leseschutzstufe (RDP) von 1 auf 0 geändert wird.

Flexibler Datenzugriff
Während Backup-Register häufig auf 32-Bit-Wortzugriffe beschränkt sind, bietet das Backup-SRAM eine feinere Flexibilität.

• Zugriffsmodi: Das Backup-SRAM kann im 32-Bit-, 16-Bit- oder 8-Bit-Modus adressiert werden, was je nach dem zu speichernden Datentyp eine effizientere Speichernutzung ermöglicht.

Differenzierte Sicherheitsbehandlung (Manipulationsereignisse)
Die beiden Speicherbereiche reagieren unterschiedlich auf physische Sicherheitsverletzungen, die von den Manipulationspins der MCU erkannt werden.

• Backup-Register: Diese werden zum Schutz sensibler Daten automatisch gelöscht, sobald ein Manipulationsereignis erkannt wird.
• Backup-SRAM: Es wird bei einem Manipulationsereignis nicht massenweise gelöscht. Stattdessen sperrt das System jeglichen Lesezugriff auf das SRAM, um zu verhindern, dass vertrauliche Informationen (wie kryptografische private Schlüssel) kompromittiert werden, während die Daten technisch weiterhin erhalten bleiben.

Anwendungsfall: Debugging von Backups

Ein entscheidender Anwendungsfall für die Nutzung der Backup-Domäne ist die Post-Mortem-Analyse eines durch einen Watchdog-Timer (IWDG oder WWDG) ausgelösten Systemabsturzes. In komplexen eingebetteten Systemen ist ein Watchdog-Reset oft das letzte Sicherheitsnetz für Software, die in eine Endlosschleife oder einen Deadlock-Zustand geraten ist.

Warum versagt herkömmliches Debugging?

Standardmäßige Debugging-Techniken sind im Allgemeinen aus mehreren Gründen unwirksam, um die Grundursache eines durch den Watchdog ausgelösten Resets zu ermitteln:

• Destruktiver Reset: Ein Watchdog-Ereignis löst einen System-Reset aus, wodurch fast alle flüchtigen Register und der standardmäßige interne SRAM (SRAM1, SRAM2) auf ihre Reset-Werte zurückgesetzt werden. Dadurch wird die Information über den Ursprungsort des Ereignisses effektiv ausgelöscht, wodurch der Aufrufstapel und lokale Variablen zerstört werden, die erklären würden, warum das System hängen geblieben ist.
• Verlust der Debugger-Synchronisation: Wenn ein Hardware-Reset auftritt, verliert der Debugger (JTAG/SWD) in der Regel seine Verbindung oder Synchronisation mit dem aktuellen Ausführungskontext des Kerns. Selbst wenn die Verbindung aufrechterhalten bleibt, startet der Kern vom Reset-Vektor aus neu, was es unmöglich macht, zu den Anweisungen unmittelbar vor dem Reset zurückzuspulen.
• Echtzeit-Einschränkungen: Viele Watchdog-Probleme treten nur unter bestimmten Echtzeitbedingungen auf, die sich bei angeschlossenem Debugger nur schwer reproduzieren lassen, da der Debugger selbst das Timing verändert und Watchdogs manchmal sogar einfrieren kann, wodurch der Fehler verschleiert wird.

Die Lösung: Backup-Debugging

Da die Backup-Domäne (einschließlich RTC-Register und Backup-SRAM) von einem System-Reset nicht betroffen ist, dient sie als einziger zuverlässiger Ort, um einen Snapshot des Systemzustands vor dem Auslösen des Watchdogs zu speichern.

1. Erfassen des Snapshots (vor dem Reset)
   Bei Verwendung des System Window Watchdog (WWDG) kann das System so konfiguriert werden, dass es unmittelbar vor dem Reset einen Interrupt auslöst. Während dieses letzten Gasp-Interrupts kann die Software wichtige Thread-Informationen schnell im 4-KB-Backup-SRAM speichern:
   • Thread-ID: Um zu identifizieren, welche Aufgabe gerade ausgeführt wurde.
   • Programmzähler (PC): Um genau zu sehen, an welcher Stelle der Code hängen geblieben ist.
   • Systemstatus-Flags: Wie beispielsweise der Status von Mutexen oder DMA-Puffern, die möglicherweise ein Deadlock verursachen.
2. Ermittlung der Ursache (nach dem Reset)
   Beim Neustart muss das System das RCC-Takt- und Statusregister (RCC_CSR) auf Reset-Flags überprüfen.
   • Ist das IWDGRSTF (Independent Watchdog Reset Flag) oder das WWDGRSTF (Window Watchdog Reset Flag) gesetzt, weiß die Firmware, dass die vorherige Sitzung mit einem Absturz endete.
   • Die Software greift dann nach Aktivierung des Power-Interface-Taktes und des Bits „Disable Backup Domain Protection“ (DBP) auf das Backup-SRAM zu, um den gespeicherten Snapshot auszulesen.

Dieser Ansatz des Backup-Debugging ermöglicht es Entwicklern, Felddaten von Abstürzen zu erfassen, die andernfalls nicht diagnostiziert werden könnten, und verwandelt so einen mysteriösen Hardware-Reset in ein dokumentiertes Software-Ereignis.

Autor

Atharva Anil Gabhe