Why does my ATtiny13 report wrong device ID?

Question

I am using an Arduino (with ATmega168) as an ISP programmer to program ATtiny13. When I try to do this, avrdude reports:

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

The -F flag to force programming does not override the ID in this case.

I know I can reset the ID with a high voltage programmer, but why did is the device wrongly reporting its ID in the first place? And why is it an intermittent problem? Every now and then the programmer works fine, but when it doesn't it always pops the exact same erratic ID.

---

Full avrdude output:

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.

Answer 1

It's not a very probable error, and the consistency of this "wrong" ID may be telling. Bad connections can cause some glitching, but usually in the form of lagging bits (i.e. showing values neighboring bits are), and 94 vs 90 doesn't look like that. Further, a quick search in avrdude's list of AVR IDs shows that the ID you get is that of an ATmega168, common on Arduino. Furthermore, the Arduino bootloader speaks the STK500 protocol, which your avrdude is using here, so the obvious question is what your programmer is?

I'd guess you may have something like an Arduino set up as a programmer to program other AVRs, and when it happens to be resetting (and thefore still in the bootloader, which has a timeout before starting the loaded program/"sketch") as avrdude is started, you get to reprogram that AVR instead of the next board.

My second guess, which would be the first without the above notes on Arduino behaviour, would be talking to another programmer unintentionally; that can be affected by simple things like the order they are connected to USB.

In either scenario, it's not actually an incorrect ID, but another AVR than intended responding. For the Arduino as programmer case, things can be complicated by automatic reset when you start a program to talk to the board; working around that might be a bit more complex, and my first guess would be something like (sleep 3 ; avrdude -P /dev/ttyUSB0 -c stk500 -p t13 -U ... ) < /dev/ttyUSB0, which would ensure a delay between opening the serial port and running avrdude.

Answer 2

This won't answer the question asked originally but it might help other people landing here:

I used an arduino (and later bought a USBasp clone) to program an ATtiny85. This worked pretty well for a fair amount of time until suddenly, without any obvious reason, I kept getting wrong device signatures from my Attiny:

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

I always got this 0x1e010b ID and it drove me crazy. It didn't match the device signature of another AVR (see this list) and the cable connection was good. A bad connection would typically cause rather random errors, and the signals looked ok on the oscilloscope as well.

I finally found that my USB hub was the problem. The 5V USB supply voltage it delivered to my programmer was only around 4.4 V. When I attached the programmer directly to my Laptop, the voltage was between 5.05 and 5.15 V and everything worked perfectly fine again! Was probably a brown out or something related to the signal levels.

If you run into a problem with wrong device signatures:

• receiving 0x000000 or 0xffffff typically mean that either your Atmel chip is not powered or reset (properly). Also check if the programmer signal levels match the power supply level of your Atmel microcontroller (typically 3.3 V or 5 V) - best before connecting it for the first time ;)
• getting random false device signature calls for a bad cable or connection
• constantly receiving the same wrong device signature might just mean that you have connected another Atmel chip than the one you specified in the console ("-p t85" for ATtiny85 in my case) or you entered a wrong command and the programmer chip responds with its own ID (take care not to overwrite your programmer with your application code!)
• ... or it could also mean that the power supply of your programmer or your target Atmel chip is weak or too low - please check connecting your programmer to your Laptop/PC directly or try a different port and also check the power supply of the Atmel chip in your application.

Hope this helps someone :)