Resurrecting Bricked AVRs

The featured picture of this post has been generated by Dall-E.

Three years ago, I wrote a short blog post about AVR fuses and what to do when you brick your MCU by setting the wrong fuse. This included a lot of jumper wires. In order to get rid of the jumper wires, I decided recently to design an Arduino shield that supports resurrecting bricked MCUs, which you can now buy at Tindie.

The initial impulse to design a shield and rework the firmware came when I received a question from a user about how to wire up an ATtiny2313 for high-voltage (HV) programming using my RescueAVR sketch. I thought this could be easily answered. It turned out, however, that I had to scratch my head intensively before I could answer. The reason is that for the ATtinys, two control lines are joined, and it is not immediately clear how this translates into the wiring of the chip. Looking into the code reveals that the XA1/BS2 line is controlled on the UNO side by the pin usually used for the BS2 line.

After looking at the code and documentation that I wrote more than ten years ago, I started to ask questions, such as:

• Where did the data about the MCUs come from?
• Is this data correct?
• Does the sketch really work on all the chips?
• Even on obsolete ones, such as the AT90S2323?
• Are there still uncovered chips?
• And couldn’t we make the wiring somehow easier?

Let us start with answers to the last question. The first thing I did was to provide wiring schemata for all DIP/SOIC chips in Appendix B of the manual. However, one must still plug in 20 jumper wires and a few other components. In addition, one needs an external 12 V source to do high-voltage programming. So, I devised a plan to design an Arduino UNO shield that already has a 12 V source on board, that provides the electronic switch to apply this voltage to the RESET line, and that has a socket with tags for all the jumper wires. After doing that, I asked myself why not putting a few IC sockets on the shield so that the wiring is only needed for SMD parts. So, I did that. In addition, I also designed an adapter board for the IC sockets that did not fit on the shield.

The result looks similar to MightyOhm’s HV Rescue Shield 2, but it can handle all classic AVR chips with a DIP footprint, and the firmware is a bit more powerful. The design data (KiCAD) can be found in the sketch repository. In addition, I made the PCBs and a kit available at Tindie.

With that out of the way, how about the other questions? I must confess that I do not remember how the large table of MCU data evolved. I believe I started with the list of MCUs printed on the silkscreen of my Fusebit Doctor Board. The signatures came from the data sheets, and the default fuse values were copied from the Engbedded AVR Fuse Calculator, which would explain the wrong default fuse values I had for AT90S* types.

So, I decided it was finally time to include all MCUs that could be programmed with HV programming. Using a Python script, which you find in the RescueAVR Github repository, I extracted the data for all MCUs currently supported by the Microchip software from the ATDF files. In addition, I included obsolete chips that had been covered before in the earlier versions of the sketch. For those, I consulted the datasheets. All in all, RescueAVR can now deal with 131 different MCUs (and I have not counted the A and V versions, which have the same signature as the chips without this suffix).

While this is great news, the question remains whether RescueAVR does the right thing when confronted with an untested MCU. Fortunately, I collected many different AVR MCUs that I used to test my hardware debugger. Still, a few were missing, which I ordered from different sources, including Chinese vendors, since I could not find a source in Europe.

I discovered a few bugs and problems when I tested RescueAVR with these chips. The ancient chips with an AT90S prefix deal with the fuse and lock bits in a funny way that is incompatible with the newer chips. Reading the lock and fuse bits is done in one operation, whereby the lock bits are returned as the two most significant bits. Writing lock and fuse bytes is done in two different operations. In addition, some AT90S chips require a different timing for the erase operation. While modern chips require a 150 ns pulse of WR for all write operations, the older chips need at least 5 ms for an erase and 1 ms for writing a fuse byte! Furthermore, the AT90S2313 and the AT90S8515 that I received require that the lock byte be written twice in succession to succeed.

The ATtiny12 appears to allow changing fuse bits even when lock bit LB1 is programmed, contrary to what the datasheet says. I first thought that I had a faulty chip, but it also happened with a second chip. In addition, the ATtiny11 and ATtiny12 sometimes return a zero bit for unused bits in the fuse and lock bytes, a behavior that distinguishes these chips from all the other MCUs of the AVR family. However, all other chips (in particular the obsolete ones) worked out fine, with one exception.

The annoying exception was the ATtiny15, a very obsolete MCU, which has no RAM at all. It seems to be the only 8-pin AVR MCU where the functionality of pins 2 and 3 is exchanged. Since for HV programming of all 8-pin MCUs, either pin 2 or pin 3 is used as the clock pin, one should get away by short-circuiting these two pins. This does not work for the ATtiny15, however. Even worse, even when leaving pin 2 open and using only pin 3, I did not get a response from the chip initially. After carefully examining the datasheet, it turned out that in contrast to all other AVR MCUs, 16 clock pulses are necessary where all the other MCUs need only one clock pulse. For this reason, I introduced another HV programming mode called HVSP for Tiny15. In other words, one can now also program the ATtiny15. However, one needs a breadboard and jumper cables because of the pin 2/pin 3 problem mentioned above.

Having tested the sketch on a much larger set of MCUs than initially, the RescueAVR sketch is in much better shape now. With the wiring schemata, setting up an HV programming breadboard circuit for any AVR chip should be a breeze. Finally, with my newly created Arduino shield, it is even easier.

In the end, three words of caution. First, always upload the RescueAVR sketch before you connect the target chip or plug the RescueAVR shield onto the UNO board. Otherwise, you may risk short-circuiting a GPIO pin that is active high to GND.

Second, when you use the HV programmer, ensure everything is wired correctly or that the chip sits in the right socket with the correct orientation. Otherwise, you may destroy the chip to be resurrected because 12 V is applied to an MCU pin that is not the RESET pin.

Third, it seems that the default fuse values that have been derived from the ATDF files are not always equivalent to what the datasheets say. However, they seem always to be safe. That is, you can use an ISP programmer afterward.

Edit: I added experience with some AT90S chips and the ATtiny15 and recommended uploading the sketch first.