Warning about burn-o-mat and/or usbtiny programmer

[Psi]

So i'm not 100% sure where the bug lies but this is a general warning about using burn-o-mat + a usbtiny programmer

I've been working on a project for a few months using an ATMega165a and over that period 1 micros stopped responding to SPI programming after i updated the code (not fuse bits).
At the end of the project, when i went to flash all 30 of my ATMega165a chips with the working program i had only just started (6/30) and already 2 more had died in the same way as the first.
At that point i switched to avrdude directly as well as a direct parallel port programmer and the 24 remaining chips all flashed fine.

The issue seems to happen when programming flash data to the micro. burn-o-mat comes up with a yes/no error about fuse bits not being correct any more. (behind the scenes avrdude checks them at the start of every programming cycle and then again at the end just to verify they haven't been changed by accident). Every so often it comes up saying they have been changed and asking if you want to change them back. Since burn-o-mat is calling avrdude in the background it answers this question automatically. (however, i'm not sure which its doing, yes or no)

In any case after that has happened all 3 of these micros end up in the same state.
They wont program any more and the built in RC oscillator runs at double it's rated clock speed. (when i say double i mean the RC in that micro is rated at 8mhz and it starts running at unsupported 16mhz. Probable due to some other undocumented fuse bit being corrupted too).

So just something to be aware of. It could be a problem with burn-o-mat or with the usbtiny firmware or with the interactions of both.

[amyk]

It should be possible to get them back into a usable state by issuing a chip erase and setting all the fuse bits back to defaults in parallel (+12V) programming mode.

[Psi]

Yeah, unfortunately there aren't any cheap or easy to build parallel AVR programmers.

Only thing i could find was one windows app designed to recover a attiny2313 through parallel programming mode using the printer port but it was hardcoded for that mcu only.

[alm]

I believe there's at least one fuse reset circuit based on an Arduino available, and I think also a plain AVR one. Shouldn't be too hard to port to another similar AVR. Don't remember if it does HVPP or HVSP, however.

[Psi]

I'm not really concerned with trying to fix the three bricked mcus. I've finished the project and all is good.
I had 4 spare anyway, so it didn't cause any issue.

Just a warning to others using the same setup.

[westfw]

unfortunately there aren't any cheap or easy to build parallel AVR programmers.

http://mightyohm.com/blog/products/hv-rescue-shield-2-x/ (but you'll need an Arduino  :-) )
http://hackaday.com/2010/05/17/magically-repair-avr-chips/

[Psi]

unfortunately there aren't any cheap or easy to build parallel AVR programmers.

http://mightyohm.com/blog/products/hv-rescue-shield-2-x/ (but you'll need an Arduino  :-) )
http://hackaday.com/2010/05/17/magically-repair-avr-chips/

I wonder if it can unlock a ATMega165a, they aren't very common.
AVRdude didn't know about it at first. I had to edit the xml files and add an entry for it.

EDIT: nice, it looks like it does.

[amyk]

I've "manually simulated" a parallel programmer using a bank of DIP switches and a PC power supply (+12V, +5V). Just follow the directions in the datasheet and flip the switches accordingly. Not the most enjoyable thing to do but if you're desperate to get a chip back to the defaults and dont' have anything else, it works if only a little tedious. Fortunately there is no minimum frequency to do this at -  it sort of reminds me of the old days where you loaded each byte into RAM using front-panel switches on the computer

[Psi]

I've "manually simulated" a parallel programmer using a bank of DIP switches and a PC power supply (+12V, +5V). Just follow the directions in the datasheet and flip the switches accordingly. Not the most enjoyable thing to do but if you're desperate to get a chip back to the defaults and dont' have anything else, it works if only a little tedious. Fortunately there is no minimum frequency to do this at -  it sort of reminds me of the old days where you loaded each byte into RAM using front-panel switches on the computer

wow
i didnt even know that was possible,
thats pretty cool

[westfw]

I've "manually simulated" a parallel programmer using a bank of DIP switches and a PC power supply ... it sort of reminds me of the old days where you loaded each byte into RAM using front-panel switches on the computer

Oh my!  Someone MUST now do a AVR-based microcontroller where you load programs from a front panel...

[amyk]

I'm not the first to think of doing this...

http://ilikebugs.blogspot.com/2006/09/avr-necromancer.html
http://photos1.blogger.com/blogger2/6111/4188/1600/wiring0.1.jpg

For it to be absolutely reliable you should debounce the clock input, but for me it didn't matter much because I only needed to issue the chip erase and write fuse commands.