Electronics > Microcontrollers

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

(1/3) > >>

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.

Navigation

[0] Message Index

[#] Next page