Corrupción de la memoria flash AVR

Esta pregunta está relacionada con la desprogramación del AVR .

Información del proyecto:
tenemos un producto alimentado por batería que utiliza un ATMEGA644P. La aplicación se ejecuta permanentemente en modo de suspensión y solo se activa una vez por segundo (RTC) o cuando se activa una de las dos líneas de interrupción externas.

El dispositivo presenta un cargador de arranque bastante simple que se comunica a través de UART (usando IC de interfaz RS232). Solo sirve como un método conveniente para actualizar el firmware para que no se requiera un programador ISP de hardware. (El gestor de arranque espera telegramas seguros de suma de comprobación)

Los dispositivos se diseñaron con la caída de tensión interna DESACTIVADA porque duplica el consumo de energía y es obligatoria una batería de larga duración (supongo que se debería haber utilizado una detección de caída de tensión externa; se está trabajando en un rediseño).

Problema:
cada pocos meses, un dispositivo simplemente deja de funcionar, NO se realizaron actualizaciones de firmware en esos dispositivos. Sin embargo, después de un examen más detallado, el contenido flash de esos dispositivos parece estar dañado. Además, las baterías de algunos de esos dispositivos aún estaban buenas, pero no quiero descartar algún tipo de situación de bajo voltaje.

Esta es una comparación del contenido flash original (izquierda) con el contenido corrupto (derecha):

Comparación de destellos

Algunas observaciones:

  • Un bloque dañado siempre consta de al menos una página flash (256 bytes) y está alineado con la página. En otras palabras: solo se ven afectadas páginas completas, no bytes individuales.
  • El contenido dañado lee 0xFF la mayor parte del tiempo, pero también puede contener otros valores o ser completamente "aleatorios".
  • La pequeña barra en el lado izquierdo de la imagen muestra todas las áreas afectadas. Para este dispositivo, es aproximadamente una décima parte del contenido flash total.
  • Teníamos un dispositivo en el que solo se vio afectada una página.

Es totalmente plausible que una condición de bajo voltaje mientras se escribe la memoria flash pueda dañar el contenido de la memoria flash. Sin embargo, esto significaría que se deben ejecutar algunas instrucciones sensibles al flash.

Tal vez el controlador se reinicia aleatoriamente debido a un bajo voltaje y el código del cargador de arranque actúa de manera completamente impredecible durante este tiempo. Para citar a un tipo de otro foro sobre bajo voltaje:

"No solo se ejecutan instrucciones aleatorias de flash, sino también un período de instrucciones aleatorias (no hay garantía de que el código de flash se lea e interprete correctamente). Junto con esto, es posible que otras partes de la mcu no se comporten según lo diseñado, incluida la protección mecanismos".

Pregunta(s):
¿Cree que la explicación del "comportamiento aleatorio durante el bajo voltaje y la ejecución de algunas instrucciones que cambian los datos en las páginas flash" es sólida? Si ese es el caso, ¿por qué no vemos este tipo de errores todo el tiempo solo como causa de algunos problemas de software (desbordamiento de pila, punteros no válidos)?

¿Tiene alguna otra idea de qué podría causar este tipo de corrupción? ¿Podría ser causado por EMI/ESD?

En el segundo bloque de su ejemplo, ¿pasó algún bit de 1->0 o todas las transiciones 0->1? Tengo un script que calcula esto, pero no voy a escribir todos los números de tu captura de pantalla.
@markrages: al mirarlo, 0-> 1 solo. Una respuesta también señaló que parece un borrado parcial en el que no todos los bits se cambiaron a 1. Gracias por la observación.

Respuestas (4)

Debes notar que el flash no se escribe, se borra. Un flash borrado está lleno de 0xFF. Sus primeros 256 bytes se borran por completo, su tercera región de 256 bytes se borra parcialmente (solo tiene 0 a 1 cambios de bits de datos correctos a datos corruptos).

De acuerdo con la hoja de datos , este flash es borrable por página (normalmente trabajo con bloques de borrado más grandes que las páginas). Como se ve en la página 282, Borrar página con SPM es bastante fácil.

Puede que le interese la sección 23.8.1 (Prevención de la corrupción de Flash):

La corrupción de un programa Flash puede ser causada por dos situaciones cuando el voltaje es demasiado bajo. Primero, una secuencia de escritura regular en Flash requiere un voltaje mínimo para funcionar correctamente. En segundo lugar, la propia CPU puede ejecutar instrucciones incorrectamente si la tensión de alimentación para ejecutar instrucciones es demasiado baja. La corrupción de Flash se puede evitar fácilmente siguiendo estas recomendaciones de diseño (una es suficiente):

  1. Si no hay necesidad de una actualización del cargador de arranque en el sistema, programe los bits de bloqueo del cargador de arranque para evitar cualquier actualización del software del cargador de arranque.
  2. Mantenga el AVR RESET activo (bajo) durante períodos de tensión de alimentación insuficiente.
    Esto se puede hacer habilitando el detector de caída de tensión interno (BOD) si el voltaje operativo coincide con el nivel de detección. De lo contrario, se puede usar un circuito externo de protección de restablecimiento de bajo VCC. Si se produce un restablecimiento mientras se está realizando una operación de escritura, la operación de escritura se completará siempre que el voltaje de la fuente de alimentación sea suficiente.
  3. Mantenga el núcleo AVR en modo de suspensión de apagado durante los períodos de bajo VCC. Esto evitará que la CPU intente decodificar y ejecutar instrucciones, protegiendo efectivamente el registro SPMCSR y, por lo tanto, la memoria flash de escrituras no intencionales.
Su observación sobre el borrado parcial en la tercera página parece plausible. Con respecto al texto de Atmel: Todos estamos de acuerdo en que el BOD parece ser obligatorio. Pero todavía no estoy seguro de la causa EXACTA de la corrupción. ¿No es bastante improbable que el controlador simplemente ejecute (debido al bajo voltaje) esta instrucción específica para borrar una página flash? Quiero decir, esto incluso tendría que suceder durante la ejecución del código del cargador de arranque, ya que solo se puede escribir en flash desde allí. Y requiere una secuencia específica.
No es posible explicar la fuente exacta de la corrupción: a medida que cae su Vcc, se vuelve demasiado bajo para saturar completamente un transistor con otro. Una MCU es básicamente una ecuación lógica muy grande. Si sus transistores dejan de comportarse como interruptores lógicos, cambia esta ecuación. Como el primer transistor en comportarse mal depende del dopaje de la oblea ASIC y de las perturbaciones electromagnéticas externas, no se puede predecir lo que sucederá. Para abordar este problema, cuando diseñe su ASIC, puede agregar una parte analógica que apague la parte digital antes de comportarse mal. Pero aumenta todo el costo de ASIC.
Es confuso que la nota de aplicación AVR180 External Brown-out Protection indique: "Tenga en cuenta que el contenido de la memoria de programa Flash interna de AVR® nunca se ve afectado por un voltaje de suministro de energía insuficiente". Además: "Como la CPU AVR no es capaz de escribir en su propia memoria de programa, el contenido de la memoria interna del programa Flash nunca se ve afectado por una situación de corte de energía". - En mi opinión, Atmel simplemente está ignorando que hay algo así como cargadores de arranque que TIENE que cambiar la memoria flash.
@Rev1.0 Bueno, sí, es bastante improbable... es por eso que solo lo ves en un dispositivo cada pocos meses, en lugar de en todos los dispositivos todo el tiempo.
"Quiero decir, esto incluso tendría que suceder durante la ejecución del código del cargador de arranque, ya que solo se puede escribir en flash desde allí". - ¡Eso solo es cierto si los bits de bloqueo de arranque ( BLB01y amigos) están configurados correctamente! ¿Son ellos? "Confuso... nota de aplicación..." - Las notas de aplicación son notoriamente poco fiables. Úselos solo como inspiración; para garantías, confíe en las hojas de datos (que tampoco son infalibles, pero bueno).

Este es un problema bien conocido y afecta a muchos microcontroladores (no solo a Atmel). El hardware de control de la memoria flash corrompe o borra parte de la memoria en condiciones de bajo voltaje. La solución simple es habilitar la protección contra caídas.

Siempre debe habilitar la protección contra caídas en los microcontroladores como algo natural.

¿Tiene alguna referencia sólida sobre CÓMO y POR QUÉ "el hardware de control de memoria corrompe o borra parte de la memoria en condiciones de bajo voltaje"? Hay muchas discusiones en el foro sobre la corrupción de flash, pero casi nunca se reduce a algo sólido, por eso pregunté aquí.
¿Es un problema de bajo voltaje en el chip o está relacionado con la ejecución incorrecta/aleatoria del programa en la sección del cargador de arranque que AFAIK solo puede modificar FLASH? Si el segundo es un problema, deshabilitar la ejecución del cargador de arranque a través de FUSE debería resolver el problema.
Recuerdo haber leído sobre ello en la fe de erratas de al menos un micro de MEGA.

La baja tensión es una causa muy probable. Por ejemplo, una vez tuve un proyecto en el que un nivel de caída de tensión de 1,8 V con frecuencia causaba daños, y estos daños nunca se podían reproducir con un nivel de caída de tensión de 3,5 V.

Tenga en cuenta que cuanto más rápido se ejecuta el procesador, más sensible es a los problemas de bajo voltaje. Si reducir la frecuencia de la CPU es una opción disponible para usted, podría valer la pena intentarlo.

Gracias por responder. Terminamos usando un detector externo de caídas de tensión de potencia ultrabaja y desde entonces no tuvimos problemas de corrupción.

EMC será su mayor enemigo, si no sigue las reglas principales del diseño de PCB. Estos son los más importantes según mi propia experiencia: - condensadores de bloqueo en cualquier IC, independientemente de lo que los fabricantes le digan en sus hojas de datos sobre esquemas infernales, coloque al menos uno entre 100pF - 1nF en las líneas de alimentación de cada IC - áreas de tierra conductoras en cada capa de PCB tanto como sea posible. Esas áreas se contactarán a través de todas las capas a través de vías tan a menudo como sea posible, una cuadrícula de 50 mil es un buen valor. Conecte esas áreas a la señal de tierra. - Nunca deje cobre sin conectar (flotante, sin señal conectada) en su PCB. Actúa como una antena y coloca radiación electromagnética en los dispositivos de manera devinitaria: haga que los rastros que transportan señales de reloj sean lo más cortos posible.

Encuentre más detalles por solicitudes de motores de búsqueda como "guía para el diseño de pcb de prueba de emc"

Corrupción de la memoria flash AVR
RespuestasAquíPolítica de privacidad1y, 0v