Wie verhindert man "partielle Schreib" Daten Korruption während des Stromausfalls?

Question

In einer eingebetteten Umgebung (mit MSP430) habe ich einige Datenfehler durch partielle Schreibvorgänge in nichtflüchtigen Speicher festgestellt. Dies scheint durch einen Stromausfall während eines Schreibvorgangs verursacht zu werden (entweder zu FRAM- oder zu Informationssegmenten).

Ich validiere Daten, die an diesen Orten mit einem CRC gespeichert sind.

Meine Frage ist, was ist der richtige Weg, um diese "teilweise schreiben" Korruption zu verhindern? Derzeit habe ich meinen Code so geändert, dass er in zwei separate FRAM-Speicherorte geschrieben wird. Wenn also eine Schreiboperation unterbrochen wird, die eine ungültige CRC verursacht, sollte die andere Stelle gültig bleiben. Ist das eine gängige Praxis? Muss ich dieses doppelte Schreibverhalten für jeden nichtflüchtigen Speicher implementieren?

Answer 1

Eine einfache Lösung besteht darin, zwei Versionen der Daten (in separaten Seiten für Flash-Speicher), die aktuelle Version und die vorherige Version zu pflegen. Jede Version hat einen Header, bestehend aus einer Sequenznummer und ein Wort, das die Sequenznummer validiert - einfach das Komplement 1 der Sequenznummer zum Beispiel:

--------- 
| seq | 
--------- 
| ~seq | 
--------- 
|  | 
| data | 
|  | 
--------- 

Entscheidend ist, dass, wenn die Daten geschrieben werden die seq und ~seq Wörter werden geschrieben zuletzt.

Bei Inbetriebnahme Sie lesen die Daten, die die höchste gültige Folge Nummer (Bilanzierung von Umgriff vielleicht - vor allem für kurze Sequenz Wörter) hat. Wenn Sie die Daten schreiben, überschreiben und validieren Sie den ältesten Block.

Die Lösung, die Sie bereits verwenden, ist so lange gültig, wie der CRC zuletzt geschrieben wurde, aber es ist nicht einfach und erzwingt einen CRC-Berechnungsaufwand, der möglicherweise nicht notwendig oder wünschenswert ist.

Auf FRAM haben Sie keine Sorgen über die Ausdauer, aber das ist ein Problem für Flash-Speicher und EEPROM.In diesem Fall verwende ich eine Rückschreib-Cache-Methode, bei der die Daten im RAM gehalten werden, und wenn ein Timer gestartet oder neu gestartet wird, wenn er bereits läuft - wenn der Timer abläuft, werden die Daten geschrieben - dies verhindert Burst-Schreibvorgänge Sie können den Speicher nicht überlasten und sind sogar bei FRAM nützlich, da sie den Software-Overhead von Datenschreibvorgängen minimiert.

Answer 2

Unser technisches Team verfolgt einen zweigleisigen Ansatz: Lösen Sie es in Hardware und Software!

Die erste ist eine Dioden- und Kondensatoranordnung, die während eines Brownouts einige Millisekunden Leistung liefert. Wenn wir bemerken, dass wir externe Energie verloren haben, verhindern wir, dass der Code in nicht-verletzende Schreibvorgänge eintritt. Zweitens sind unsere Daten besonders kritisch für den Betrieb, sie werden oft aktualisiert, und wir wollen unseren nicht-störungsfreien Flash-Speicher nicht ausnutzen (er unterstützt nur so viele Schreibvorgänge), sodass wir die Daten tatsächlich 16-mal speichern Flash und schützen Sie jeden Datensatz mit einem CRC-Code. Beim Booten finden wir den neuesten gültigen Schreibvorgang und starten dann unsere Lösch-/Schreibzyklen.

Wir haben noch nie Daten Korruption seit der Umsetzung unserer offen paranoiden System gesehen.

Update:

Ich sollte anmerken, dass unsere Flash auf unsere CPU extern ist, so dass die CRC hilft, die Daten überprüft, ob es eine Kommunikations Glitch zwischen der CPU und Flash-Chip ist. Wenn mehrere Störungen gleichzeitig auftreten, schützen die Mehrfachschreibvorgänge vor Datenverlust.

Answer 3

Wir haben etwas verwendet, das Cliffords Antwort ähnlich ist, aber in einem Schreibvorgang geschrieben. Sie benötigen zwei Kopien der Daten und wechseln zwischen ihnen. Verwenden Sie eine fortlaufende Sequenznummer, so dass effektiv eine Position gerade Sequenznummern hat und eine ungerade ist.

Schreiben Sie die Daten wie folgt aus (in einem Schreibbefehl, wenn Sie können):

--------- 
| seq | 
--------- 
|  | 
| data | 
|  | 
--------- 
| seq | 
--------- 

Wenn Sie es wieder sicher machen lesen sowohl die Sequenznummern gleich sind - wenn sie nicht dann die Daten ungültig . Beim Start beide Orte lesen und herausfinden, welcher Punkt aktueller ist (unter Berücksichtigung der fortlaufenden Nummerierung).

Answer 4

Speichern Sie Daten immer in einer Art von Protokoll, wie START_BYTE, Gesamtanzahl der zu schreibenden Bytes, Daten, END BYTE. Bevor Sie zum externen/internen Speicher schreiben, überprüfen Sie immer die POWER Moniter Register/ADC. Wenn Ihre Daten korrumpieren, wird auch das END-Byte beschädigt. Dieser Eintrag wird nach der Validierung des gesamten Protokolls nicht gültig. Checksum ist keine gute Idee, Sie können CRC16 statt wählen, wenn Sie CRC in Ihr Protokoll aufnehmen möchten.