¿La dirección 0 se considera una mala semilla que no debe utilizarse?
Se trata de cuál es la dirección cuando algo va mal en su sistema. Probablemente los dos casos más frecuentes de los que me preocuparía, pensando de esta manera, serían cuando las líneas de dirección son todas-0 (arriba) o todas-1 (abajo). No puedo proporcionarte un mecanismo específico en el caso de tu MCU, por supuesto. Y quizás esto se aplique más a casos en los que la EEPROM sea una parte externa que a uno en el que sea interna. Pero me viene a la cabeza como preocupación ciertamente en el caso de un bus externo. Así que supongo que también es por eso que el autor de ese comentario dijo lo que dijo.
(La misma idea se aplica también a las direcciones superior e inferior de cualquier disposición de página física para la EEPROM, si la hubiera. Así que también podría preocuparme de la parte superior e inferior de cada página, así como de la primera y la última página).
¿Cómo sería posible comprobar si está en medio de una escritura de escritura?
Un posible síntoma es que una escritura nunca termina. Esto podría deberse a algún problema de hardware (la MCU está sufriendo una caída de tensión no detectada y se comporta mal, por ejemplo) o podría deberse a que tu propio software se bloquea. U otras razones. En cualquier caso, conocer el tiempo de escritura en el peor de los casos, así como utilizar el temporizador de vigilancia (o un temporizador diferente) como medio para reiniciar la MCU o para llamar la atención sobre el problema, puede ayudar aquí. Nada es perfecto. Así que esto no es una panacea. Pero conocer tus tiempos de escritura y establecer un medio para detectar un fallo sólo sobre esta base puede ayudar.
Pero supongamos que el procesador se reinicia y usted vuelve sabiendo que algo ha ido mal. (Normalmente, hay una bandera que te dice que el watchdog causó un reinicio o bien puedes usar un vector especializado en SRAM que te dice este hecho). Sabes que puede haber un problema en la EEPROM.
O bien, puede que haya pasado por un ciclo completo, normal, de apagado y encendido, y que esté arrancando y encuentre un problema en la EEPROM.
¿Cómo se detecta que una escritura no se ha completado del todo? ¿Cómo encontrar secciones que no estaban bien escritas?
Pues bien, hay que aplicar una serie de técnicas:
- Proporcionar un método de detección de errores. Esto puede incluir una suma de comprobación, un CRC, una función hash como MD5 o SHA256, o una de las muchas opciones ECC; o una combinación de ellos. Si puedes permitirte la idea, yo recomendaría incluir dos métodos: una suma de comprobación que es muy sencilla de implementar y proporciona una primera prueba que, si tiene éxito, conduce a la segunda prueba: un CRC o ECC.
- Proporcionar un medio para la corrección de errores. Esto se puede conseguir utilizando ECC en cualquier nivel de corrección que se desee (1 bit, 2 bits o más). Pero otra forma de enfocar esto es la redundancia, proporcionando segmentos duplicados de los datos para que si uno falla en la prueba se pueda utilizar el otro (que luego se replica de nuevo para proporcionar redundancia de nuevo).
- No confíes en ubicaciones fijas. En su lugar, proporcione segmentos de datos que incluyan un TAMAÑO, un TIPO, un CHECKSUM y un componente ECC/CRC. Omite los que no se comprueban y sigue adelante, utilizando el campo TAMAÑO. Esto te permite recuperarte de los casos en los que un segmento es malo y no se puede confiar en él. Un problema aquí es que el propio campo SIZE puede ser defectuoso. Puedes mejorar esa situación proporcionando un ECC muy bueno en el propio campo TAMAÑO. Esta podría ser una solución. Sin embargo, hay otros.
- Incluir un esquema de nivelación del desgaste. Te recomendaría que echaras un vistazo a UBIFS en particular, ya que se ocupa de la memoria sin procesar y es de código abierto. Algunas de las ideas pueden ser aplicables incluso si no te molestas con la nivelación de desgaste, debido a los objetivos compartidos de integridad de los datos.
Yo no me molestaría en nivelar el desgaste, directamente. Pero te recomendaría que leyeras a fondo sobre las técnicas aplicadas en UBIFS para asegurarte de que no te pierdes ninguna buena idea allí. Una de las cosas buenas de su existencia es que puedes encontrar implementaciones exactas de varias ideas para que no tengas dudas sobre cómo implementar algo, si decides que quieres hacerlo, y tienes algo que puedes usar para validar tu propia codificación si queda alguna duda. No hay libro blanco que pueda hacer eso por ti.
Sin embargo, creo que deberías considerar la idea de no colocar las cosas en lugares fijos. Y te recomendaría que o bien consideraras la duplicación de datos o bien ECC decente, para que tengas una forma de recuperarte automáticamente de los errores más probables. Creo que necesitarás ECC para algunos elementos dentro de las estructuras, como el campo SIZE que he mencionado, porque ciertos tipos de errores a nivel de elemento pueden hacer imposible que funcione de forma fiable, después. Así que hay que identificar los fallos puntuales y cubrirlos con ECC, creo. Una vez solucionado, se puede construir sobre él con otras estructuras flexibles que se pueden omitir o utilizar, según se considere oportuno.
Suena como si tuvieras suficiente EEPROM para hacer un trabajo creíble en esto. Y nada de lo anterior debe tomarse como que no haces otras cosas como usar tu temporizador watchdog (u otros temporizadores) para proporcionar aún más capacidad para al menos detectar problemas, si no recuperarse completamente de ellos. Tendrás que pensar detenidamente en las funciones que ofrece tu MCU para ver cuáles de ellas pueden ayudarte, y cómo.
Si puede implicarse aún más, por supuesto. Podrías tener errores transitorios que afecten al contador del programa. (Esto es un problema más presente y continuo cuando se envían MCUs a la órbita o al espacio exterior). Además, los errores transitorios no sólo pueden afectar al PC, sino que pueden afectar momentáneamente al comportamiento de los módulos. Los fallos más persistentes pueden afectar a los módulos dentro de tu MCU y podrían dificultar su buen funcionamiento. Etc. Deja volar tu imaginación, si quieres. Hay muchas formas de que las cosas vayan mal.
