eeprom overflow

1

Estaba usando STM32f401RE, y almacené una serie de números en el AT24c512, las operaciones de lectura y escritura de EEPROM varias veces durante la implementación del código, aproximadamente 10,000 veces cada ejecución de código. Al principio, los números de EEPROM se leen correctamente y están escritos correctamente en él.

Pero cuando ese dispositivo permanecerá encendido durante aproximadamente 5 a 6 horas y el microcontrolador podrá escribir y leer los datos de la EEPROM para que no reciban los números correctos.

Por ejemplo, 500 deben escribirse en la EEPROM, pero el número que se lee de la EEPROM es 1,589,436. Que al apagar el dispositivo o al escribir los nuevos números no se emitirá correctamente. En tu opinión, ¿cuál es el problema? ¿Cómo soluciono esto?

    
pregunta Mehrshad

1 respuesta

4

Parece que estás desgastando la EEPROM. Todas estas celdas de memoria de puerta flotante tienen un número finito de veces que pueden escribirse y borrarse antes de que se dañen irreparablemente. Compruebe la hoja de datos. Debe proporcionar los valores mínimos de "vida útil" garantizados para las escrituras y borrados.

La mayoría de las EEPROM puras están calificadas para más de 10,000 operaciones de este tipo. Sin embargo, eso es lo que aparentemente hace su código cada vez . Y, especialmente durante el desarrollo y la depuración, es muy posible que algo se haya ejecutado en un bucle y haya realizado estas operaciones muchas veces.

Su EEPROM está tostada, hecha, desgastada. Si lo reemplazas con un nuevo chip y el problema desaparece (temporalmente), definitivamente eso es lo que sucedió.

En general, si necesita una actualización frecuente de datos no volátiles, necesita hacer algo más que simplemente conectar a ciegas una EEPROM. La primera estrategia es cambiar la arquitectura para que el estado no volátil no sea necesario actualizarlo con tanta frecuencia. Si eso es imposible, entonces vive con una vida limitada o usa una tecnología diferente.

Algo más a considerar es cómo exactamente el firmware está escribiendo en la EEPROM. Estas cosas generalmente tienen "páginas" que se borran o se escriben a la vez. A veces es posible escribir bytes individuales, pero aún así cuenta como un evento para toda la página.

Por lo tanto, el firmware debe ser inteligente acerca de cómo se realizan las escrituras. Normalmente creo rutinas de interfaz que permiten leer o escribir bytes individuales al azar. Sin embargo, debajo de ellos realmente cachean una página entera. Las escrituras no van a la EEPROM física hasta que se necesita una página diferente o hasta que se llama la rutina explícita FLUSH. A veces, la rutina FLUSH es llamada automáticamente por un temporizador.

Sin embargo, en todos los casos no hace una escritura física cuando no se cambia ningún valor. Mantengo un bit "sucio" que indica si la página almacenada en caché se ha cambiado desde que se leyó desde la EEPROM. Cuando se va a una página diferente, no se realiza la escritura si el caché actual no está sucio. También hay lógica para verificar si las escrituras de bytes individuales no cambian el valor almacenado en caché. En ese caso, la bandera sucia no está establecida.

Las rutinas de acceso a EEPROM de bajo nivel adecuadas pueden ayudar, pero la aplicación también debe tener en cuenta las limitaciones de la memoria no volátil. Debería intentar evitar, por ejemplo, saltar por todo el espacio de direcciones escribiendo pequeños números de bytes. Si tiene que hacer una escritura grande, tenga cuidado de hacerlo secuencialmente.

Por supuesto, simplemente no puede escribir un nuevo valor cada segundo, por ejemplo, y esperar que un dispositivo con una vida útil de 100,000 escrituras dure más de 28 horas. Incluso un dispositivo con una vida útil de escritura de 1,000,000 ni siquiera duraría 12 días en este caso.

    
respondido por el Olin Lathrop

Lea otras preguntas en las etiquetas