I tried soldering together that perfboard prototype I mentioned the other day, though it did not go well. My main issue is that I still can’t properly make those nice, clean solder lines on the underside of a board. As a result, my entire plan backfired, and so I tried using multiple jumper wires on the topside of the board. Let me tell you, improvising while soldering rarely works out for me. Perhaps it’s easier to do when you’re far more experiences, but for me it results in a large mess, and right now the board does not work.
In all likelihood, I’ve made some soldering error as I tried retooling the schematic on the fly. Some other day I’ll try tracing all the wires to see which one(s) I forgot, or which ones aren’t connected properly. Far more relevant, though, in my consideration, is that I’ll need some solid practice into making nice solder lines. Either I’m struggling against the surface tension of the solder or I’m accidentally bridging gaps between adjacent pins (while I’m struggling against the surface tension). Yet when I see some videos on YouTube, some people seem to have no problem with it at all. I just don’t know what I’m doing wrong here yet, and I think I may juat start soldering some random wires just to practice this better. It seems to me that this is a major factor holding me back in doing better projects right now.
Success! The HV programmer worked like a charm! For only about three Euro of additional components I threw together the basic design, replacing components where necessary (my local shop doesn’t sell microchips, as online stores has made that highly impractical for the owner). The biggest thing missing, though, was a DC jack that could be mounted on the perfboard. so, I’ll have to fumble some solution to work for my setup.
In any case, a quick upload to the ATtiny13 I’m using as HV programmer, and a quick reset of the ATtiny84 later, and the reset disable fuse is reset again! It felt amazing building my own tool to repair an issue I ran into, even if I did essentially assemble somebody else’s work.
I set to work retooling it to put on perfboard, as I’m sure this won’t be the last time fuses get screwed up. Instead of making separate reprogrammers per 8 or 14-pin chip, I figured to combine the two in one:
Figure 1: the schematic for the combined reprogrammer.
I then used KiCAD PCBNEW setup at a grid of 2.54mm with 1mm trace width to plan out my perfboard:
Figure 2: The perfboard layout made in PCBNew.
The green lines denote the back of the perfboard, and my intention is to have those be solder lines, where the red lines are jumpers on the top of the board. I’m curious to see whether that one near the LED will interfere with it too much. I’ll be testing a method to guide my solder bridges on the back using a stripped copper wire as a guide. I hope to give it a good test tomorrow to see how it works out.
After some searching online, I managed to find a blog post where somebody built an HV programmer to fix pretty much exactly the issue that I’ve had as well. While programming their AVR chips through a USBTiny, they accidentally set the reset disable fuse, locking themselves out of the AVR programming. They point out exactly the frustrating part of that: the microchip is perfectly fine – it absolutely works, and could be used still. It’s just that SPI programming is unavailable. Now, the post is from 2008, so the claim that there are few to no HV programmers are available might be quite outdated (I hope so, at least). I’ll first try to find a cheap programmer, but at least I now have an alternative available as well.
EDIT: In fact, I’ve found another blog post with an even easier solution. That looks like one I’ll put on a bit of perfboard, as I doubt this will be the last time I run into this problem.
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.
Following up on my earlier post about the USBTiny failure to upload via AVRDude, I just did a quick test to see if I could upload a basic blink program to my ATTiny13. When I detached the cable from the ISP connector I’d sloppily soldered together, I noticed that the connections were loose – a glimmer of hope that the problem might be simple. So, I grabbed some jumper wires and hooked everything up again without the connectors. Sadly, no luck. When I wired up an ATTiny13, however, and cobbled together your average blink program, the upload worked just fine.
So, the good news is that the USBTiny itself is okay, and can still be used as an ISP programmer. Other good news is that I’m now closer to finding out the actual root of the problem. The way I see it, the options are as follows:
The USBTiny programmer is broken; or
The connections to the ATTiny84 are broken; or
The breadboard has faulty connections; or
There is a problem with the ATTiny84 itself.
My next test will have to be to put the ATTiny84 on another breadboard and try a basic blink sketch on it. That should determine whether the problem is with the ATTiny84 itself, or the other components. I sincerely hope that the blink sketch will work out, because that’ll be quite a simple problem to solve.
However, what’s far more likely a scenario, considering that I had odd error messages about the fuse settings just before I started having this issue with the chip, is that the fuses are messed up in some manner. I’ve been doing some cursory reading online, and one thing that might have happened is that the fuse bit that enables the reset pin is turned off, which means that the ISP programmer can’t initiate the programming sequence at all. Apparently, there may still be a method to rectify this, but it’s a method I don’t know (more opportunities to learn!).
