Is there anyway I can use my UNO do flash my USBasp with the newest firmware from http://www.fischl.de/usbasp/ using my UNO R3 as the ISP ? Will that solve my problem?

Yes, updating the firmware will solve your problem.Connect the Arduino to the header pins on the USBasp as you would when using the Arduino as an ISP http://arduino.cc/en/Tutorial/ArduinoISP 13 -> SCK12 -> MISO11 -> MOSI10 -> RST/ResetYou also have to short together one of the jumpers at the top of the USBasp to put it into self-programming mode.Upload the latest firmware .hex file using AVRDUDE.

Is there anyway I can use my UNO do flash my USBasp with the newest firmware from http://www.fischl.de/usbasp/ using my UNO R3 as the ISP ? Will that solve my problem?

Yes, updating the firmware will solve your problem.Connect the Arduino to the header pins on the USBasp as you would when using the Arduino as an ISP http://arduino.cc/en/Tutorial/ArduinoISP 13 -> SCK12 -> MISO11 -> MOSI10 -> RST/ResetYou also have to short together one of the jumpers at the top of the USBasp to put it into self-programming mode.Upload the latest firmware .hex file using AVRDUDE.

Cookies, sorry for the dumb question, but I've never used avrdude directly. How do I do that, specially specifying that the UNO will be the ISP ? Thanks.

Learn to live: Live to learn. Showing off my work: http://arduino.cc/forum/index.php/topic,126197.0.html

Anyway, I have a USBasp myself and I get the same warning as you, but I just ignore it, it works OK.

While that will work on an AVR that is setup to use a crystal,it won't always work depending on the fuses. i.e. it won't work on new parts using the internal oscillator at 1Mhz.With the old USBASP firmware you have to short out the slow SCK jumper on the USBASP programmersince it doesn't support setting the SCK clock rate in the command interface.

i have also purchased those from dx and there is no need to reprogram your chip. that is only a warning for a feature the firmware does not support. use the -B avrdude option to select clock speed instead. for new chips out of the tube with default 1mhz its rarely but sometimes necessary to slow programming down that way.

I finally got the Arduino ISP sketch working. Somehow during the afternoon it wasn't working, complaining about sync() and the like.

Now, at night, it decided to work (same jumper cables!).

I tried the flashing procedure again. The first downside I found was that my USBasp-clone is not exactly an Atmega8, but an Atmega8A-AU, and the device signature is different. So I did what I did to bootload my Atmega328-PU (note: non-P) with the Arduino bootloader: I edited avrdude.conf to let the Atmega8A signature be the one for the Atmega8.

A few verification runs with avrdude and all seemed ok. Let's flash!

Before proceeding, I dumped the original flash from my USBasp-clone to disk:

a) all the fuses are 0. I had noticed this before, when using only -v with avrdude, but since the USBasp was working, I won't care much about it. I am afraid to set the supposedly proper fuses and "fubar" my USBasp-clone.

b) note the "verification error, first mismatch at byte 0x0000". WTF? The USBasp still works for verifying other Arduinos (I checked it with 2 different arduinos), but I have no idea how this will affect other aspects of its functionalities.

I redid the procedure 3 times (flashing the latest USBasp firmware), and everytime I got the same error.

Any help on these 2 matters?

Thanks.

Learn to live: Live to learn. Showing off my work: http://arduino.cc/forum/index.php/topic,126197.0.html

if your fuses are really set to zero the chip is dead and theres nothing you can do short of buying an expensive programmer with 12v capability. try just reading the fuses. that is always safe. if the signature reads ok that means your fuse is not really zero. if you didnt use the -u before then it is not likely fuses were changed to zero. one must be very careful when changing fuses because that is the #1 way noobs brick their avr.

if your fuses are really set to zero the chip is dead and theres nothing you can do short of buying an expensive programmer with 12v capability. try just reading the fuses. that is always safe. if the signature reads ok that means your fuse is not really zero. if you didnt use the -u before then it is not likely fuses were changed to zero. one must be very careful when changing fuses because that is the #1 way noobs brick their avr.

I can read the device ID and my USBasp-clone works well (except for the annoying "sck period" message). Other than that it can communicate with other devices and other devices (arduino ISP) can communicate with it.

I am wondering if the wrong fuses are causing the "sck period" problem.

Learn to live: Live to learn. Showing off my work: http://arduino.cc/forum/index.php/topic,126197.0.html

A lot of these USBasp programmers from China have the lock bits set so you can't re-program them or read them. You need to check your lock bits on the ATmega8 and see if they have been set. If the lock bits have been set the only way to re-program is to do an chip erase first.

alx is not trying to reprogram his usbasp so none of that is relevant. as i mentioned before the sck period message has nothing to do with the targets fuses and is an avrdude warning that is to be ignored. i would suggest reading this thread from the start, specially my comments, and posting the avrdude output this time while reading fuses. it should tell exactly what is wrong.

alx is not trying to reprogram his usbasp so none of that is relevant.

Uh.... That's not what I see.Most of this thread looks to be about trying to update/re-program a USBasp device.Look at the original post and then again at his comments in response #6and the hex image he is using.What I see is that the thread started about a question about an sck error/warning messagewhen attempting to burn a blank AVRand then asking about using an UNO to update the USBasp device to the latest firmware.Then, in response #6, actually attempting to update the USBasp device firmware with a setup using ArdinoISP.Even the title of the thread is "Fixing USBasp ..."

Quote

as i mentioned before the sck period message has nothing to do with the targets fuses and is an avrdude warning that is to be ignored.

I disagree with this. If trying to program a new part with the factory default fuses, which is using the internal 1Mhz oscillator (which is controlled by fuses), sck period must be slowerso the "warning" is indicating why things are not working.

Also note that the original question relates to burning a blank part is what was stated as being done in the original post:

Quote

Whenever I try to program (either a sketch or burn bootloader on a blank chip) with it I get this message:

The older versions of USBasp firmware used a jumper to slow SCK down, the newer versions support doing this from avrdude.If the clock is not slowed down when using a slow clock in the target AVR, avrdude will abort or get strange errors since it can't talk to/program the part.While I agree that the SCK warning can be ignored in some situations,(like when the target has fuses set up to use an external crystal like a typical Arduino board)the warning message does indicate why things may not be working on a virgin/blank AVR chip.

With the old firmware if you get this error/warning message and things are not working, often everything will workif you simply jumper the slow SCK jumper on the USBasp device.

This is what I do on my USBasp device as I've not gotten around to updating my USBasp firmware so it canbe slowed down from avrdude rather than having to use a jumper.

Once the AVR has been programmed to use a faster external crystal, (which requires changing fuses)the USBasp slow SCK jumper can be removed.Future re-programming of that AVR can now be done fasterand the SCK error/warning can be ignored since the AVR is now running with a fasterexternal crystal and the faster SCK will not create any issues since the AVR can keep upwith it.