¿Las nuevas variantes de "PB" de ATmega tiene un fallo en el detector de brown-out?

Question

Hemos estado utilizando ATmega48/88/168/328 los microcontroladores con éxito durante muchos años en muchos de nuestros productos. Ahora hemos considerado a cambiar a partir de la Una y PA variantes a la nueva PB variante (porque vamos a necesitar los pines extras, temporizadores y UARTs en nuevos productos, porque es más barato, y porque parece que el viejo variantes será descontinuado), así que nos cambiamos a cabo una ATmega328A con un ATmega328PB. Parece ir de mal en peor muy a menudo después de las interrupciones de energía. Estos problemas nunca se produjo con la edad variantes.

Regular las interrupciones de energía son normales para el caso de uso de nuestros productos. Utilizamos una fuente de poder (como este) para 5V, y capacitores en el 220µF rango en el ATmega de VCC, para mantener el SRAM vivo por las interrupciones de energía en el rango de varios minutos, para almacenar interno de los estados que no son de misión crítica, pero aumentar significativamente la experiencia de usuario está disponible al instante después de un reinicio (estos estados de cambio, a menudo suficiente para hacer la EEPROM no apto). Esto siempre ha funcionado.

Sin embargo, con la nueva ATmega328PB, después de una interrupción de la alimentación, el chip se restablece sin una condición de reinicio que se encuentra en MCUSR, y el reloj parece ir de mal en peor.

• el marrón de salida del detector se establece por fusible. Hemos probado todos los disponibles bodlevel, el problema sucede en todos ellos.
• utilizamos externo de 20 MHz, también se establece correctamente por fusible.
• tratamos de 3 chips diferentes, así que no fue una sola soldadura u otro fallo de hardware.

Después de que se produce el fallo, el reloj de frecuencia de los conjuntos de 2.5 x velocidad más lenta, lo que indica que el mcu está siendo desplazado por el de 8 MHz oscilador interno. Sin embargo, a veces la desaceleración es de alrededor de 6x. Esto significa que no puede ser un error de software cambiar el divisor de reloj, ya que no puedo configurar los fusibles de software, y el divisor de reloj no se puede dividir el reloj de 2.5 o por 6.

Por lo tanto, mi primer sospechoso era el nuevo Reloj de Detección de Fallo de fusible. Sin embargo, no importa si está encendido o apagado, el comportamiento sigue siendo el mismo.

Para descartar software peculiaridades, escribí un simple programa de prueba desde cero, lo cual no hace otra cosa sino que alterna una salida con 100 Hz de un temporizador de interrupción, y se indica con el Led después de cada reinicio que restablecer las condiciones fueron activados (como lectura de MCUSR). El resto del hardware también fue eliminado, sólo el mcu y el regulador están allí (y el indicador led con resistencias en serie).

Los resultados

Aproximadamente 2/3 del tiempo, nada interesante sucede. Después de la interrupción de la alimentación, la mcu reanuda su trabajo, tanto en el brown-out reset y power-on reset indicadores de encendido.

(en la imagen, el rojo es el tensado de pin, y el azul es VCC. En esta imagen, el 2.7 V bronwn es claramente visible. Hice las mismas pruebas con el otro marrón-ajustes de salida, los resultados son exactamente los mismos, así que voy a omitir las fotos)

Aproximadamente 1/3 del tiempo, en el mencionado fallo se produce, y cuando el poder está de vuelta de nuevo, ninguno de los brown-out reset y power-on reset indicadores se iluminan! El resultado es diferente, como si el mcu fue marcando con un extraño reloj. No es caótica, sin embargo, mantiene marcando con la misma frecuencia.

Curiosamente, en esta situación, el brown-out detector parece ser totalmente inactivo, debido a que después de la próxima interrupción de la alimentación (donde la correcta reloj es a veces restaurado, a veces no), es claramente visible que la salida se mantiene la alternancia después de brown-out ha sido aprobada. En tales situaciones, el reloj a veces se hace más rápido, otras veces se vuelve más lento:

Durante estas pruebas he utilizado 16K CK/14CK + 4.1 ms para la puesta en marcha de retraso (pero el 65 ms retardo de no evitar los problemas).

Aquí está una foto ampliada, donde se puede ver claramente que la VCC alcanza un estado estable a 5 V en menos de 2 ms:

En la imagen de arriba, el mcu se inició correctamente.

Curiosamente, cuando no, la tensión llega a un establo 5 V incluso antes (parece que muchas partes de la mcu no poder, por lo que consume menos corriente durante el arranque)

Abajo es una imagen de un fallido inicio:

Por favor, tenga en cuenta que el software se pone en marcha después de más de 85 ms después de la tensión de alimentación se ha estabilizado, en lugar de la 10.5 ms requerido de otra manera. Los fusibles para el retraso de inicio de la misma, 16K CK/14CK + 4.1 ms.

Lo que también es interesante tener en cuenta, es que después de que el suministro se apaga, el VCC se estabiliza en alrededor de 1,1 a 1,2 Voltios (el viejo, ATmega328A variante bajó a alrededor de 0.6 - 0.7 V). Mantiene que durante varios minutos. Si tengo que esperar el tiempo suficiente (en el orden de la mitad de una hora o más), el mcu siempre se inicia correctamente! Así que parece que el problema es que hay 1.1 Voltios alrededor, que, según la hoja de datos, no se garantiza que sea suficiente para que un power-on reset. Pero debería ser suficiente para que un brown-out reset!

Excepto para estas situaciones, el brown-out detector funciona bien. Es visible en la primera imagen (la señal de salida se detiene cuando la bodlevel se ha alcanzado, y la caída de tensión se ralentiza, como partes de la mcu se cierran). Me hicieron pruebas cuando he reducido el VCC a ligeramente por debajo de la bodlevel y se deja subir de nuevo de nuevo, el mcu siempre se reinicia correctamente, bajo tales condiciones, con sólo el brown-out reset indicador se ilumine.

¿Me olvido de algo obvio, o no la ATmega328PB tener un grave error en sus brown-out detector?

EDITAR:

Curiosamente, estos problemas sólo surgen cuando se interrumpe el suministro antes de que el regulador. Si puedo interrumpir después de que el regulador (o el uso de un laboratorio de la fuente de alimentación), los problemas nunca llegan a suceder. Como si la forma de la creciente tensión causado los problemas. Sin embargo, como se puede ver en la última imagen, el aumento de tensión es bastante agradable y se estabiliza rápidamente.

EDIT 2

He probado con 16 MHz en lugar de los 20 MHz, pero los mismos problemas ocurren.

Answer 1

No creo que sea un bug con el marrón de salida del detector, sino de cómo se utiliza el chip.

Como usted mismo ha dicho, el power-on reset umbral de 1.1 V no se alcanza si el poder es sólo brevemente se retira y conectado, por lo que no será POR.

Brown-out detector no puede ayudar mucho por aquí. Usted está utilizando el AVR de 20 MHz, y esto requiere que la tensión de alimentación de 4.5 V o superior, o que están violando las especificaciones. Y BOD no garantiza que se va de viaje a 4.5 V, es por lo general menos de que, por ejemplo 4.3 V. por Lo que incluso antes de la DBO desencadenantes, no hay ninguna garantía de en qué estado se encuentra el AVR termina, pero la JUNTA de directores debe desencadenar, a excepción de que no puede trabajar debido a sus 20 MHz de reloj. Cuando el voltaje comienza a subir de nuevo, la JUNTA de directores se desactiva antes de que el voltaje de suministro es segura 4.5 V nivel de nuevo. Si se activa correctamente. El inicio del tiempo de retardo debe ser, a continuación, establece lo suficientemente alto para que el voltaje tiene un cambio de lugar de la JUNTA de directores de la desactivación de nivel a 4.5 V antes del reset es liberado.

Pero todo puede fallar debido a que se necesita al menos de 4,5 V a ejecutar en 20 MHz. El AVR hoja de datos no mencionar que si el interno de reinicio del sistema es inadecuado, a continuación, utilizar un reseteo del chip, y en este caso parece que se iba a resolver sus problemas para restablecer el AVR antes de las caídas de voltaje a 4.5 V.