6
\$\begingroup\$

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.
\$\endgroup\$
  • \$\begingroup\$ This one should be obvious, but are you sure you connected the programmer properly? \$\endgroup\$ – AndrejaKo Jul 4 '12 at 19:12
  • \$\begingroup\$ Didn't change anything, didn't even touch the circuit. Just tried reprogramming and all of a sudden it worked. Enlighten me, what is the obvious thing I'm overlooking, it happened before. \$\endgroup\$ – jippie Jul 4 '12 at 19:25
  • \$\begingroup\$ I don't know. Similar thing happened to an ATmega162 of mine, but I didn't have time to investigate it. Sometimes, the error will appear if the programmer is badly connected, but if the connection is fine, then it's probably something else. \$\endgroup\$ – AndrejaKo Jul 4 '12 at 19:27
  • \$\begingroup\$ @AndrejaKo What type programmer do you use for your devices? \$\endgroup\$ – jippie Jul 4 '12 at 21:33
  • \$\begingroup\$ I use home-brewed version of PonyProg. \$\endgroup\$ – AndrejaKo Jul 4 '12 at 21:50
4
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ There is a ATmega168 in my programmer! This is an interesting find. I certainly have to check your answer in more detail tomorrow. \$\endgroup\$ – jippie Jul 16 '12 at 18:42
  • \$\begingroup\$ Haven't been able to reproduce my problem since I prevented the ATmega168 (Arduino) from receiving a reboot. \$\endgroup\$ – jippie Jan 1 '13 at 23:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.