¿Por qué mi ATtiny13 informa una ID de dispositivo incorrecta?

Estoy usando un Arduino (con ATmega168) como programador ISP para programar ATtiny13. Cuando trato de hacer esto, avrdude informa:

avrdude: Device signature = 0x1e9406
avrdude: Expected signature for ATtiny13 is 1E 90 07

La -Fbandera para forzar la programación no anula la ID en este caso.

Sé que puedo restablecer la identificación con un programador de alto voltaje, pero ¿por qué el dispositivo informa incorrectamente su identificación en primer lugar? ¿Y por qué es un problema intermitente? De vez en cuando, el programador funciona bien, pero cuando no lo hace, siempre muestra exactamente la misma identificación errática.


Salida avrdude completa:

avrdude: Version 5.11.1, compiled on Oct 30 2011 at 10:37:28
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"
         User configuration file is "/home/jhendrix/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/ttyUSB003
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
         AVR Part                      : ATtiny13
         Chip Erase delay              : 4000 us
         PAGEL                         : P00
         BS2                           : P00
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65     5     4    0 no         64    4      0  4000  4000 0xff 0xff
           flash         65     6    32    0 yes      1024   32     32  4500  4500 0xff 0xff
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          2    0      0     0     0 0x00 0x00
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00

         Programmer Type : STK500
         Description     : Atmel STK500 Version 1.x firmware
         Hardware Version: 2
         Firmware Version: 1.16
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtiny13
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9406
avrdude: Expected signature for ATtiny13 is 1E 90 07
         Double check chip, or use -F to override this check.

avrdude done.  Thank you.
Este debería ser obvio, pero ¿estás seguro de que conectaste el programador correctamente?
No cambió nada, ni siquiera tocó el circuito. Intenté reprogramar y de repente funcionó. Ilumíname, ¿cuál es la cosa obvia que estoy pasando por alto? Sucedió antes.
No sé. Algo similar le sucedió a un ATmega162 mío, pero no tuve tiempo de investigarlo. A veces, el error aparecerá si el programador está mal conectado, pero si la conexión está bien, probablemente sea otra cosa.
@AndrejaKo ¿Qué tipo de programador usas para tus dispositivos?
Yo uso la versión casera de PonyProg .

Respuestas (2)

No es un error muy probable, y la consistencia de esta identificación "incorrecta" puede ser reveladora. Las malas conexiones pueden causar algunas fallas, pero generalmente en forma de bits retrasados ​​(es decir, mostrando los valores que son los bits vecinos), y 94 frente a 90 no se ve así. Además, una búsqueda rápida en la lista de ID de AVR de avrdude muestra que la ID que obtiene es la de un ATmega168, común en Arduino. Además, el cargador de arranque Arduino habla el protocolo STK500, que su avrdude está usando aquí, por lo que la pregunta obvia es ¿cuál es su programador?

Supongo que puede tener algo como un Arduino configurado como programador para programar otros AVR, y cuando sucede que se está reiniciando (y por lo tanto todavía en el cargador de arranque, que tiene un tiempo de espera antes de iniciar el programa cargado / "boceto") cuando se inicia avrdude, puede reprogramar ese AVR en lugar de la siguiente placa.

Mi segunda suposición, que sería la primera sin las notas anteriores sobre el comportamiento de Arduino, sería hablar con otro programador sin querer; eso puede verse afectado por cosas simples como el orden en que están conectados al USB.

En cualquiera de los escenarios, en realidad no es una identificación incorrecta, sino otro AVR que responde a la intención. Para el caso de Arduino como programador, las cosas pueden complicarse con el reinicio automático cuando inicia un programa para hablar con la placa; solucionar eso podría ser un poco más complejo, y mi primera suposición sería algo como (sleep 3 ; avrdude -P /dev/ttyUSB0 -c stk500 -p t13 -U ... ) < /dev/ttyUSB0, lo que garantizaría un retraso entre la apertura del puerto serie y la ejecución de avrdude.

¡Hay un ATmega168 en mi programador! Este es un hallazgo interesante. Ciertamente tengo que comprobar su respuesta con más detalle mañana.
No he podido reproducir mi problema desde que evité que el ATmega168 (Arduino) recibiera un reinicio.

Esto no responderá a la pregunta original, pero podría ayudar a otras personas a llegar aquí:

Usé un arduino (y luego compré un clon de USBasp) para programar un ATtiny85. Esto funcionó bastante bien durante una buena cantidad de tiempo hasta que, de repente, sin ninguna razón obvia, seguía recibiendo firmas de dispositivos incorrectas de mi Attiny:

avrdude: Device signature = 0x1e010b
avrdude: Expected signature for ATtiny85 is 1E 93 0B

Siempre obtuve esta identificación 0x1e010b y me volvía loco. No coincidía con la firma del dispositivo de otro AVR (consulte esta lista ) y la conexión del cable era buena. Una mala conexión normalmente causaría errores bastante aleatorios, y las señales también se veían bien en el osciloscopio.

Finalmente descubrí que mi concentrador USB era el problema. El voltaje de suministro USB de 5 V que entregó a mi programador fue de solo alrededor de 4,4 V. Cuando conecté el programador directamente a mi computadora portátil, el voltaje estaba entre 5,05 y 5,15 V y ¡todo volvió a funcionar perfectamente bien! Probablemente fue un apagón o algo relacionado con los niveles de señal.

Si tiene un problema con firmas de dispositivos incorrectas:

  • recibir 0x000000 o 0xffffff generalmente significa que su chip Atmel no está encendido o reiniciado (correctamente). También verifique si los niveles de señal del programador coinciden con el nivel de suministro de energía de su microcontrolador Atmel (típicamente 3.3 V o 5 V) - mejor antes de conectarlo por primera vez ;)
  • recibir llamadas falsas aleatorias de firma de dispositivo para un cable o conexión defectuosos
  • recibir constantemente la misma firma de dispositivo incorrecta podría significar que ha conectado otro chip Atmel que el que especificó en la consola ("-p t85" para ATtiny85 en mi caso) o que ingresó un comando incorrecto y el chip del programador responde con su propia identificación (¡tenga cuidado de no sobrescribir su programador con su código de aplicación!)
  • ... o también podría significar que la fuente de alimentación de su programador o su chip Atmel de destino es débil o demasiado baja; verifique si conecta su programador a su computadora portátil/PC directamente o intente con un puerto diferente y también verifique la fuente de alimentación del Chip Atmel en su aplicación.

Espero que esto ayude a alguien :)