ATtiny2313 refuses to be programmed after setting CPU clock to 500kHz

Question

The other day I was writing a program for an ATtiny2313. Once it worked I decided to test it at the various clock speeds that are available and programmed through setting the LFUSE as described on page 159.

• The default clock speed is 1MHz;
• so I tried 8MHz next and all worked fine;
• Then I set the clock speed for 4MHz with the /8-prescaler resulting in 500kHz clock.

Although the controller runs the program at the expected speed, my programmer refuses to reprogram the controller since. avrdude (5.11.1) just throws the well known: 'Yikes!':

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.

I tried adding the -F flag, but of course that didn't either.

Here are some code sniplets I used and changed the clock speed as expected:

// 0.5MHz
FUSES = { .low = 0x62   , .high = HFUSE_DEFAULT , .extended = EFUSE_DEFAULT , };


// 1MHz (default)
FUSES = { .low = 0x64   , .high = HFUSE_DEFAULT , .extended = EFUSE_DEFAULT , };

// 8MHz
FUSES = { .low = 0xe4   , .high = HFUSE_DEFAULT , .extended = EFUSE_DEFAULT , };

For programming, I use an Arduino with the ArduinoISP (version 04m3) sketch that came with Arduino IDE 1.0.1.

This is the command to program flash:

avrType=attiny2313
avrFreq=1000000
programmerDev=/dev/ttyUSB003
programmerType=arduino
avrdude -p$(avrType) -c$(programmerType) -P$(programmerDev) -b$(baud) -v -U flash:w:$(src).flash.hex

This is the command to program the fuses:

avrdude -p$(avrType) -c$(programmerType) -P$(programmerDev) -b$(baud) -v -U lfuse:w:$(src).lfuse.hex

My question is twofold:

1. What is the reason I cannot program the controller after setting it to 500kHz clock (while the program in the controller seems to run just fine);
2. What are my options for reprogramming the fuses without using a HV-programmer? Did I perhaps miss any useful flags to avrdude?

BTW: Had the same issue once with an ATtiny45 @ 128kHz. HV-programming solves it, but I want to prevent the HV situation.

Answer 1

The issue, as explained, too high SPI clock frequency. There exists a fixed version of ArduinoISP that can program at lower frequency available here. Some discussion on topic is available here.

Answer 2

As a rule of thumb, you may not choose any ISP speed more than quarter of your target MCU's speed. In your case, 500 / 4 = 125KHz should be the maximum ISP speed. If you can't change your Arduino's SPI speed as angelatlarge described, you may need an external programmer.

If you can't manage decreasing SPI speed of ArduinoISP, another solution may be a custom programmer code. You may change ArduinoISP to use a software SPI and calculate proper delays to decrease to 100KHz or maybe custom speeds. Take a look at http://little-scale.blogspot.com/2007/07/spi-by-hand.html for software implementation of SPI.

Answer 3

I am going to go for the Captain Obvious badge here and suggest that the ATtiny2313 speed is too low to be programmed by the ArduinoISP now. From the ATtiny2313 datasheet:

The minimum low and high periods for the serial clock (SCK) input are defined as follows: Low:> 2 CPU clock cycles for f\$_{ck}\$ < 12 MHz, 3 CPU clock cycles for f\$_{ck}\$ >= 12 MHz High:> 2 CPU clock cycles for f\$_{ck}\$ < 12 MHz, 3 CPU clock cycles for f\$_{ck}\$ >= 12 MHz

Your arduino probably runs at at least 16Mhz. Here's the relevant line from ArduinoISP.ino:

SPCR = 0x53;

This sets the Arduino SPI speed at f\$_{OSC}\$/64, or 250Khz if the SPI2X bit is programmed in the SPSR register. If this is correct At 500kHz clock, this is not more than 2 CPU clock cycles as the datasheet recommends. If this hypothesis is correct, the solution is to set the SPI clock divider to 128 by ensuring that SPI2X is off in spi_init() function in ArduinoISP.ino:

SPSR &= ~(1<<SPI2X);

Answer 4

I’m currently working on ScratchMonkey, an Arduino-as-programmer sketch that implements a software fallback for SPI, gradually backing off to speeds as low as 1kHz.

It’s still a work in progress, but you can get it from github