ATMEL 169PA se reinicia con MCUSR = 0

De vez en cuando me olvido de vincular el pin \ $ \ overline {\ text {RESET}} \ $ a Vcc, lo que da como resultado reinicios aleatorios. Utilice una resistencia de 10k si desea poder realizar la programación en el circuito, de lo contrario puede guardar la resistencia y atar el pin a Vcc directamente.

Según la Hoja de datos de ATmega169P , el registro MCUSR tiene los siguientes valores en el inicio:

  

• Bit 4 - JTRF: indicador de restablecimiento de JTAG Este bit se establece si se está reiniciando   causado por uno lógico en el registro de restablecimiento de JTAG seleccionado por el JTAG   instrucción AVR_RESET. Este bit se restablece mediante un reinicio de encendido, o por   escribiendo un cero lógico en la bandera.

     

• Bit 3 - WDRF: marca de restablecimiento de Watchdog Este bit se establece si un Watchdog   Se produce un reinicio. El bit se restablece mediante un reinicio de encendido, o escribiendo un   Lógica cero a la bandera.

     

• Bit 2 - BORF: Indicador de restablecimiento de salida de marrón Este bit se establece si se produce una salida de café   Se produce un reinicio. El bit se restablece mediante un reinicio de encendido, o escribiendo un   Lógica cero a la bandera.

     

• Bit 1 - EXTRF: Indicador de restablecimiento externo Este bit se establece si un Externo   Se produce un reinicio. El bit se restablece mediante un reinicio de encendido, o escribiendo un   Lógica cero a la bandera.

     

• Bit 0 - PORF: indicador de reinicio de encendido Este bit se establece si se enciende   Se produce un reinicio. El bit se restablece solo escribiendo un cero lógico en el   bandera.

En el caso de una falla de la fuente de alimentación, esperaría que el registro contuviera un valor de uno, o si el pin de reinicio externo no estuviera bien asegurado, esperaría un valor de dos. Si usted (o el compilador en cuestión) está utilizando la recomendación de leer y restablecer el registro de cerca después del inicio, sospecho que el microcontrolador no se está reiniciando en absoluto.

Una causa más probable es un error de código que hace que la ejecución del código vuelva al vector de restablecimiento o a un punto en el código que lo hace aparecer como si se hubiera producido un reinicio. El vector de reinicio se encuentra en la dirección del programa cero, por lo que cualquier salto a esa dirección puede causar ese problema, pero sin ver el código es difícil de determinar. Tal vez sea un caso de borde en la secuencia de código y / o secuencias de interrupción que tiende a ocurrir con poca frecuencia, o puede depender de los patrones de uso de los dispositivos que presentan el problema.

También según lo sugerido por Jippie dependiendo del compilador, la última instrucción después de main (); es un rjmp.-2 o un jmp 0x0000 por lo que si el programa logra dejar main (); entonces el controlador puede mostrar un comportamiento similar.

Responder su pregunta directamente requerirá mucha más información. ¿Cómo sabes que se está reiniciando? ¿Lo has borrado accidentalmente antes de que se lea?

De lo contrario, esto indicaría un Power-On-Reset donde el voltaje cae por debajo de VPOT (como se especifica en la hoja de datos). Huelo un problema de hardware en alguna parte.

[Editar] Dada la nueva información de que la unidad está siendo sometida a temperaturas muy frías. Es casi seguro que algunas unidades probablemente estén fallando debido a esto. Me pondré en contacto con Atmel con la información del chip defectuoso (número de lote, fecha, etc. que está marcada en el dispositivo) y pedirle más orientación. Tal vez muchos tuvieron problemas. La tasa de fallos parece demasiado pequeña para ser un problema de PCB, pero podría explicarse definitivamente por algunos dispositivos que no cumplen con la especificación -40C.