¿Las nuevas variantes "PB" de ATmega tienen un error en el detector de oscurecimiento?


9

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)

se reinicia bien

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.

se reinicia en un estado loco

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:

Sin oscurecimiento, el reloj se acelera Sin oscurecimiento, el reloj 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:

inicio exitoso, ampliado

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:

inicio sin éxito, ampliado

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.


¿Has contactado a Atmel o investigado sus erratas? En la actualidad, los errores de diseño de IC son bastante comunes.
Edgar Brown

He revisado las erratas (no encontré nada en esta dirección), y estamos considerando contactar a Atmel, pero no antes de hacer más pruebas y mirar un poco más.
vsz

3
Según mi experiencia, no pierda el tiempo antes de contactar al fabricante o usar sus foros. Ha realizado una depuración más que suficiente para presentar un caso muy sólido. Con mucho menos que eso, TI me envió sus erratas internas (inéditas) para uno de sus circuitos integrados que documentaba nuestro problema.
Edgar Brown

Mis dos centavos valen: he visto problemas con otras CPU si la potencia aumenta demasiado rápido. Algunos fabricantes especifican un tiempo de aumento máximo, pero con mayor frecuencia esto no se menciona.
Oldfart

Respuestas:


3

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.


Supuse que BOD no usa el procesador en sí, pero es un hardware dedicado. ¿Tal vez lo cambiaron por la variante PB? Me sorprendería si ya no admiten BOD para 20 MHz. El bodlevel más alto es de 4.3 V, ¿entonces 20 MHz requeriría un BOD externo? Aún así, tengo dudas de que solo esto sea la causa. Hice una prueba con 20 MHz, bodlevel de 2.7V, configuré el VCC a 3V, funcionó bien. Cuando reduje el voltaje manualmente a ligeramente por debajo de 2.7, la salida se detuvo, cuando lo aumenté por encima de 2.7, la salida se reanudó, siempre, nunca falló, ni siquiera una vez. Solo un inicio desde 1.1 V parece deshabilitar el BOD.
vsz

Lo más probable es que sea hardware dedicado, pero durante la subtensión antes de que el BOD entre en funcionamiento, ¿puede estar seguro de que se obtienen los datos correctos de la memoria flash para la ejecución de la CPU, y la CPU los ejecuta correctamente? Podría, o simplemente escribir datos aleatorios en registros reservados que hacen cosas no especificadas. Las especificaciones han cambiado para la variante PB, y tampoco admitían BOD para 20MHz en el chip anterior. La variante PB tiene curvas BOD y POR realmente diferentes y se activa más adelante a voltajes más bajos.
Justme

Por favor, eche un vistazo a mi segunda foto. El BOD aparentemente se activó correctamente y ha reiniciado el chip. Solo no se inicializa en el próximo inicio. Además, he manejado este chip a 3 V y funcionó correctamente, nunca falló ni una sola vez.
vsz

Bueno, en mi opinión, el chip no necesita funcionar fuera del área de operación segura, pero continuemos. El BOD no reiniciará el detector de fallas del reloj, por lo que solo el reinicio de encendido y el reinicio externo se desconectarán del reloj interno. Por lo tanto, verifique la configuración del fusible CFD. ¿Estás usando un cristal externo o un reloj externo? El fusible CFD podría haber sido previamente el fusible Full Swing. Y dado que no hay un fusible de giro completo, la frecuencia máxima para un cristal es de 16MHz, y 20MHz requiere una señal de reloj de nivel lógico externo. Por lo tanto, también podría ser un problema de inicio de Crystal, así que ponga un alcance a los pins de Crystal también.
Justme

Yo uso un cristal. Buena idea, lo investigaré. Tenga en cuenta que el mismo comportamiento que describí con imágenes ocurrió sin importar si el CFD estaba encendido o apagado.
vsz
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.