corrupción de memoria flash AVR

Navega tus respuestas
11

Esta pregunta está relacionada con desprogramación AVR en sí misma .

Información del proyecto:
Tenemos un producto alimentado por batería utilizando 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 cuenta con un cargador de arranque bastante simple que se está comunicando a través de UART (utilizando la interfaz RS232 IC). Simplemente sirve como un método conveniente para actualizar el firmware de modo que no se requiera ningún programador ISP de hardware. (El gestor de arranque espera telegramas asegurados de suma de comprobación)

Los dispositivos se diseñaron con un apagón interno DESACTIVADO porque duplica el consumo de energía y la duración de la batería es obligatoria (supongo que se debería haber utilizado una detección de apagones externos; el rediseño está en funcionamiento). / p>

Problema:
Cada pocos meses, un dispositivo deja de funcionar, NO se realizaron actualizaciones de firmware en esos dispositivos. Sin embargo, tras un examen más detenido, los contenidos flash de esos dispositivos parecen estar dañados. Además, las baterías de algunos de esos dispositivos aún eran buenas, pero no quiero descartar algún tipo de situación de bajo voltaje.

Esta es una comparación del contenido original de flash (izquierda) con el contenido dañado (derecha):

Algunasobservaciones:

  • Unbloquedañadosiempreconstadealmenosunapáginaflash(256bytes)yestáalineadaconlapágina.Enotraspalabras:soloseafectanlaspáginascompletas,nolosbytesindividuales.
  • Elcontenidodañadolee0xFFlamayorpartedeltiempo,perotambiénpuedecontenerotrosvaloresosercompletamente"aleatorio".
  • La barra pequeña en el lado izquierdo de la imagen muestra todas las áreas afectadas. Para este dispositivo, es aproximadamente una décima parte del contenido total de flash.
  • Tuvimos un dispositivo en el que solo una página se vio afectada.

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

Tal vez el controlador se reinicie aleatoriamente debido a la falta de voltaje y el código del cargador de arranque esté actuando de manera impredecible durante este tiempo. Para citar a alguien de otro foro en relación con el bajo voltaje:

  

"No solo se trata de instrucciones aleatorias de flash que se ejecutan, sino de períodos de instrucciones aleatorias (no hay garantía de que el código de flash se lea y se interprete correctamente). Junto con esto, otras partes del mcu pueden no comportarse como diseñado, incluyendo mecanismos de protección ".

Preguntas:
¿Cree que el "comportamiento aleatorio durante el voltaje bajo 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 como causa de algunos problemas de software (desbordamiento de pila, punteros no válidos)?

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

    
pregunta Rev1.0

4 respuestas

11

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

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

Es posible que le interese la sección 23.8.1 (Cómo evitar la corrupción de flash). ):

  

Una corrupción del 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 propia CPU puede ejecutar las instrucciones incorrectamente, si la tensión de alimentación para ejecutar las instrucciones es demasiado baja.   La corrupción repentina 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.   
  2. Mantenga el RESTABLECIMIENTO AVR activo (bajo) durante los períodos de voltaje de alimentación insuficiente.
      Esto se puede hacer habilitando el Detector de reducción de tensión (BOD) interno si el voltaje de operación coincide con el nivel de detección. De lo contrario, se puede usar un circuito externo de protección de restablecimiento bajo de VCC. Si se produce un restablecimiento mientras se está realizando una operación de escritura, la operación de escritura se completará siempre que la tensión de alimentación sea suficiente.
    3.   
  3. Mantenga el núcleo del AVR en modo de suspensión de apagado durante los períodos de baja VCC. Esto evitará que la CPU intente descodificar y ejecutar instrucciones, protegiendo efectivamente el registro SPMCSR y, por lo tanto, Flash de escrituras no intencionales.
    4.   
    
respondido por el Jacen
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 más sencilla es habilitar la protección contra la caída de tensión.

Siempre debe habilitar la protección contra caídas de tensión en los microcontroladores como una cuestión de rutina.

    
respondido por el user
3

La baja tensión es una causa muy probable. Por ejemplo, una vez tuve un proyecto en el que un nivel de reducción de tensión de 1.8 V causaba con frecuencia corrupción, y estas corrupciones nunca podrían reproducirse con un nivel de reducción de tensión de 3.5V.

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

    
respondido por el vsz
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 de mi propia experiencia: - Bloqueo de los capacitores en cualquier IC, independientemente de lo que los fabricantes le informen en sus hojas de datos sobre esquemas infernales, coloque al menos uno entre 100pF - 1nF en las líneas eléctricas de cada IC - conducir las áreas de tierra en la capa de cada PCB tanto como sea posible. Estas áreas deben contactarse a través de todas las capas a través de vías con la mayor frecuencia posible, una cuadrícula de 50mil es un buen valor. Conecte esas áreas a la señal de tierra. - Nunca deje cobre desconectado (flotante, sin señal conectada) en su PCB. Actúa como una antena y, de forma divina, coloca radiación electromagnética en los dispositivos. - haga trazas que lleven las señales de reloj lo más cortas posible

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

    
respondido por el woodz

Lea otras preguntas en las etiquetas

¿Cómo se comunica una GPU / CPU con una salida de pantalla estándar? (HDMI / DVI / etc) [cerrado] ¿Se cortocircuitará una batería cuando los terminales estén directamente conectados entre sí o la resistencia interna lo salvará?