next topic »

[on:]

I have an USBasp based on ATmega8 which I have never been able to do anything.

The specific model I have is this (that I also got deom DX):

http://dx.com/p/usb-isp-programmer-for-atmel-avr-atmega-attiny-51-board-148046

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

avrdude: warning: cannot set sck period. please check for usbasp firmware update

I have properly selected the correct programmer in the IDE and the USBasp drivers are installed.

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?

Thanks.

[Reply #1 on:]

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 -> SCK
12 -> MISO
11 -> MOSI
10 -> RST/Reset
You 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.

[Reply #2 on:]

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 -> SCK
12 -> MISO
11 -> MOSI
10 -> RST/Reset
You 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.

[Reply #3 on:]

How do I do that, specially specifying that the UNO will be the ISP ? Thanks.

It is explained in the readme file

http://www.fischl.de/usbasp/Readme.txt

avrdude -c usbasp -p atmega8 -U flash:w:main.hex

If you are using Arduino as ISP it would be something like this

avrdude -c arduino -p atmega8   -P com3 -U flash:w:main.hex:i

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

[Reply #4 on:]

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 programmer
since it doesn't support setting the SCK clock rate in the command interface.

With the standard older Fischl firmware that would be jumper J3.


--- bill

[Reply #5 on:]

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

avrdude: warning: cannot set sck period. please check for usbasp firmware update

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.

[Reply #6 on:]

Thanks for the help, guys!

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:

avrdude -c arduino -P \\.\COM7 -p m8 -v -B 1 -U flash:r:originalusbasp.hex:i

The this command line I used to flash my USBasp from the arduino as ISP :

avrdude -c arduino -P \\.\COM7 -p m8 -v -B 1 -U flash:w:usbasp.atmega8.2011-05-28.hex

(I had avrdude.conf, avrdude.exe and the hex file all in the same folder, one I created for this).

This is where things got a bit sour: it flashed, but gave me the following results (just the interesting bits):

avrdude: reading input file "usbasp.atmega8.2011-05-28.hex"
avrdude: input file usbasp.atmega8.2011-05-28.hex auto detected as Intel Hex
avrdude: writing flash (4700 bytes):

Writing | ################################################## | 100% 1.52s

avrdude: 4700 bytes of flash written
avrdude: verifying flash memory against usbasp.atmega8.2011-05-28.hex:
avrdude: load data flash data from input file usbasp.atmega8.2011-05-28.hex:
avrdude: input file usbasp.atmega8.2011-05-28.hex auto detected as Intel Hex
avrdude: input file usbasp.atmega8.2011-05-28.hex contains 4700 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 1.21s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0x3b != 0xdb
avrdude: verification error; content mismatch

avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Two things there worry me:

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.

[Reply #7 on:]

It gets weirder! I decided to flash the fuses to the USBasp, since the fuses for the Atmega8 match those for the Atmega8A, and my USBasp has a 12Mhz Xtal on board.

Take a look at the command I issued and its output below:


avrdude -c arduino -P \\.\COM7 -p m8 -B 200 -U hfuse:w:0xC9:m -U lfuse:w:0xEF:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: reading input file "0xC9"
avrdude: writing hfuse (1 bytes):

Writing |                                                    | 0% 0.00s ***faile
d;
Writing | ################################################## | 100% 0.07s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xC9:
avrdude: load data hfuse data from input file 0xC9:
avrdude: input file 0xC9 contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xc9 != 0x00
avrdude: verification error; content mismatch

avrdude: safemode: hfuse changed! Was c9, and is now 0
Would you like this fuse to be changed back? [y/n] y
avrdude: stk500_cmd(): programmer is out of sync

In other words, it wouldn't let me save the fuses. What gives?!

[Reply #8 on:]

you must add the -u option otherwise avrdude will not change the fuses.

[Reply #9 on:]

you must add the -u option otherwise avrdude will not change the fuses.

Thanks for that, John.

Considering that my fuses are set to 0, do you thing it is a bad idea (or a good one) to try and set the fuses?

Thanks!

[Reply #10 on:]

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.

[Reply #11 on:]

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.

[Reply #12 on:]

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.

[Reply #13 on:]

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.

[Reply #14 on:]

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 #6
and the hex image he is using.
What I see is that the thread started about a question about an sck error/warning message
when attempting to burn a blank AVR
and 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 ..."

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 slower
so 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:

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 work
if 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 can
be 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 faster
and the SCK error/warning can be ignored since the AVR is now running with a faster
external crystal and the faster SCK will not create any issues since the AVR can keep up
with it.

--- bill