AVR se desprograma a sí mismo

¿Alguien más ha tenido casos en los que un AVR dejó de funcionar misteriosamente después de varios meses, pero reprogramarlo lo traería de vuelta?

Estoy ejecutando un montón de atmega328 en la red de sensores inalámbricos. Ahora he tenido 3 veces (en aproximadamente un año) cuando una de ellas acaba de dejar de funcionar. Volveré a grabar el programa y comenzará a funcionar nuevamente. No siempre es la misma unidad, por lo que no parece que sea un chip defectuoso.

Parece que sería algo desastroso que evitaría que las personas usen AVR, por lo que obviamente es algo sobre mis circunstancias particulares. Me preguntaba si alguien más se ha topado con él y podría tener algunos consejos.

Estoy funcionando a 3.3V sin baterías, por lo que el voltaje caerá demasiado bajo para funcionar una vez cada dos meses y tengo que reemplazar las recargables. Los módulos usan el modo de suspensión y el temporizador de vigilancia para dormir durante 60 segundos, tomar una lectura, enviarlo por radio a la estación base y luego volver a dormir. Los módulos son compatibles con Arduino, por lo que no he cambiado el bit "no me permitas volver a grabar este".

¿Estás usando DBO? Ocasionalmente pueden ocurrir cosas desagradables si un chip se oscurece.

Probablemente la detección Brown-Out es la forma correcta de hacerlo, pero ...

Tuve un problema de software único que causó síntomas muy similares, aunque mucho más rápido. Creo que algunos C ++ malos (¿compilando?) Resultaron en corrupción de la pila, y la función regresó fuera del programa real, ejecutando instrucciones aleatorias. No estoy seguro de lo que sucedió a continuación, pero la única forma de solucionarlo fue volver a grabar el programa (aparentemente algunas de esas instrucciones aleatorias incluían escribir en la memoria del programa).

El error fue solo un destructor llamado en el momento equivocado. Hacer que la variable sea global (para que nunca se destruya) solucionó el problema. El problema era muy fácil de reproducir (tardó aproximadamente un minuto en activarse) y con una potencia muy estable. La configuración particular fue Arduino + WaveShield usando la biblioteca WaveHC, pero creo que esto podría pasarle a cualquiera que use C ++.

Si prefiere idiomas de bajo nivel, accidentalmente hice lo mismo en el ensamblaje, pero milagrosamente esto nunca causó más que problemas de sincronización esporádicos: la mayoría de las instrucciones son de 2 bytes de largo, pero algunas son más largas, calculé tontamente la distancia de salto y salté en medio de una instrucción de 4 bytes. Se realineó bastante rápido, pero no es difícil imaginar algo como esto en una ruta de código raramente utilizada que causa locura.

También he visto que los condensadores de desacoplamiento de Vcc insuficientes / mal ubicados / faltantes causan efectos similares. ¿Tiene desacoplamiento local lo más cerca posible del IC? (Se prefiere el tipo de cerámica 100nF - 1uF)

Otro factor que puede hacer que los dispositivos pierdan su memoria son las descargas electrostáticas (ESD).

Colocar algunos varistores en todos los conectores externos que están expuestos a la exposición puede aliviar este problema. Lo he visto antes en algunos productos comerciales basados ​​en microcontroladores PIC de Microchip, por lo que no es desconocido.

Hay algunos varistores útiles que también funcionan como condensadores de filtro (del orden de 10-150 pF). Echa un vistazo a estos http://www.tdk.co.jp/tefe02/e9c11_avr.pdf

Son pequeños, baratos y protegerán su dispositivo. Colóquelos lo más cerca posible de los conectores que traen señales externas a la placa y dirija todos los rastros inmediatamente lejos de los pines del conector.