Problemas para volver a flashear ATtiny85 después de configurar la preescala en 0x00

Después de flashear el ATtiny85 con el código, incluida la configuración de la preescala del reloj en 0x00 (en el código, sin parpadear el fusible), la próxima vez que intento flashear obtengo los siguientes errores que me impiden hacerlo:

avrdude.exe: error: programm enable: target doesn't answer. 1
avrdude.exe: initialization failed, rc=-1
avrdude.exe: AVR device initialized and ready to accept instructions
avrdude.exe: Device signature = 0x500075 
avrdude.exe: Expected signature for ATtiny85 is 1E 93 0B

Realmente no entiendo. Obviamente, el USBasp está conectado correctamente y funcionando (de lo contrario, no obtendría la línea de seguimiento "Dispositivo AVR inicializado..."). He intentado volver a flashear el código que estaba ejecutando (CLKPR = 0x00). (sin preescala), todavía falló. Luego probé el programa de parpadeo en un ATtiny85 diferente - funcionó. Volviendo al original, ¡todavía no puedo flashear!

Intenté restablecer el fusible usando el -B1 a -B6, nada...

Soy un novato, ¡así que probablemente haya algo estúpido que esté haciendo!


Restablecer ese dispositivo justo antes de enviar el flash ve que funciona. Sin embargo, ahora parece que tengo un nuevo problema al intentar flashear el fusionado a los valores predeterminados.

El comando que estoy emitiendo...

avrdude  -p t85 -P COM3  -b 19200 -c avrisp  -U efuse:w::m -v -B700

La salida...

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.08s

avrdude.exe: Device signature = 0x000000 (retrying)

Reading | ################################################## | 100% 0.06s

avrdude.exe: Device signature = 0x000000 (retrying)

Reading | ################################################## | 100% 0.06s

avrdude.exe: Device signature = 0x000000
avrdude.exe: Yikes!  Invalid device signature.
             Double check connections and try again, or use -F to override
             this check.

Después de leer la ronda, estoy bastante seguro de que está relacionado con el reloj / cristal. Simplemente no estoy muy seguro de cómo agregar un cristal.

Gracias de nuevo, Harold Clements

¿Cuál es el valor con el que programó los bytes del fusible?
No cambié los bytes del fusible. Estaba tratando de hacerlo más fácil al hacerlo solo en código.
Eso parece inusual porque el dispositivo debe mantenerse reiniciado antes y durante la programación, por lo que el código no debería ejecutarse. Además de que el chip se dañe, lo único aleatorio que se me ocurre es mantener el reinicio bajo en su circuito (tal vez 1K a tierra) mientras lo enciende, intente programar y vea qué sucede.
foto de tu montaje? ¿Están bien los voltajes de la fuente de alimentación? ¿Agregó una tapa de desacoplamiento en los rieles de la fuente de alimentación cerca del controlador?

Respuestas (2)

Hay varios problemas con el comando avrdude que publicaste.

  • Está especificando una tasa de baudios y un puerto serie con -P COM3 -b 19200, lo cual no tiene sentido ya que el USBasp es un periférico USB puro y no requiere un puerto serie ni utiliza un convertidor USB a serie internamente. Estos ajustes no tienen ningún efecto.

  • Ha seleccionado el Atmel avrisp como su programador con -c avrisp, mientras afirma que su programador es el USBasp. Esto puede funcionar o no, pero avrdude es compatible con USBasp de forma nativa, por lo que debe indicarle a avrdude que el programador es USBasp con -c usbasp.

  • Está reescribiendo los bits efuse sin especificar un valor con -U efuse:w::m. La forma correcta de configurar los bits de fusible en modo inmediato (sin leer los valores de los bits de fusible de un archivo) sería -U FUSE:w:VALUE:m, por ejemplo -U efuse:w:0xFF:m, . El manual de avrdude no establece que dejar el valor del fusible sin especificar establezca el fusible en su valor predeterminado, por lo que probablemente solo establezca el fusible en 0x00 .

  • Su programador no es Atmel JTAG ICE, por lo que la configuración del reloj de bits -B700no tiene sentido y no tiene ningún efecto.

La buena noticia es que desechó efuse en lugar de hfuse, lo que podría haber bloqueado el AVR al configurar RSTDISBL y, por lo tanto, evitar la reprogramación.

Para resucitar su chip, sugeriría reprogramar todos los fusibles. Mi suposición es que, sin darse cuenta, ha estropeado los valores de los fusibles en algún momento, lo que hace que el chip funcione a 1 MHz o menos. Esto hace que el programador se comunique demasiado rápido en relación con la frecuencia de reloj de ATtiny, lo que da como resultado la transacción fallida que ve. El USBasp tiene un puente para reducir la velocidad de datos, que debe configurar. Para los fusibles en sí, existe una práctica herramienta en línea para determinar y comprender fácilmente los valores. Para programar los fusibles, ejecute

avrdude -p t85 -c usbasp -P usb -U lfuse:w:0x62:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m

(frecuencia de reloj de 8 MHz con oscilador interno, ISP habilitado, sin configuraciones especiales)

Para actualizar el chip con un nuevo .hex, ejecute

avrdude -p t85 -c usbasb -P usb -U flash:w:FILENAME:i
Siempre puede usar el modo de programación HVSP para programar un AVR que tenga configurado el bit RSTDISBL o que tenga una configuración de reloj incorrecta, pero hay muy pocos programadores que puedan programar un dispositivo usando este método. El AVR Dragon es lo que uso para estas situaciones.

Ate nRESET bajo antes de aplicar energía, luego aplique energía. Esto mantendrá la MCU en modo de reinicio para que el código de preescala nunca tenga la oportunidad de ejecutarse y debería poder programarlo normalmente después.