![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Today I first attempted to set up and program an ATtiny2313 AVR microcontroller mounted on an independent breadboard rather than the STK500’s own sockets. (I had until now only had chips which required external crystals — and all the crystals I had were well above their speed ratings!)
But I was getting extremely unreliable communication; avrdude would repeatedly fail to correctly read the device signature bytes or verify fuses. The failures were random; individual bytes were often correct, and very rarely the communication was completely successful. Sample failure:
avrdude: Device signature = 0x14910a
avrdude: Expected signature for ATtiny2313 is 1E 91 0A
Double check chip, or use -F to override this check.Or, when the signature read worked but the fuse-verify read failed:
That the failures are partial tells me that the chip is basically working and the programming connections are correct; there's just something marginal about the system. But what? Were my wires too long or too haywire? Did I need a closer decoupling capacitor? I got my hint while reading the ATtiny2313 datasheet's section on “Serial Downloading”:avrdude: AVR device initialized and ready to accept instructions avrdude: Device signature = 0x1e910a avrdude: safemode: Verify error - unable to read hfuse properly. Programmer may not be reliable. avrdude: safemode: To protect your AVR the programming will be aborted
Depending on CKSEL Fuses, a valid clock must be present. The minimum low and high periods for the serial clock (SCK) input are defined as follows:
Low:> 2 CPU clock cycles for fck < 12 MHz, 3 CPU clock cycles for fck >= 12 MHz
High:> 2 CPU clock cycles for fck < 12 MHz, 3 CPU clock cycles for fck >= 12 MHz
Hmm—what's my fck? The ATtiny2313 as shipped defaults to internal RC oscillator mode with a clock frequency of 1.0 MHz. The STK500 has a SCK period parameter, and mine’s set to: 1.1 µs. A clock frequency of 1.0 MHz (106 cycles/second) is a period of 1.0 µs (10-6 seconds), so this SCK period is way out of spec; I'm surprised it worked as well as it did.
I set the SCK period to 3 µs (the STK500 rounded it to 3.3 µs), putting it comfortably above the datasheet requirement of greater than 2 µs, and everything's working fine as far as I can tell — I haven't tried programming the chip yet, but repeated reads give no errors.
As can be found in the avrdude manual page, in order to set the SCK period, you use terminal mode (avrdude -t) and enter the command sck desired-period-in-µs. (The current period can be read with the parms command.) The tricky part is that avrdude attempts to communicate with the target chip before entering terminal mode! So you have to either keep trying until it works (-F to skip the signature check helps), or connect the STK500 to a target for which it is already correctly configured! (I haven't tried disconnecting the ISP interface entirely.)
I hope this helps the next person searching for “Programmer may not be reliable.”
