# Not able to program Attiny85-20PU

I have a small amount of Attiny85-20PU which I am trying to program with a stk500v1-type-programmer (for the sake of simplicity say an Arduino with ArduinoISP-Sketch).

My first attempts with that part were with the Arduino-Environment, but in the long run I want to use Atmel Studio (in connection with AVRDude as well).

But I am getting a Yikes-Type error from AVRDude. Verbose output shows that it doesn't recognize device signature (being 0x0).

The programmer, configuration (like baud rate) and wiring must be correct because I can successfully program another Tiny85-compatible board (the Nanite85, see https://cpldcpu.wordpress.com/2014/04/25/the-nanite-85/, it is internally clocked, I am not using the bootloader/USB). I have just double checked it, still works. Also, programming an Atmega328 in-circuit (with external clock) is not a problem with that programmer. It can't be a single defective part, I have checked it with two different items.

So my hot guess is that my Attiny85's are fused for external clock. But the datasheet from Atmel (http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-2586-AVR-8-bit-Microcontroller-ATtiny25-ATtiny45-ATtiny85_Datasheet.pdf, section 6.2 clock sources) clearly says that it should be factory-fused to "Calibrated Internal Oscillator". Could it be that this depends on the concrete model of the chip, contrary to the datasheet?

The chips seem properly labeled with Atmel logo and all. Although I bought them on Ebay, I can hardly imagine that any chinese copycat manufacturer would bother with an oldschool 2€ part.

Can I find out if the clock fuses are the problem without soldering the Attiny together with a crystal?

• You can use one of your other boards to generate a sufficiently fast clock for slow ISP and inject that. You just need a bit of code or Arduino sketch to toggle an I/O (with interrupts disabled please) or activate a hardware timer. For whatever reason, when I tried this I had better luck feeding it into the crystal output pin than the alleged input one, but your mileage may very. Keep in mind however that you cannot yet rule out a reset disable fuse, a fake part, a damaged one, or perhaps mistakes made in connection. – Chris Stratton Jul 25 '18 at 21:37
• @ChrisStratton: thanks, I'll consider it. BTW is there any defined behaviour to be expected if I just power on an (unprogrammed) MCU (looking at a scope) ? Or is it just consuming power without showing any meaningful behavior on the ports? – oliver Jul 26 '18 at 14:57
• With very sensitive instrumentation you might see the internal clock running (if enabled) especially as current on the power pins. But using a validated programming setup is probably simpler. Perhaps you should get at least one known-good ATtiny for comparison. And if fused for an external clock, I wouldn't expect much to happen. – Chris Stratton Jul 26 '18 at 15:07

I found the problem!

After giving high voltage erasure of the fuses a desperate trial - to no avail - it came to me that the problem might be SPI clock speed.

And indeed, when I changed the SPI clock speed inside the ArduinoISP sketch (excerpt below) from my previously tweaked value of 1 Mhz to the value recommended for Attiny85, programming (as well as device signature recognition) worked again!

// Configure SPI clock (in Hz).
// E.g. for an attiny @128 kHz: the datasheet states that both the high
// and low spi clock pulse must be > 2 cpu cycles, so take 3 cycles i.e.
// divide target f_cpu by 6:
//     #define SPI_CLOCK            (128000/6)
//
// A clock slow enough for an attiny85 @ 1MHz, is a reasonable default:

// Working with Attiny85 (the default in the ArduinoISP sketch):
#define SPI_CLOCK       (1000000/6)

// I tweaked this in the past, but it's not working with Attiny85:
//#define SPI_CLOCK 1000000UL

#define USE_HARDWARE_SPI


I did not notice that although Attiny85 is set to 8MHz default internal clock speed, there is also a clock divider of 8 active by default, so CPU clock is actually at 1 Mhz.