1
\$\begingroup\$

After flashing the ATtiny85 with code including setting the clock prescale to 0x00 (in code, not flashing the fuse), the next time I try and flash I get the following errors preventing me from doing so:

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

I really don't understand. Obviously the USBasp is connected correctly and working (otherwise I would not get the "AVR device initialized..." trace line. I have tried re-flashing code that I was running (CLKPR = 0x00). Then tried flashing a simple blink program (no prescale), still failed. Then tried the blink program on a different ATtiny85 - worked. Back to the original, still can't flash!!!

I tried resetting the fuse using the -B1 to -B6, nothing...

I am very much a novice, so there is probably something stupid that I am doing!

Resetting that device just before I sent the flash sees to work. However, I now appear to have a new problem when trying to flash the fused back to default!

The command that I am issuing...

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

The output...

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.

After reading round, I am pretty sure that it is clock / crystal related. I am just not too sure how to go about adding a crystal.

Thanks again, Harold Clements

\$\endgroup\$
4
  • 1
    \$\begingroup\$ What is the value you programmed the fuse bytes with? \$\endgroup\$
    – jippie
    Apr 21, 2014 at 11:04
  • \$\begingroup\$ I did not change the fuse bytes. I was trying to make it easy by doing in code only. \$\endgroup\$
    – haroldjclements
    Apr 21, 2014 at 11:42
  • \$\begingroup\$ That seems unusual because the device should be held in reset before and during programming, so the code shouldn't run. Apart from chip being damaged the only random thing I can think of to try is holding the reset low in your circuit (maybe a 1K to ground) while powering up, try programming and see what happens. \$\endgroup\$
    – PeterJ
    Apr 21, 2014 at 14:05
  • \$\begingroup\$ Picture of your setup? Are the power supply voltages OK, did you add a decoupling cap across power supply rails near the controller? \$\endgroup\$
    – jippie
    Apr 21, 2014 at 18:07

2 Answers 2

Reset to default
2
\$\begingroup\$

There are several issues with the avrdude command you posted.

  • You are specifying a baud rate and a serial port with -P COM3 -b 19200, which is nonsensical as the USBasp is a pure usb peripheral and does not require a serial port nor use a usb to serial converter internally. These settings have no effect.

  • You have selected the Atmel avrisp as your programmer with -c avrisp, while you claim that your programmer is the USBasp. This may or may not work, but avrdude supports USBasp natively, so you should instruct avrdude that the programmer is USBasp with -c usbasp.

  • You are rewriting the efuse bits without specifying a value with -U efuse:w::m. The correct way to set the fuse bits in immediate mode (not reading the fuse bit values from a file) would be -U FUSE:w:VALUE:m, for example -U efuse:w:0xFF:m. The manual of avrdude does not state that leaving the fuse value unspecified sets the fuse to its default value, so it probably just sets the fuse to 0x00.

  • Your programmer is not the Atmel JTAG ICE, so the bit clock setting -B700 is nonsensical, and has no effect.

The good news is that you trashed efuse instead of hfuse, which could have bricked the AVR by setting RSTDISBL and thus preventing reprogramming.

To resurrect your chip, I would suggest to reprogram all fuses. My guess is that you have inadvertently messed up the fuse values at some point, causing the chip to run at 1MHz or less. This causes the programmer to communicate too fast relative to the clock frequency of the ATtiny, resulting in the glitched transaction you see. The USBasp has a jumper for lowering the data rate, which you should set. For the fuses themselves, there is a handy online tool for easily determining and understanding the values. To program the fuses, run

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

(8MHz clock frequency using internal oscillator, isp enabled, no special settings)

For flashing the chip with a new .hex, run

avrdude -p t85 -c usbasb -P usb -U flash:w:FILENAME:i
\$\endgroup\$
1
  • \$\begingroup\$ You can always use HVSP programming mode to program an AVR which has had its RSTDISBL bit set or which has bad clock settings, but there are very few programmers which can program a device using this method. The AVR Dragon is what I use for these situations. \$\endgroup\$
    – akohlsmith
    Jun 24, 2015 at 15:23
0
\$\begingroup\$

Tie nRESET low before applying power, then apply power. This will hold the MCU in reset mode so that the prescale code never has a chance to run and you should be able to program it normally after.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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