¿Cómo prevenir la corrupción de datos de" escritura parcial " durante la pérdida de energía?

Question

En un entorno integrado( usando MSP430), he visto algunos daños en los datos causados por escrituras parciales en la memoria no volátil.Esto parece deberse a una pérdida de energía durante una escritura (en segmentos FRAM o info).

Estoy validando los datos almacenados en estas ubicaciones con un CRC.

Mi pregunta es, ¿cuál es la forma correcta de evitar esta corrupción de "escritura parcial"?Actualmente, he modificado mi código para escribir en dos ubicaciones FRAM separadas.Por lo tanto, si se interrumpe una escritura provocando una CRC no válida, la otra ubicación debería seguir siendo válida.¿Es esta una práctica común?¿Necesito implementar este comportamiento de doble escritura para cualquier memoria no volátil?

Answer 1

Una solución simple es mantener dos versiones de los datos( en páginas separadas para memoria flash), la versión actual y la versión anterior.Cada versión tiene un encabezado que comprende un número de secuencia y una palabra que valida el número de secuencia, simplemente el complemento 1 del número de secuencia, por ejemplo:

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

Lo crítico es que cuando se escriben los datos, el seq y ~seq las palabras están escritas último.

En la puesta en marcha de usted leer los datos que tiene el secuencia válida más alta número (quizás teniendo en cuenta el resumen, especialmente para palabras de secuencia corta).Cuando escribe los datos, sobrescribe y valida el más antiguo bloquear.

La solución que ya está utilizando es válida siempre que el CRC se escriba en último lugar, pero carece de simplicidad e impone una sobrecarga de cálculo del CRC que puede no ser necesaria o deseable.

En FRAM, no le preocupa la resistencia, pero este es un problema para la memoria Flash y la EEPROM.En este caso, utilizo un método de caché de reescritura, donde los datos se mantienen en la RAM y, cuando se modifica, se inicia o reinicia un temporizador si ya se está ejecutando; cuando expira el temporizador, se escriben los datos; esto evita que las escrituras en ráfagas abarroten la memoria, y es útil incluso en FRAM, ya que minimiza la sobrecarga de software de las escrituras de datos.

Answer 2

Nuestro equipo de ingeniería requiere un enfoque de dos puntas para este problema: ¡Resuelve en hardware y software!

La primera es una disposición de diodos y condensadores para proporcionar algunos milisegundos de energía durante un marrón. Si notamos que hemos perdido la alimentación externa, evitamos que el código ingrese a cualquier escritura que no haya violado.

Segundo, nuestros datos son particularmente críticos para la operación, se actualiza a menudo y no queremos desgastar nuestro almacenamiento de flash no violado (solo admite tantas escrituras). Por lo tanto, en realidad almacenamos los datos 16 veces en Flash y proteger cada registro con un código CRC. En el arranque, encontramos la nueva escritura válida y luego inicie nuestros ciclos de borrado / escritura.

Nunca hemos visto la corrupción de datos ya que implementando nuestro sistema francamente paranoico.

Actualización:

Debería tener en cuenta que nuestro flash es externo a nuestra CPU, por lo que el CRC ayuda a validar los datos si hay un fallo de comunicación entre la CPU y el Flash Chip. Además, si experimentamos varias fallas seguidas, las múltiples escrituras protegen contra la pérdida de datos.

Answer 3

Hemos usado algo similar a la respuesta de Clifford, pero escrito en una operación de escritura.Necesita dos copias de los datos y suplentes entre ellos.Use un número de secuencia incrementable para que efectivamente una ubicación tenga un número de secuencia incluso y uno tiene impar.

Escriba los datos como este (en un comando de escritura si puede):

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

Cuando lo lee, asegúrese de que ambos números de secuencia sean los mismos, si no son, entonces los datos no son válidos.Al inicio, lea ambas ubicaciones y funciona cuál es más reciente (teniendo en cuenta el número de secuencia que se está rodando).

Answer 4

Siempre almacene datos en algún tipo de protocolo, como START_BYTE, bytes totales para escribir, datos, bytes finales. Antes de escribir a la memoria externa / interna, siempre revise los registros de Power Moniter / ADC. Si de alguna manera, se corrompe los datos, el byte final también se corrompe.Para que la entrada no va a Vaild después de la validación de todo el protocolo. La suma de comprobación no es una buena idea, puede elegir CRC16 en lugar de eso, si desea incluir CRC en su protocolo.