programming fails

[GoogleCodeExporter]

What steps will reproduce the problem?
1. connect atmega168 to arduino, noted that directions in comments at
beginning of avrisp.pde code seem to be incorrect (miso/mosi inverted). i
used the following instead:

arduino pin 7 - "communicating" led
arduino pin 8 - "error" led
arduino pin 9 - "heartbeat" led
arduino pin 10 - atmega pin 1 "reset"
arduino pin 11 - atmega pin 17 "mosi"
arduino pin 12 - atmega pin 18 "miso"
arduino pin 13 - atmega pin 19 "sck"

2. upload avrisp.pde into arduino diecimila, i can see heartbeat led fading
on/off. quit arduino environment.
3. enter command from within hardware/tools/avr/bin directory of
arduino-011 directory: ./avrdude -C ../etc/avrdude.conf -p m168 -c avrisp
-b 19200 -P /dev/tty.usbserial-A4001lXM -U flash:w:Blink.hex -U
lfuse:w:0xE2:m -U hfuse:w:0xDF:m 

What is the expected output? What do you see instead?
expected to burn "blink" program to atmega168.
instead:
- heartbeat went off 
- "communicating" led did not light up.
- after a while, "error" led started flashing.
- avrdude gives error messages, see below. program is not uploaded.

What version of the product are you using? On what operating system?
Mac OS X 10.4.11, Arduino Diecimila, Arduino environment v.11

Please provide any additional information below.

Although avrdude appeared to upload and verify the program hex file, it is
not so, since the same output happens whether or not the target atmega is
even connected to the programming lines.

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.11s

avrdude: Device signature = 0x1e9406
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be
performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "Blink.hex"
avrdude: input file Blink.hex auto detected as Intel Hex
avrdude: writing flash (1094 bytes):

Writing | ################################################## | 100% 1.00s

avrdude: 1094 bytes of flash written
avrdude: verifying flash memory against Blink.hex:
avrdude: load data flash data from input file Blink.hex:
avrdude: input file Blink.hex auto detected as Intel Hex
avrdude: input file Blink.hex contains 1094 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.85s

avrdude: verifying ...
avrdude: 1094 bytes of flash verified
avrdude: reading input file "0xE2"
avrdude: writing lfuse (1 bytes):

Writing |                                                    | 0% 0.00s
***failed;  
Writing | ################################################## | 100% 0.26s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xE2:
avrdude: load data lfuse data from input file 0xE2:
avrdude: input file 0xE2 contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xe2 != 0x00
avrdude: verification error; content mismatch

avrdude: safemode: lfuse changed! Was e2, and is now 0
Would you like this fuse to be changed back? [y/n] 
avrdude: safemode: Fuses OK
avrdude: stk500_recv(): programmer is not responding 

Original issue reported on code.google.com by jef...@trashymail.com on 6 May 2008 at 10:26

[GoogleCodeExporter]

eh, somehow my inital comments got lost... anyways, thanks for working on this! 
it
would be great to use the arduino itself to program blank atmega chips!

Original comment by jef...@trashymail.com on 6 May 2008 at 10:34

[GoogleCodeExporter]

You're right about the pins, they were mislabeled in the original release.
For the programming, it looks like the flash part works. I'd suggest programming
the flash and then programming the fuses in a separate step.

Original comment by rsb...@gmail.com on 27 May 2008 at 4:46

[GoogleCodeExporter]

The avrdude in Arduino 011 doesn't always work. I'd recommend using a current 
WinAVR
toolchain.

Original comment by rsb...@gmail.com on 10 Feb 2009 at 11:00

[GoogleCodeExporter]

I seem to be having a problem programming the fuse bytes as well.  Normal flash
programming works fine, but reading the fuse bytes always results in 0x00 and 
writing
the fuse bytes fails.

I have tried both high and low fuses, with the same results for both.  I am on 
OS X
10.4, using avrdude included with Arduino 013 (I tried the macports version, 
but it
could not even program the flash RAM correctly).  I just updated from avrisp 
0.2 to
0.3, and the problem exists with both.

Output of avrdude (for reading) follows:

./avrdude -C ../etc/avrdude.conf -p m168 -P /dev/tty.usbserial-FTE0U36U -c 
avrisp -b
19200 -U hfuse:r:-:h -U lfuse:r:-:h

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9406
avrdude: reading hfuse memory:

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

avrdude: writing output file "<stdout>"
0x0
avrdude: reading lfuse memory:

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

avrdude: writing output file "<stdout>"
0x0

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Output of avrdude for writing follows:

./avrdude -C ../etc/avrdude.conf -p m168 -P /dev/tty.usbserial-FTE0U36U -c 
avrisp -b
19200 -U hfuse:w:0xdf:m

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9406
avrdude: reading input file "0xdf"
avrdude: writing hfuse (1 bytes):

Writing |                                                    | 0% 0.00s 
***failed;  
Writing | ################################################## | 100% 0.13s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xdf:
avrdude: load data hfuse data from input file 0xdf:
avrdude: input file 0xdf contains 1 bytes
avrdude: reading on-chip hfuse data:

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

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xdf != 0x00
avrdude: verification error; content mismatch

avrdude: safemode: hfuse changed! Was df, and is now 0
Would you like this fuse to be changed back? [y/n] y
avrdude: stk500_recv(): programmer is not responding

Original comment by wyatt.ol...@gmail.com on 19 Feb 2009 at 1:31

[GoogleCodeExporter]

same problem with arduino uno and attiny2313, it worked yesterday, but today i 
have this:
F:\>avrdude -p attiny2313 -c avrisp   -F  -U hfuse:r:-:h -U lfuse:r:-:h

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.13s

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATtiny2313 is 1E 91 0A
avrdude: reading hfuse memory:

Reading | ################################################## | 100% 0.04s

avrdude: writing output file "<stdout>"
0x0
avrdude: reading lfuse memory:

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

avrdude: writing output file "<stdout>"
0x0

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

and this:

F:\>avrdude -p attiny2313 -c avrisp   -F  -U hfuse:w:0xdf:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.13s

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATtiny2313 is 1E 91 0A
avrdude: reading input file "0xdf"
avrdude: writing hfuse (1 bytes):

Writing |                                                    | 0% 0.00s 
***failed;
Writing | ################################################## | 100% 0.32s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xdf:
avrdude: load data hfuse data from input file 0xdf:
avrdude: input file 0xdf contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.05s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xdf != 0x00
avrdude: verification error; content mismatch

avrdude: safemode: hfuse changed! Was df, and is now 0
Would you like this fuse to be changed back? [y/n]

Original comment by a...@bcnet.ro on 17 Feb 2011 at 11:53

[GoogleCodeExporter]

Original comment by rsb...@gmail.com on 25 Jun 2011 at 3:27

• Changed state: WontFix

[GoogleCodeExporter]

Getting this same error while programming a small production run of devices. 
Design works, but programming failure rate is 30%. Devices were contract 
manufactured. Using avrdude: Version 5.10 on Ubuntu 10.10

gduncan@HackBox:~$ avrdude -p m168 -P usb -c avrispmkII -B 6 -U lfuse:w:0xbf:m 
-U hfuse:w:0xff:m -U efuse:w:0xff:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9406
avrdude: reading input file "0xbf"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xbf:
avrdude: load data lfuse data from input file 0xbf:
avrdude: input file 0xbf contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xff"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xff:
avrdude: load data hfuse data from input file 0xff:
avrdude: input file 0xff contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xff != 0xdf
avrdude: verification error; content mismatch

avrdude: safemode: hfuse changed! Was ff, and is now df
Would you like this fuse to be changed back? [y/n] y
avrdude: safemode: and is now rescued
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

When programming flash I also get:

gduncan@HackBox:~$ avrdude -p m168 -P usb -c avrispmkII 
-Uflash:w:Desktop/CurrentWork/Disorient_2010_Firmware/sd_testing.hex -B 2

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9406
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file 
"Desktop/CurrentWork/Disorient_2010_Firmware/sd_testing.hex"
avrdude: input file Desktop/CurrentWork/Disorient_2010_Firmware/sd_testing.hex 
auto detected as Intel Hex
avrdude: writing flash (14542 bytes):

Writing | ################################################## | 100% 1.52s

avrdude: 14542 bytes of flash written
avrdude: verifying flash memory against 
Desktop/CurrentWork/Disorient_2010_Firmware/sd_testing.hex:
avrdude: load data flash data from input file 
Desktop/CurrentWork/Disorient_2010_Firmware/sd_testing.hex:
avrdude: input file Desktop/CurrentWork/Disorient_2010_Firmware/sd_testing.hex 
auto detected as Intel Hex
avrdude: input file Desktop/CurrentWork/Disorient_2010_Firmware/sd_testing.hex 
contains 14542 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 1.45s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0x0c != 0x00
avrdude: verification error; content mismatch

avrdude: safemode: lfuse changed! Was bf, and is now 0
Would you like this fuse to be changed back? [y/n] y

Answering yes causes both avrispmkII LEDs to flash, and hang avrdude and the 
avrispmkII. Only solution is to unplug/replug avrispmkII to reset it and move 
try the next device. Answering no for lfuse, hfuse, and efuse returns the 
prompt but still crashes avrispmkII. 

I find it kind of hard to believe that 30% of the Atmega168's in my build are 
bad or damaged. Will gladly work with devs to debug this problem and improve 
avrdude!

Original comment by playas...@gmail.com on 22 Aug 2011 at 6:45

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Last time I had similar simptoms with ATmega328P, it was because the SPI clock 
during ISP was too high for the MCU clock.

Did you try to reduce SPI clock during ISP programming?

What clock frequency is the MCU running from during ISP? 

Do you get better yield if you use avrdude option -B 40 ?

Original comment by *bj...@logitech.com on 23 Aug 2011 at 8:20