The plan to blow all the fuses

The aims of this mini project are quite humble: Build an out-of-circuit parallel mode programmer lite which can whip a borked avr back into something like its factory condition ready for in-circuit programming. At the moment I'm going to concentrate on one chip only and if it all works, and there's sufficient interest, I'll think about expanding the scope.

I'm not going to go into depth - this is just really a sketch of what's happening in my bonce right now. I'll be abstracting quite heavily and using my own terms because it doesn't make sense to just repeat all the detail in the datasheets. Code and schematics will be posted as and when available.

All the information I needed for V0.1 is in the atmega32 data sheet. It looks like it'll be quite easy to reset the fuses.

I've come across a design for a parallel port programmer which looks like it would be simple to build but I don't relish the thought of soldering up yet another DB25 connector. So I've decided to drive this project with an Arduino. I'm imagining nothing more than a socket on some stripboard connected to some header pins that will mate with my Diecimila, some power regulation and switching. I would have built a shield but for whatever reason the designers of the board decided to use a non-standard spacing between 2 sets of sockets which makes building shields on protoboard difficult. Grrrr.

The procedure will simply be:- Erase chip, reset fuses. Job done. The chip erase step has the effect of resetting any lock bits. As one of the locks controls our ability to write fuses this is essential. The state of the EEPROM will be indeterminate after this step, however, as there is a fuse controlling whether the erase cycle also clears EEPROM. And we don't know how this is set.

There are two ways to enter high voltage programming mode. The first involves gently tickling a port but it relies upon the clock settings for the chip being set to external. I think this might have been how I borked my chip, but as I couldn't ressurect it with an attached clock signal this could well not not be the case. So I'm going to go for the second method. Brute force!

Powering up the target with 12v @ 250uA on its reset line, logic low on four specific pins and a wait of 100uS should be enough for it to become willing to accept programming commands. Which are loaded thus:

• Set the 'mode select' pins to 'load command'.
• Present the desired command to the DATA pins.
• Pulse the clock pin to latch the command. All pulses need to last at least 250nS.

Commands are executed by giving a pulse to ~wr. Progress can be tracked by monitoring the rdy/~bsy pin, which will go low until the action has finished.

Addresses are loaded in the same manner, we just substitute 'load address' as the mode.

All the dirty details of the required pulsing is clearly outlined in the timing waveform diagrams in the data sheet.

In order to check how the hardware and code is functioning I'll read the signature bytes of the chip as my first step.

• Load the 'read signature' command.
• Load the address of the desired signature byte, 0-2, to be accessed.
• Set ~oe low.
• The target presents the requested byte on the DATA bits.
• Set ~oe high.

When this is returning what I expect then we'll start on the fuses. First though - some erasing.

• Load 'erase chip' command.
• Pulse ~wr.
• Wait for the command to complete. This will take between 7-9mS.

Once this is done happily then we're ready to blow the fuses! We'll do low, then high.

• Load the 'write fuse' command.
• Load DATA with the low fuse byte.
• Give ~wr a pulse and wait for rdy/~bsy to indicate the process has completed.
  

For general write operations this will take between 3-5mS.

• Load the 'write fuse' command.
• Load DATA with the high fuse value.
• Give ~wr a pulse and wait for rdy/~bsy.

And that should be that!

I'll let you know how I get on :)

Here's an untested arduino sketch that I've hacked up, which should give a better idea of the specifics. It should be read in concert with the data sheet chapter 'Memory programming'.

/* CUT DUE TO ITS TEMPORARY NATURE - PLEASE SEE LATER POST */

Retro Heaven

I've just hacked together an MMC2IEC interface on my breadboard. Thanks Lars!


It's a serial device that pretends to be a commodore 1541 disk drive. It uses SD card storage and disk images to deliver retrogaming goodness to my '128. This is #4 of 4 in my old computers that I've added flash storage to series. Seriously - if you have old computers and a few spare hours it's worth the solder burns.

Having got that device working in its original Lars form I noticed that the open source design has been picked up by a couple of other bods who have taken it to another level. Details are scant, unless you speak German, but I've managed to scrape enough information together to upgrade Lars' original hardware design with some improved firmware called SD2IEC. This supports many more features such as high capacity cards, disk switching, some fastloaders and JiffyDos which should speed things up considerably. Which if you've ever used a C64 disk system you'll know is a must. Some details in English are here.

During the process of upgrading I managed to half-brick an AVR chip. Unlike PICs they are easy to render unprogrammable by changing their configuration fuses in an an unfavourable way. My mistake was not reading the output of this avr fuse calculator carefully enough. Instead of making the AVR desire an external resonator, I made it lust for Clock. Which is different. I've done this a couple of times before with some 168s. In the aftermath of that embarrassing mistake I did some research and found that usually these chips can be resurrected.

If you program a chip to expect a clock, then it should be possible to reprogram it as long as the relevant signal is present. I usually program chips in a little home-made ISP cradle which doesn't have a clock available. For the 168s it proved possible to get them going again by dropping them in my Deicimilia board before attempting to reset the fuses.

The mega32 hasn't responded to this trick though. I used an Arduino to provide what I thought was a good clock to no avail. It's going to need something a little more ... high voltage. AVRs can be programmed using SPI in-circuit, or by more conventional parallel means out-of-circuit. Programming serially you need a well configured support circuit for the chip. Using a parallel programmer you can reset fuses that would prevent SPI from working. So here's my next project - an avr fuse reset device. A cut-down high voltage parallel programmer that only has one job - to reset the fuses to a factory fresh state. Insert AVR, press button, bingo! At least in theory :)

I'm off to grab some of Atmel's brilliant application notes. Then it'll be time for a nice sit down and some strawberry cheesecake.