¿Tendrá un chip SPI EEPROM los mismos problemas con las operaciones de escritura no atómicas que la EEPROM interna de un dsPIC? [duplicar]

Hace un tiempo tuve algunos problemas intermitentes con la EEPROM interna de un dsPIC. De vez en cuando, se encontraría algún valor en la EEPROM puesto a cero en el encendido. Rastreé el problema hasta que el chip perdió energía después del paso de borrado del ciclo de escritura, pero antes de que se completara la escritura. Se trataba del momento del apagado en relación con la ejecución del firmware, que era (en funcionamiento normal) aleatorio. Resolví esto agregando una sección de búfer a mi EEPROM, para asegurarme de que un ciclo de escritura incompleto pudiera completarse al restaurar la energía. Tuve que convertir las escrituras de EEPROM en una operación atómica.

(Para obtener más detalles, mi técnica de almacenamiento en búfer define un área de memoria persistente que consta de tres campos: dirección para escribir, datos para escribir y un indicador LISTO. Una "escritura" consta de cuatro pasos: escribir en el búfer, establecer LISTO , escribir desde el búfer, borrar el indicador READY. En el encendido, verifique el indicador READY. Si está configurado, ejecute lo que esté en el búfer. Esto funcionó bien en la EEPROM interna).

Ahora estoy usando un dsPIC diferente sin EEPROM interna, y estoy tratando de usar un chip EEPROM externo para almacenar datos persistentes. Me pregunto si debería tener preocupaciones similares. ¿Debería preocuparme de que mi chip EEPROM externo se apague a mitad de la escritura y pierda datos, y escriba una solución para esto en mi firmware como lo hice para la EEPROM interna? ¿O el propio chip garantiza operaciones de escritura atómica?

Misma pregunta, misma respuesta: el chip NO garantiza la finalización de las escrituras. Tendrás que lidiar con esto, de una forma u otra.
En general, debe proporcionar un enlace directo a la hoja de datos del dispositivo , no un enlace a la página del producto de algún distribuidor. Tenga en cuenta que este dispositivo es más de dos órdenes de magnitud más lento en escritura (6 ms frente a 40 us) que el dispositivo flash.
Mi otra pregunta es solo un duplicado si alguien puede leerlo y obtener la misma información que puede obtener de este. No es descabellado pensar que los chips flash y EEPROM pueden comportarse de manera diferente de esta manera.
¿Por qué pensaría que la respuesta podría ser diferente en relación con la EEPROM interna y la memoria flash externa? El problema fundamental es el mismo en los tres casos: se requiere una energía significativa para modificar el estado de estos dispositivos, y esta energía no se puede almacenar en el chip.
Flash borra en grandes sectores, EEPROM es byte-borrable. No me parecería irrazonable pensar que los diseñadores de la tecnología de borrado de bytes gastarían un par de bytes adicionales agregando un búfer para que pueda manejar un apagado asíncrono. Para flash, eso es obviamente mucho más caro, aunque solo sea por el tamaño del sector.

Respuestas (2)

El chip no puede garantizar escrituras atómicas: si se va la energía mientras está escribiendo (o borrando), no hay nada que pueda hacer al respecto.

Por supuesto, los diseñadores de chips podrían implementar algún tipo de almacén de retención (como lo ha hecho usted), pero eso agrega un costo que otros usuarios no querrán pagar. Además, ¿qué sucede si se corta la energía mientras se escribe en el búfer en lugar de la memoria "real"?

Si se corta la energía mientras escribe en el búfer, ha perdido lo que planeaba escribir, pero no ha perdido ninguno de los datos almacenados previamente. Esa es la principal preocupación: apagar entre borrar y escribir.
@StephenCollings: sí, es justo, eso funciona para muchas aplicaciones.

Para una recuperación confiable de los datos de la EEPROM, se pueden hacer varias cosas. Consideremos, por ejemplo, almacenar un valor de contador ocasional en el almacenamiento persistente de la EEPROM. Debe tener en cuenta tanto el problema de pérdida de energía que estamos discutiendo aquí como las características de resistencia de escritura de la EEPROM serial.

Está bien usar la EEPROM en un modo de lectura/escritura (dado que tiene tiempo para hacerlo) siempre y cuando se asegure de que la resistencia al desgaste de las celdas de memoria no se agotará en la longitud. de vida del producto. Como por ejemplo, he hecho diseños de productos con EEPROM externa como 93C46 conectada al microcontrolador a través de 3 pines de puerto. He usado ciertas ubicaciones en la EEPROM para acumular información como el conteo acumulado o el paso del tiempo total. Hice cálculos utilizando los números de resistencia para 93C46 y descubrí que si desea asegurarse de que un producto pueda durar 10 años, en promedio puede permitir que la ubicación de EEPROM se actualice una vez cada 10 minutos.

Con esto en mente, normalmente diseño mi software para que el microcontrolador mantenga el conteo actual o el acumulador de tiempo en la RAM local y luego una función de temporizador proporciona una actualización "una vez cada 10 minutos" para copiar las ubicaciones de la RAM en la EEPROM. Para muchas aplicaciones esta sencilla solución es más que adecuada ya que la pérdida ocasional de 10 minutos de acumulación no es especialmente crítica.

Sin embargo, si el mantenimiento del conteo necesita ser más crítico, puede hacer que el microcontrolador administre su propio apagado y fuerce una actualización final de las ubicaciones de EEPROM desde las ubicaciones de RAM justo antes de apagarse.

Y si se requiere un mantenimiento aún más crítico, puede hacer arreglos para tener una interrupción de falla de energía de advertencia temprana que permitirá que el software fuerce una actualización de la EEPROM justo antes de que el microcontrolador pierda su suministro de electrones.

Ahora hay un tema aún más importante a considerar en el uso de una EEPROM para mantener contadores no volátiles. Esto se relaciona con la forma en que administra el proceso de mantener un almacenamiento confiable de los acumuladores cuando se corta la energía justo cuando está en el proceso de escribir en la EEPROM. He abordado este problema a lo largo de los años, en muchos proyectos, de la siguiente manera:

Tomemos el chip 93C46 como ejemplo. Tiene ubicaciones de 16 bits. Por lo general, uso 2 ubicaciones y hago que mi acumulador sea de 24 bits y luego calculo un CRC de tipo XOR simple sobre estos tres bytes y lo conecto en el 4.º byte de los 32 bits del par de ubicaciones de EEPROM. Luego, cuando se escribe la EEPROM, el acumulador + CRC se escribe en la EEPROM en dos lugares diferentes. (Es decir, el acumulador se almacena de forma redundante en la EEPROM). También asegúrese de escribir su software para que la escritura de una copia del accumularor+CRC esté completamente escrita antes de que se inicie la otra. También es una buena idea interponer un retraso de algunos milisegundos entre el par de operaciones de escritura.

Luego, en el próximo encendido, cuando inicializo la copia basada en RAM de los acumuladores de EEPROM, uso el siguiente concepto. Leo la primera copia del acumulador+CRC de la EEPROM y compruebo el CRC. Si es correcto, uso el valor de lectura de los otros 24 bits como el valor para escribir en las ubicaciones de RAM. Si la verificación de la primera ubicación falla, voy a leer la segunda copia y la verifico. Si está bien, ese se convierte en el valor conectado a las ubicaciones de RAM. Si ambos han fallado, aplico un valor predeterminado al contador en RAM, como cero o conteo "completo". (El recuento "completo" se aplicaría a los casos en los que la ubicación de EEPROM se utiliza para realizar un seguimiento de cuántas veces quedan para permitir que suceda algo... [como cuántas cajas más se permiten antes de que el microcontrolador publique un mantenimiento solicitud... etc etc].