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):
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?
Respuestas:
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):
fuente
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).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.
fuente
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.
fuente
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"
fuente