Warning about burn-o-mat and/or usbtiny programmer - Page 1
Forum section: electronics / general

author: Psi
author_rank: Super Contributor
timestamp: February 20, 2012, 04:20:31 am
content: So i'm not 100% sure where the bug lies but this is a general warning about using burn-o-mat + a usbtiny programmerI'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.

author: amyk
author_rank: Super Contributor
timestamp: February 20, 2012, 08:49:28 am
content: 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.

author: Psi
author_rank: Super Contributor
timestamp: February 20, 2012, 12:48:55 pm
content: 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.

author: Unknown
author_rank: Unknown
timestamp: February 20, 2012, 06:37:57 pm
content: 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.

author: Psi
author_rank: Super Contributor
timestamp: February 20, 2012, 09:27:55 pm
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: February 21, 2012, 01:17:48 am
content: Quotehttp://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/

author: Psi
author_rank: Super Contributor
timestamp: February 21, 2012, 02:32:41 am
content: Quote from: westfw on February 21, 2012, 01:17:48 amI 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.

author: amyk
author_rank: Super Contributor
timestamp: February 21, 2012, 11:41:19 am
content: 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

author: Psi
author_rank: Super Contributor
timestamp: February 21, 2012, 12:28:10 pm
content: Quote from: amyk on February 21, 2012, 11:41:19 amwowi didnt even know that was possible,thats pretty cool

author: westfw
author_rank: Super Contributor
timestamp: February 21, 2012, 05:03:37 pm
content: Quote from: amyk on February 21, 2012, 11:41:19 amOh my! Someone MUST now do a AVR-based microcontroller where you load programs from a front panel...

author: amyk
author_rank: Super Contributor
timestamp: February 22, 2012, 12:41:59 pm
content: I'm not the first to think of doing this...http://ilikebugs.blogspot.com/2006/09/avr-necromancer.htmlhttp://photos1.blogger.com/blogger2/6111/4188/1600/wiring0.1.jpgFor 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.