AVRISP mkII not reading device signature

I recently bought a dozen ATtiny85 MCUs and I was trying to test one simply by putting a blink program on it via the Arduino IDE with and AVRISP mkii (Arduino 1.0.5, Ubuntu 13.04). I kept getting an error suggesting that it wasn't wired correctly, but I've checked it multiple times (and it's powered externally at 4.8v). I even tested multiple ATtinys so it's very unlikely that they're all duds. When I switched to using my Arduino as ISP, it programmed fine. I tried using avrdude -c avrispmkii -p t85 -P usb -t to see if it was a problem with the Arduino IDE setup, but that gave me the same error. I set all the /etc/udev rules correctly as far as I can tell, and still no dice...

So I booted into Windows 8, installed Atmel Studio 6 and the drivers for the AVRISP mkii. I updated the devices firmware (to 1.16), and then tried to read the signature of the attiny85. This failed, giving me [ERROR] Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00, ModuleName: TCF (TCF command: Device:startSession failed.). I tried it again, this time with the atmega328p from my arduino, and once again it failed. The ISP clock is dropped to 125 khz (and I've tried lower too). I know both the atmega328p and attiny85 are working still and the fuse bits were never tampered with (the blink program on the attiny from when i used my Arduino as ISP still runs).

Does this mean that my avrisp mkii is dead? All the LED lights behave exactly as expected (LED turns green with power is given to the MCU, red otherwise. USB LED is solid green and flashes when theres traffic). Additionally, it's recognized by both Windows device manager and Atmel Studio 6.

Thanks

• We had problems with the 6-pol ribbon cable on the AVRISP mkii several times. Most of the time this caused sporadic errors and after replacing the cable, it worked again without problems. But some of our programmers are very frequently used (production), so its not so unexpected that at some point the cable gives up after being bend and twisted 1000 times. – Rev Aug 8 '13 at 10:55

There are several possible problems. One is actually udev. If it runs fine calling avrdude with sudo, you have to get your udev stuff right. In Debian Wheezy I have the following line in my /etc/udev/rules.d/56-avr.rules file:

# Atmel AVR ISP mkII
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2104", GROUP="users", MODE="0660"


I guess you can change any appropriate group.

If that's not your error, check your circuit. A common problem is other things are connected to the ISP pin header. If you want to be sure, put the controller somewhere, where nothing else is connected to these pins and try to flash it there.

And finally: check the colors of the LED in the mkII. Errors or warnings are indicated by yellow/orange or red color. If everything is wired up correctly, the LED in the programmer is green.

I had to set the frequency lower to be able to read the correct device signature "-B 5", worked for me.

What is the history of the ISP programmer? If they get over voltage they may fail with your described symptoms. It is usually the front-end IC in them, the MAX-something, that needs to be replaced.

If debugwire is enabled then ISP won't work. In the debugger run the program, and then choose Debugger->Disable Debugwire and close, and then after cycling power to the board, ISP will work again.

Atmel Studio 6 (v6.2.1563 SP2), on Windows 10 (Build 10240)

I have had the same problem on a Attiny13A, with a AVRISPMKII.
I have got multiplye Attiny13A boards here and 2x AVRISPMKII programmers. The problem is with all of these.

the Attiny running on the internal oscilator by default. Could read target voltage but device signature failed to give the correct result.
Have changed the programming speed in the device programming tool, to 64khz, pressed "set" and from this point, device reading and programming works ok.

I'm not really sure why this is but at least I can continue working now.
Hope that this can help anyone.

Carl

Lowering the ISP clock frequency to 1,747 kHz solved the same problem for me.