ATTiny84 Issue Figured Out

I’m so glad I bought a logic analyzer a while back. It’s made figuring out the issue I was having so much easier. As I wrote the other day, my ATTiny84 no longer responded to AVRDude. I checked by programmer by uploading a basic blink test to an ATTiny13, and confirmed that the programmer itself was fine. I double-checked connections, and they are all set up. So, it was time to hook up the logic analyzer to see what was going on.

Figure 1: Standard AVRDude AVR programing initialization (the unexpected bytes are common for my setup, and I have no idea why).

I hooked up my logic analyzer to the breadboard setup to check what the ISP programming looks like and what’s happening. Using PulseView, I got the result above. The decoder tells me that the signals being sent are the standard programming enabling command, so I know that the USB programmer is sending the usual commands. Whenever I’ve used the logic analyzer, I’ve always had those unexpected bytes in the reply. I’m not sure why they show up, but I’m sure it’ll have something to do with me not setting things up correctly. Either way, I got those with a succesfull programming sequences as well, so I’m not too worried.

Figure 2: silence on the wire

It’s after the programming enable message that the interesting thing happens; or, more specifically, doesn’t happen. The reset pin gets a high signal, to ready the ATTiny84 for programming, followed by nothing. The LED being powered by the chip doesn’t even turn off as I’d expect it to do when the chip fully resets. This leads me to conclude that the reset pin just isn’t responding. That would make sense, given the AVRDude error message:

avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

This is exactly what I’m seeing, as the programmer is trying to initialize, but it seems to be failing at the reset stage. I assume the programmer would expect some kind of acknowledgement from the chip. Now, the reset pin may not be triggered, but I certainly am at this point (sorry, I couldn’t resist): just before I had this problem, the fuses were changing for some reason. My next step, therefore, is checking the datasheet for fuse settings.

And there we have it: bit number 7 is RSTDISBL, and as the footnote lists, if it is programmed, only high-voltage serial programming will work. I recall the first fuse error message saying something about fuses being set to 0, which ends up programming the Fuse High Byte bit 7 to disable the reset pin. So, I’ve locked myself out of this chip. I’ll have to learn about high-voltage programming to see if it’s worth investing in a new thing to make that work, or whether it makes more sense to just get a new chip.