Hemos estado utilizando microcontroladores ATmega48 / 88/168/328 con éxito durante muchos años en muchos de nuestros productos. Ahora hemos considerado cambiar de las variantes A y PA a la nueva variante PB (porque necesitaremos los pines, temporizadores y UART adicionales en los nuevos productos, porque se ha vuelto más barato y porque parece que las variantes antiguas se descontinuarán), entonces cambiamos un ATmega328A con un ATmega328PB. Parece enloquecer muy a menudo después de interrupciones de energía . Tales problemas nunca ocurrieron con las antiguas variantes.

Las interrupciones de energía regulares son normales para el uso de nuestros productos. Usamos una fuente de alimentación conmutada (como esta ) configurada en 5V, y tenemos condensadores en el rango de 220 µF en el VCC de ATmega, para mantener viva la SRAM por interrupciones de energía en el rango de varios minutos, para almacenar estados internos que no son misión crítico, pero aumenta significativamente la experiencia del usuario al estar disponible instantáneamente al reiniciar (estos estados cambian con la frecuencia suficiente para que la EEPROM no sea adecuada). Esto siempre ha funcionado.

Sin embargo, con el nuevo ATmega328PB, después de una interrupción de energía, el chip se restablece sin que se encuentre una condición de reinicio en MCUSR, y el reloj parece enloquecer.

• el detector de apagón se configura por fusible. Probamos todos los bodlevel disponibles, el error ocurre en todos ellos.
• Usamos 20 MHz externos, también configurados correctamente por fusible.
• probamos 3 chips diferentes, por lo que no se trataba de una sola soldadura u otra falla de hardware.

Después de que ocurre el error, el reloj a menudo se pone a una velocidad 2,5 veces más lenta, lo que indica que el oscilador interno de 8 MHz sincroniza el mcu. Sin embargo, a veces la desaceleración es de alrededor de 6x. Esto significa que no puede ser un error de software que cambie el divisor del reloj, ya que no puedo configurar los fusibles del software, y el divisor del reloj no puede dividir el reloj por 2.5 o por 6.

Entonces, mi primer sospechoso fue el nuevo fusible de detección de falla del reloj. Sin embargo, no importa si está activado o desactivado, el comportamiento sigue siendo el mismo.

Para descartar las peculiaridades del software, escribí un programa de prueba simple desde cero, que no hace nada más que alternar una salida con 100 Hz de una interrupción del temporizador, e indica con LED después de cada reinicio qué condiciones de reinicio se activaron (como se lee en MCUSR). También se eliminó el resto del hardware, solo están presentes el mcu y el regulador (y los leds indicadores con resistencias en serie).

Los resultados

Aproximadamente 2/3 de las veces, no pasa nada interesante. Después de la interrupción de energía, el mcu reanuda su trabajo, tanto los indicadores de reinicio de apagado como de reinicio de encendido se iluminan.

(en la imagen, el rojo es el pin de alternancia, y el azul es VCC. En esta imagen, el bronceado de 2.7 V es claramente visible. Hice las mismas pruebas con los otros ajustes de marrón, los resultados son exactamente los mismos, así que omitiré esas fotos)

Aproximadamente 1/3 de las veces, se produce el error mencionado anteriormente, y cuando se vuelve a encender, ¡ ninguno de los indicadores de reinicio de apagado y reinicio de encendido se enciende! La salida es diferente, como si el mcu estuviera marcando un reloj extraño. No es caótico, sin embargo, sigue marcando con la misma frecuencia.

Curiosamente, en esta situación, el detector de apagón parece estar completamente inactivo, porque después de la siguiente interrupción de la alimentación (donde a veces se restaura el reloj correcto, a veces no), es claramente visible que la salida sigue alternando bien después del apagón. Se ha superado el nivel. En tales situaciones, el reloj a veces se acelera, otras veces se vuelve más lento:

Durante estas pruebas, utilicé 16K CK / 14CK + 4.1 ms para el retraso de inicio (pero el retraso de 65 ms no evita los problemas).

Aquí hay una imagen ampliada, donde puede ver claramente que el VCC alcanza un estado estable a 5 V en menos de 2 ms:

En la imagen de arriba, el mcu comenzó correctamente.

Curiosamente, cuando no lo hace, el voltaje de suministro alcanza 5 V estables incluso antes (parece que muchas partes del mcu no se encienden, por lo que consume menos corriente durante el arranque)

A continuación se muestra una imagen de un inicio sin éxito:

Tenga en cuenta que el software comienza a ejecutarse después de más de 85 ms después de que la tensión de alimentación se haya estabilizado, en lugar de los 10,5 ms requeridos de lo contrario. Los fusibles para el retraso de inicio siguen siendo los mismos, 16K CK / 14CK + 4.1 ms.

Lo que también es interesante notar es que después de que se apagó el suministro, el VCC se estabiliza en alrededor de 1.1 a 1.2 voltios (la antigua variante ATmega328A bajó a alrededor de 0.6 - 0.7 V). Lo mantiene durante varios minutos. Si espero lo suficiente (del orden de media hora o más), ¡el mcu siempre comienza correctamente! Por lo tanto, parece que el problema es que hay 1.1 voltios alrededor, lo que, según la hoja de datos, no se garantiza que sea suficiente para un reinicio de encendido. ¡Pero debería ser suficiente para un reinicio de caída de voltaje!

Excepto en estas situaciones, el detector de oscurecimiento funciona bien. Es visible en la primera imagen (la señal de salida se detiene cuando se alcanza el nivel bodlevel, y la caída de voltaje se ralentiza, ya que partes del mcu se apagan). Hice pruebas cuando reduje el VCC a un poco por debajo del nivel bodlevel y dejé que volviera a subir, el mcu siempre se reiniciaba correctamente en tales condiciones, con solo el indicador de reinicio de oscurecimiento iluminado.

¿Olvidé algo obvio o el ATmega328PB tiene un error grave en su detector de oscurecimiento?

EDITAR:

Curiosamente, los problemas anteriores solo surgen cuando interrumpo el suministro ante el regulador. Si lo interrumpo después del regulador (o uso una fuente de alimentación de laboratorio), los problemas nunca suceden. Como si la forma del aumento de voltaje causara los problemas. Sin embargo, como puede ver en la última imagen, el aumento de voltaje es bastante bueno y se estabiliza rápidamente.

EDITAR 2

Lo probé con 16 MHz en lugar de 20 MHz, pero ocurren exactamente los mismos problemas.

No creo que sea un error con el detector de oscurecimiento, sino cómo usas el chip.

Como usted mismo dijo, el umbral de reinicio de encendido de 1.1 V no se alcanza si la energía se corta y se conecta brevemente, por lo que no habrá POR.

El detector de oscurecimiento tampoco puede ayudar mucho aquí. Está utilizando el AVR a 20 MHz, y esto requiere que el voltaje de alimentación sea de 4.5 V o superior, o está violando las especificaciones. Y BOD no garantiza que se disparará a 4.5 V, por lo general es menor que eso, digamos 4.3 V. Por lo tanto, incluso antes de que se active BOD, no hay garantía en qué estado termina el AVR, pero el BOD debería activarse, excepto que puede no funciona debido a su reloj de 20 MHz. Cuando el voltaje comienza a aumentar nuevamente, el BOD se desactiva antes de que el voltaje de suministro vuelva a un nivel seguro de 4.5 V. Si se activó correctamente. El tiempo de retardo de arranque debe establecerse en un valor lo suficientemente alto como para que el voltaje tenga un cambio que aumente del nivel de desactivación de la DBO a 4.5 V antes de que se libere el reinicio interno.

Pero todo puede fallar porque solo necesita al menos 4.5 V para funcionar a 20 MHz. La hoja de datos del AVR menciona que si el sistema de reinicio interno no es adecuado, use un chip de reinicio externo, y en este caso parece que resolvería sus problemas al reiniciar el AVR antes de que el voltaje caiga a 4.5 V.