AVR no puede entrar en el modo de programación

Tengo un ATMega88PB en una PCB que no ingresa al modo de programación después de cambiar la configuración del fusible a EXTFSXTAL_16KCK_14CK_0MS. Antes de esto, el AVRISP MkII podía comunicarse con el microcontrolador (desde entonces cambié a un Atmel ICE que todavía no puede comunicarse).Error de Atmel Studio

En caso de que haya alguna duda de que he cambiado incorrectamente otras configuraciones de fusibles, aquí hay una captura de pantalla de los fusibles antes de la programación.Configuración de fusibles

Encuentro esto confuso porque el oscilador parece estar funcionando bien; si hubiera programado la configuración incorrecta del fusible (por ejemplo, ext clk), esperaría que el oscilador se deshabilite para ahorrar energía. Como puede ver, este no es el caso, ya que el oscilador funciona ligeramente por debajo de los 20 MHz.

Forma de onda XTAL2:Forma de onda XTAL2

Forma de onda XTAL1:Forma de onda XTAL1

Aquí está el esquema para el circuito del oscilador:Esquemático

He intentado programar el dispositivo a todas las velocidades disponibles y todavía no he tenido suerte. También intenté alimentar una señal de reloj desde el pin CLK0 de un AVR en funcionamiento sin éxito, y probé condensadores de carga de 18pF en lugar de los 33pF indicados en el esquema.

¿Qué más puedo intentar para que este microcontrolador vuelva a funcionar?

Respuestas (1)

Su registro de fusible bajo es 0xD7. Eso equivale a 0b1101 0111 en binario.

Mirando la hoja de datos, los 4 bits inferiores son responsables del reloj. Esto se correlaciona con

CKSEL3 = 0, CKSEL2 = 1, CKSEL1 = 1, CKSEL0 = 1.

Según la hoja de datos, esta no es una configuración válida, pero puede configurarse en un cristal de baja frecuencia. Las dos configuraciones válidas similares son 0b0100 y 0b0101, ambas son para un oscilador de baja frecuencia. Intente reemplazar el cristal de 20MHz con un cristal de 32.768kHz.

Una discrepancia entre la frecuencia esperada y la frecuencia real puede provocar que el procesador no se inicie.

Si eso no funciona, es posible que deba usar la programación paralela para recuperar el chip. La programación paralela no requiere un cristal de trabajo y proporciona un reloj externo.

Aquí hay una captura de pantalla de la hoja de datos.ingrese la descripción de la imagen aquí

No estoy en una computadora en este momento, así que no puedo verificar, pero ¿es posible que el registro de fusibles que muestra Atmel Studio sea la configuración de fusibles anterior que detectó antes de escribir el nuevo fusible? (En la captura de pantalla, SUT_CKSEL se modificó pero aún no se escribió).
La página 27 de la hoja de datos dice que CKSEL3...0 = 0111 - 0110 corresponde al oscilador de cristal de oscilación completa, por lo que no estoy seguro de por qué cree que es una configuración no válida. Además, SUT1...0 y CKSEL0 = 011 corresponde al oscilador de cristal, BOD habilitado. (tiempo de inicio 16k CK, +19CK desde reinicio) y finalmente CKDIV8 = 1 significa que la división de reloj está deshabilitada. Estos son los fusibles que tengo pensado programar para no ver el problema.
@bhillam No estoy seguro de qué hoja de datos está trabajando, ¿dónde la obtuvo? Obtuve esta hoja de datos del sitio web de Atmels. La imagen es la página 30. El ajuste del oscilador 0111 no aparece en la lista.
Parece que tengo una hoja de datos preliminar. imgur.com/ID8x0TR no es que deba importar ya que Atmel Studio debería tener la configuración de fusibles correcta (no escribí en el campo hexadecimal, los elegí en la GUI).
@bhillam Entonces, ¿qué hay exactamente en los campos HEX? Porque su captura de pantalla muestra 16kCK_14CK_0MS, que no es una configuración que figura en la hoja de datos.
No tengo forma de averiguar cuáles son los bits de fusible reales ahora, ya que el programador no se comunicará con el avr. Cuando pueda tener en mis manos un cristal de 32 kHz, intentaré comprobarlo.
Reemplacé el cristal de 20MHz con un cristal de 32.768kHz y ahora el oscilador no arranca en absoluto; antes oscilaba, pero no respondía al programador.
@bhillam Entonces la programación paralela es la única forma que queda para recuperar el chip.
Terminé volviendo a programar el chip inyectando un reloj externo de 1 MHz en el pin XTAL1/TOSC1 (mi error anterior fue dejar el cristal conectado al hacerlo). Los fusibles leídos por el programador ahora son ex: F9, hi: DF, lo: 77, por lo que no estoy seguro de dónde obtuvo el software los bits de fusibles anteriores. Este parece ser el oscilador de cristal de giro completo como se esperaba, por lo que no estoy seguro de por qué hubo un problema. El cristal oscilaba a 20 MHz pero no estaba en pleno movimiento (solo alcanzó alrededor de 2 V pico a pico), por lo que mi pregunta ahora es: ¿por qué el oscilador no puede alcanzar los rieles? (0-5V)?
Por lo que vale, la opción de oscilador de cristal de oscilación completa se eliminó de rev. 42176E (octubre de 2015) de la hoja de datos ATMega48/88/168PB (sin explicación). Además, la hoja de datos no parece indicar que la operación por encima de 16 MHz sea compatible con el oscilador de cristal de baja potencia (la única opción de oscilador de alta velocidad). Finalmente, AtmelStudio no parece limitar las opciones de fusibles en función del dispositivo seleccionado, lo que permite programar fusibles completamente sin sentido.
AVR no puede entrar en el modo de programación
RespuestasAquíPolítica de privacidad1y, 0v