openrcforums

Yeah, I saw it in this thread, and I tried it already. In my case the avrdude still could not detect the programmer - same "Device not found" error as jbeebo mentioned above

I have never tried it with your particular hardware. I have taken a working usbasp and flashed with the 'usbasp' version of firmware from here
http://www.obdev.at/avrusb/avrdoper.html

I tested it on win8 and it worked without a driver. I was going to investigate further until I found out that the 'zadig' application could install working usbasp drivers in win8 ,hence I quit checking out the avrdoper firmware.

as far as your problem . it shouldnt matter what firmware is on the chip you should be able to reprogram it if the wires are hooked up properly, the reset is held. If the fuses are mangled it may require a very slow programming speed or possibly even an external oscillator. the -F option of avrdude really can mangle the fuses. At this cost point the easiest thing would be to purchase another programmer. But if you like a challenge

Perhaps the firmware on my device is different and is not compatible with avrdude at all... Getting another USBasp is the easiest and the most efficient way, indeed. It's just since I have this one already available, I'd like to try and fix it.

An external oscillator is on my list of things to try. But if Atmega starts up and works fine (as the programmer is detected in Windows when plugged into a USB port), may it still be the clock / oscillator problem?

That is a good point. if it runs as a programmer I would think the fuses are correct for programming. If I recall you have double checked your wiring and tried to slow the programming down with the -B option. I have heard of cases where all of the ground pins on the idc 10 arent actually connected to ground. Maybe you could double check the ground connection ?

I did see on the comments in this post that others have had trouble reprogramming the device
http://www.sciencetronics.com/greenphotons/?p=938

I guess my next step would be to trace the lines out and create a schematic of the device

So far I triple-checked the connections:

Pins 4,6,18,20 = VCC (not sure why there are so many)
Pin 14 and 29 = Reset
Pin 15 = MOSI
Pin 16 = MISO
Pin 17 = SCK
Pins 3, 21 = Ground

I checked the voltage - 5V comes to the chip. It means that VCC and GND are connected.
Also, MOSI, MISO and SCK are connected directly to the programming header - there are no elements that could influence their signals.
RST is also directly connected, but there's also an LED between the RST and VCC. It blinks when a Reset is coming, meaning that Reset signal comes through...

It all looks like everything is just right for Atmega to respond to an external programmer - but it doesn't!

Do you know if there's a way to set fuses so that the chip will work but will not respond to flashing (or reading flash) attempts at all?!




EDIT:
I think I know what could be causing such a behavior (though I'm still not absolutely sure). In case "RESETDISABLE" fuse is Enabled, the chip will not be accessible to an external programmer, but will execute the code that was previously flashed. Sounds quite like my case...

What I don't know is how to reset fuses in such a situation... I guess an external oscillator won't help here. Something like an STK500 could probably do the job, but I don't have access to one and buying it to just restore an $3 device is ... hmm... is this called "irrational"?
There is also something discussed on this page, but I don't see the attachment these people are discussing (perhaps a registration is needed).

Another option is to buy a new Atmega. It's an ATmega8A-MU in a tiny QFN32 package... ugh, good chance to improve my soldering skills...

i looked at the datasheet for the atmega8L . Most of my replies come from referring to this doc.
http://www.atmel.com/Images/Atmel-2486- ... asheet.pdf

Re:
pin connections. These look good. Yes there are several I think to keep current draw down per pin and some of those pins are for reference voltages

Led on reset line. well an LED is a diode and it does have a voltage drop across it. It may make a difference depending on how it is connected betwen pins 14 and 29. The reset has to be held low throughout programming ( page 230 from above link)

disable serial programming: Yes it is possible but it would have to be repaired using high voltage programming. Can not be changed with serial programming. I doubt that this has been done but there are 2 fuse bytes that could accomplish it. Reset Disable, and Serial programming enable

taken from above link, pg 216

Table 87. Fuse High
Fuse High
SPIEN (1) Enable Serial Program and Data
RSTDISBL (Select if PC6 is I/O pin or RESET pin 1 (unprogrammed, PC6 isRESET-pin)

1. The SPIEN Fuse is not accessible in Serial Programming mode

The LED is not exactly on Reset line, it goes from Reset to ground via a resistor (initially I thought it goes to VCC, but I guess I was wrong). I just checked with a multimeter: when the device is powered up the reset line is HIGH. When trying to program the Atmega, it gets LOW. So everything looks good from this perspective.

I just ordered a new ATmega8A-MU, will grab the chip on Monday...

If RSTDISBL has been programmed you need to use "High Voltage parallel programming" to "unprogram" it.

Yes, a STK500 can do that!

Mike.

Thanks, Mike!
As I said, I don't have an STK500. So I think the cheapest way for me is to replace the chip with a new one - that's what I'm going to try on Monday...

Success!!!

Replacing Atmega fixed the issue - the new one flashed without any Voodoo techniques!

It means the original Atmega WAS locked. And that's likely the reason for some people failing to reflash this specific programmer.

One extra note (in case someone with a similar issue will find this thread): on the photo I posted above there are jumpers called A and B. These need to be removed - either before reflashing or after - the sequence doesn't matter. Just remove the solder so that the two pads underneath each of these will not be in contact. In my case these were even more obvious - there were two tiny 0 Ohm resistors that I had to unsolder. After that, a regular unmodified USBasp firmware works great, as well as the "optimized" one posted by Romolo.

Congrats. Glad you got it going.
It surprises me that the original mcu was locked. I would have guessed that avrdude would have responded to a programming request with a 'device not found' instead of an 'invalid signature' if either RSTDISABLE OR SPIEN fuses had been modified to inhibit programming. But i have no experience with these settings.

What purpose did the 0 ohm jumpers provide ?

Well it did say 'device not found' ("Target doesn't answer" to be precise).
The 'invalid signature' message coming afterwards was a result of the '-F' key that I tried at that time. Sorry if this was misleading.

The 0 ohm jumpers are for the "USBISP" firmware this thing came with. That article on sciencetronics.com states the following:

the modified design also connected USB-D- to PD3/INT1, the rather aggressiv definition of output pins leads to a unsolveable conflict, when suddenly PD2 is driving against the USB signals from the host!

So if the jumpers are there, the device is not detected by Windows at all when used with the native USBasp firmware. There is also a modified USBasp firmware on sciencetronics page that defines unused ports as inputs, so that this design doesn't cause any issues. But I find it easier to just remove the jumpers and stick with a rock-solid firmware from Romolo.

thanks for the clarifications, it all makes sense to me now. Good job on getting it going.
I also use firmware that is similar to the Romolo firmware on this forum.