AVR corrupción de memoria flash

11

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

Información del proyecto:
Tenemos un producto con 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 la interfaz RS232 IC). Simplemente 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 una disminución de voltaje interna DESACTIVADA porque duplica el consumo de energía y la larga duración de la batería es obligatoria (supongo que se debería haber utilizado una detección externa de disminución de voltaje; un rediseño está funcionando).

Problema:
cada pocos meses un dispositivo 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 seguían siendo buenas, pero no quiero descartar algún tipo de situación de baja tensión.

Esta es una comparación de los contenidos flash originales (izquierda) con los contenidos corruptos (derecha):

Comparación flash

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 enteras, no bytes individuales.
El contenido dañado lee 0xFF la mayor parte del tiempo, pero también puede contener algunos otros valores o ser completamente "aleatorio".
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 total del flash.
Teníamos un dispositivo donde solo una página se veía afectada.

Es totalmente plausible que una condición de bajo voltaje al escribir la memoria flash pueda corromper el contenido 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 está actuando de manera completamente impredecible durante este tiempo. Para citar a un tipo de otro foro sobre subtensión:

"No solo se ejecutan instrucciones aleatorias de flash, sino un período de instrucciones aleatorias (no hay garantía de que el código de flash se leerá e interpretará correctamente). Junto con esto, otras partes del mcu pueden no comportarse según lo diseñado, incluida la protección mecanismos ".

Pregunta (s):
¿Crees que el "comportamiento aleatorio durante el bajo voltaje y la ejecución de algunas instrucciones que cambian los datos en páginas flash" - la explicación 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)?

¿Tienes alguna otra idea de lo que podría causar este tipo de corrupción? ¿Podría ser esto causado por EMI / ESD?

— Rev1.0
fuente

En el segundo bloque de su ejemplo, ¿alguno de los bits pasó de 1 a 0 o de todas las transiciones de 0 a 1? Tengo un script que calcula esto, pero no voy a escribir todos los números de tu captura de pantalla.

— markrages

@markrages: al mirarlo, solo 0-> 1. Una respuesta también señaló que parece un borrado parcial donde no todos los bits se volcaron a 1. Gracias por la observación.

— Rev1.0

11

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

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

Puede interesarle la sección 23.8.1 (Prevención de la corrupción instantánea):

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 el Flash requiere un voltaje mínimo para funcionar correctamente. En segundo lugar, la CPU misma puede ejecutar instrucciones incorrectamente, si el voltaje de suministro para ejecutar las instrucciones es demasiado bajo. La corrupción del flash se puede evitar fácilmente siguiendo estas recomendaciones de diseño (una es suficiente):

Si no hay necesidad de una actualización de Boot Loader en el sistema, programe los bits de bloqueo de Boot Loader para evitar actualizaciones de software de Boot Loader.

Mantenga el AVR RESET activo (bajo) durante los períodos de tensión de alimentación insuficiente.
Esto se puede hacer habilitando el Detector de reducción de voltaje interno (BOD) si el voltaje de operación coincide con el nivel de detección. De lo contrario, se puede utilizar un circuito externo de protección de restablecimiento de bajo VCC. Si se produce un reinicio mientras una operación de escritura está en progreso, la operación de escritura se completará siempre que el voltaje de la fuente de alimentación sea suficiente.

Mantenga el núcleo AVR en modo de suspensión de apagado durante períodos de bajo VCC. Esto evitará que la CPU intente decodificar y ejecutar instrucciones, protegiendo efectivamente el registro SPMCSR y, por lo tanto, el Flash de escrituras involuntarias.

— Jacen
fuente

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 la DBO parece ser obligatoria. 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 el flash solo se puede escribir desde allí. Y requiere una secuencia específica.

— Rev1.0

3

No es posible explicar la fuente exacta de la corrupción: a medida que su Vcc cae, 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, usted cambia esta ecuación. Como el primer transistor que se comporta mal depende del dopaje de la oblea ASIC y las perturbaciones electromagnéticas externas, no puede predecir lo que sucederá. Para solucionar este problema, cuando diseñe su ASIC, puede agregar una parte analógica que apague la parte digital antes de comportarse mal. Pero aumenta el costo total de ASIC.

— Jacen

Confundiendo que la nota de aplicación AVR180 Protección externa de apagón dice: "Tenga en cuenta que el contenido de la memoria interna del programa Flash AVR® nunca se ve afectado por un voltaje insuficiente de la fuente de alimentación". Además: "Como la CPU AVR no es capaz de escribir en su propia memoria de programa, el contenido interno de la memoria del Programa Flash nunca se ve afectado por una situación de falla de energía". - IMO Atmel simplemente ignora que hay algo como cargadores de arranque que TIENE QUE cambiar la memoria flash.

— Rev1.0

@ Rev1.0 Bueno, sí, es bastante improbable ... es por eso que solo lo ves en un dispositivo cada pocos meses, en lugar de todos los dispositivos todo el tiempo.

— user253751

"Quiero decir, esto incluso tendría que suceder durante la ejecución del código del cargador de arranque, ya que el flash solo se puede escribir 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 confiables. Úselos solo como inspiración; para garantías, confíe en las hojas de datos (que tampoco son infalibles, pero bueno).

— marcelm

4

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 de oscurecimiento.

Siempre debe habilitar la protección de oscurecimiento en los microcontroladores como algo natural.

— usuario
fuente

3

¿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 con respecto a la corrupción flash, pero casi nunca se reduce a algo sólido, por eso pregunté aquí.

— Rev1.0

¿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, la desactivación de la ejecución del cargador de arranque a través de FUSE debería resolver el problema.

— TMa

Recuerdo haber leído sobre esto en las erratas de al menos un micro MEGA.

— usuario

3

El bajo voltaje es una causa muy probable. Por ejemplo, una vez tuve un proyecto donde un nivel de caída de voltaje de 1.8 V frecuentemente causaba corrupción, y estas corrupciones nunca podrían reproducirse con un nivel de caída de voltaje de 3.5V.

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

— vsz
fuente

1

Gracias por responder. Terminamos usando un detector externo de baja potencia de baja potencia y no tuvimos problemas de corrupción desde entonces.

— Rev1.0

0

EMC será su mayor enemigo, si uno no sigue las reglas principales del diseño de PCB. Aquí están los más importantes desde mi propia experiencia: - bloquear los condensadores en cualquier CI, independientemente de lo que los fabricantes le digan en sus hojas de datos sobre esquemas infernales, coloque al menos uno entre 100 pF - 1 nF en las líneas de alimentación de cada CI - conduciendo áreas de tierra 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 rejilla de 50mil 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 devinitivamente coloca radiación electromagnética en los dispositivos: haga que las trazas que transportan las señales del reloj sean lo más cortas posible

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

— Woodz
fuente