usbasp and zombie arduino uno : "cannot set sck period" error of death

Hi there.
I bought on amazon this usbasp http://www.amazon.fr/gp/product/B00AVRHVPO?psc=1&redirect=true&ref_=oh_aui_detailpage_o00_s00
the goal is to write the arduino uno bootloader on atmega328p-pu I got for cheap on ebay among other purposes, to bring back my arduino to life (the chip is dead)
Sooo I am on ubuntu and Mac and I have everytime the same error : : “cannot set sck period”
I checked the wiring a hundred times so I don’t know what’s wrong.
Also I know this error can be ignored sometime but trust me : no bootloader has been burnt here
It drives me crazy…I don’t know anymore what else to try…
Thank you in advance for your help.

Cannot set SCK period please update USBASP firmware is a warning, not an error. It does not interfere with programming and can be safely ignored. I have programmed scores of chips with a USBAsp, getting that error every time. Everyone else reports that that message can be ignored, and chips program fine.

Thus, that message is a red herring, and you need to start looking elsewhere for the problem.

When you read out the contents of the flash+fusebits after burning bootloader, what did you see? ExtremeBurner AVR (windows app - but I assume you have a way to get windows app - otherwise read it with avrdude from the command line) makes it trivially easy to attempt reading data off of AVR processors - you don't even have to fart around with avrdude or any of that crap. If that reads it, but shows no bootloader, what about bootloading it with ExtremeBurner AVR? (just 'open' the .hex file from extremeburner, set the fuses on that tab, make sure the "write" box is checked for fuses that needed changing, and do write all)

A sloppy port of a boards.txt file from 1.0.x to 1.6.x will result in it failing to write the hex file - before it used bootloader.path and bootloader.file, now just bootloader.file, and the path must be in bootloader.file (note that bootloader.file must not include the path for 1.0.x). Backwards com*b*atability - and for no apparent reason; there seems to be a pattern in 1.6.x of kicking custom core people in the shins. Failure mode is the same either way (.path and .file on 1.6.x, or .file with the path in it on 1.0.x) - it looks okay, but fails to write the .hex file.

If you can't read the flash with ExtremeBurnerAVR or avrdude - are you using the board in the uno already? (if not, it won't work without a crystal). Could it be that there's something else wrong with the board?

First : Thank you for trying to help me out and for all those info ! I noticed there was an ubuntu version of eXtreme burner which is running on my laptop now 8) So far what I got is : "Cannot communicate with target chip". I am indeed using the Uno body. That said, I will try tomorrow on a windows pc...maybe I did something wrong during the installation....

chaosbc:
First : Thank you for trying to help me out and for all those info !
I noticed there was an ubuntu version of eXtreme burner which is running on my laptop now 8)
So far what I got is : “Cannot communicate with target chip”.
I am indeed using the Uno body.
That said, I will try tomorrow on a windows pc…maybe I did something wrong during the installation…

And you’re using the right ISP header right? (the Uno has two, one for the 16u2, and one for the '328)

That implies that it’s either connected wrong, or the chip’s fuses are set to use an external crystal, but the one on the Arduino board is bad (?!), or to use external clock input (which isn’t present). Could it be that there’s something wrong with the Uno board?

I use the isp which is the closest to the atmega so I really do think it is the good one. Maybe the Uno is dead after all.... I think I will try to make an arduino on the breadboard then connect to the usbasp....you never know...

Ok this is beyond nonsense : I get exactly the same messages with arduino on a breadboard. I really don't get it. :cold_sweat:

OK OK this is getting interresting... I followed the arduino on a bredboard tutorial here : http://www.arduino.cc/en/Main/Standalone First, I believe there is a mistake on the tutorial because during the step where installing the first led, the tuto says pin13 : there is no led at pin13 but well...the photo is right so ...let's say it's another story.

OK, so I completed my breadboard then I jumped to the bootloader part (at the end of the page) and it says :

The MISO pin of your adapter will go to pin 18 or Arduino digital pin 12 of your Atmega chip. The SCK pin of your adapter will go to pin 19 or Arduino digital pin 13 of your Atmega chip. The RESET pin of your adapter will go to pin 1 of your Atmega chip. The MOSI pin of your adapter will go to pin 17 or Arduino digital pin 11 of your Atmega chip.

So I did my first wiring according to the 2nd choice (pin 12, 13 ,1 and 11) : still the same (raging inside !) I don't know why but I gave the 1st choice a test (18, 19, 1, 17) and my activity led (the green one on the tuto) was blinking.

BOOM : I am able to read it from Extreme burner : Low fuse : 0xFF ** **High fuse : 0xDE Lock fuse : 0xCF Calibration: 0xFFFFFF93 (write is never unticked)

I don't know what that mean. So I did Arduino IDE a bootloader test and what I have now is different : Expected signature for ATmega328P is 1E 95 0F

This is really weird because I am pretty sure this is a ATMega328P-PU : I triple checked, it is what I ordered and what is written on the chip I received. How to find the real signature of my chip then ? Maybe if I can get it, I will be able to modify the avrdude.conf and finally burn this bootloader I am clueless... :astonished:

Aaaah - you were counting based on physical pins, but using the numbers for the arduino pins (the arduino pin numbers are not the same as physical pin numbers - google image search for atmega 328 arduino pinout, and you'll get tons of nice images of the arduino pin mapping. On the Uno, the pin numbers marked on the board are the arduino pins - for example, pin 12 (as marked on the board) is connected to physical pin 18.

Doesn't Extreme Burner complain if you don't select the part that matches the signature? What part did you select in Extreme Burner? The ATmega328p and the ATmega328 are not the same. There is both a ATmega328p-pu and a ATmega328-pu. These are not the same.

You can get the signature by running avrdude from the commandline, if that doesn't work.

Yes indeed that is right regarding the pin numbers…for my defense, it was late at night (early in the morning) here…so I guess in the end I mixed up things… :blush:
Indeed Extreme burner told that the chip was not the good one and prompt for confirmation to continue in every parts.
At the beginning, extreme burner did not propose the chip on the menu but I guessed I needed to edit the chip.xml
I proceed with this :

ATmega328P
32768
1024
0x000F951E
128
YES
YES
YES
YES
YES
.\Images\Placements\ZIF_DIP_40.bmp

I found it there http://forum.extremeelectronics.co.in/index.php?topic=2391.0
That said there is a part with the fuselayout.xml in the same post but since I did not find this very file in the Extreme Burner folder, I did not do anything regarding fuses
Sorry, I am really unexperimented with this tool…I try to make it work the best I can

DrAzzy: Cannot set SCK period please update USBASP firmware is a warning, not an error. It does not interfere with programming and can be safely ignored. I have programmed scores of chips with a USBAsp, getting that error every time. Everyone else reports that that message can be ignored, and chips program fine.

This is not totally correct. There are situations where programming will not work.

Here is some additional information. The way the h/w designers implemented the AVR internally, it requires an oscillator/clock of some sort in order to use the ISP programming interface. The speed of of the AVR clock determines the maximum speed of the SCK clock on the ISP port which determines how fast the AVR can be programmed. A given AVR clock speed can only handle a given maximum SCK clock rate. Exceed this and you won't be able to talk to or program the AVR.

A virgin AVR chip is shipped with the fuses set to use an internal clock of 1Mhz. This requires using a much slower SCK clock than can be used when say a 16Mhz clock is used. The default SCK clock rate used by USBASP provides a fast ISP programming but is is faster than what will work with the default 1Mhz clock.

USBASP has the ability to control (slow down) the SCK clock rate, which must be used on virgin AVR chips or any AVR that is using a slow clock like the internal 1Mhz oscillator. The older versions of the USBASP firmware required using a jumper on the PCB to slow it down. The newer versions of the firmware (I say newer but it came out in 2009) still allow setting the SCK clock with jumpers but also with a command over the USB interface so you can set it from avrdude rather than have to use jumpers.

The reason you get the warning is because of the way Joerg wrote the code that intializes the USBASP device when he added the code to avrdude to support the new USBASP commands to set the SCK clock speed. The USBASP firmware has a default SCK clock rate that it uses if you don't tell it otherwise. You can also send it commands to set the clock rate. One of the commands tells the USBASP device to use its default clock rate. The code in avrdude always tells the USBASP device what SCK clock rate to use. If the user does not specify a clock rate when running avrdude, avrdude tells the USBASP device to use its default clock rate. If the USBASP firmware does not support the command to set the SCK rate, avrdude prints the warning. I would not have written the code that way. I would have written it set the SCK rate only if the user asked but not try to set it if he didn't ask. That way you would not get warning unless you explicitly asked to set the rate. i.e. there is no need to set the SCK rate to its default since it will already be at that rate by default.

Anyway, that is why you are getting a warning. avrdude is trying to set the SCK rate and the firmware is old (more than 6 years) and doesn't support this command.

Whether or not you can get away with using the default faster SCK clock rate depends on then environment. So for example, if you are re-programming an already programmed AVR on something like an Arduino UNO, it will work since the fuses will not be their default but will be set up to use the 16MHz crystal/oscillator on the board. However, if you using a virgin AVR or say replacing the AVR on an UNO with a virgin new one, then the programming will not work until you slow down the SCK clock rate since AVR will be using the internal 1Mhz clock. In order to slow down the USBASP SCK clock rate, you must either have the newer USBASP firmware that can be told to use the slower clock by avrdude or you will have to use the jumper on the USPASP device. Nearly all the USBASP devices have the jumpers on them. Many of them don't have the headers soldered on them but the PCB has the holes for them.

--- bill

You can program virgin avr chips with the common, cheap usbasps from eBay, which all give that warning. It may be that they use a lower default clock rate to make sure it works on virgin chips.

I think there is a reason they don't supportt the usb command -maybe they are out of flash, and didn't want to move to the next size up? The cheap ones use an '88, with only 8k of flash.

The USBASP device I bought off EBAY wouldn't program virgin AVRs without inserting the slow/SCK jumper.

There are many different versions of USBASP devices out there and some of them do use old f/w modified to use the slow rate by default. While it allows any AVR to be programmed it also means that until you put in the h/w SCK jumper, it will program slower than it could be when using it on an Arduino board. I bought one a few years ago and it had the old f/w in it. I updated it to the newer f/w and that device used an atmega48 which only has 4k of flash. I also modified the code to change the the LED behavior so that it blinks red while writing and green while reading.

Although with a 4k flash you have to use the code from 2009-02-28 vs the latest code from 2011-05-28. The SCK command was added in the 2009-02-28 release and the code still fits in 4k. The 2011-05-28 code won't fit in the 4k flash; however, with 8k flash there shouldn't be any issues with the newer code.

From my perspective, I see no reason to ship a USASP device with f/w older than the 2009-02-28 release which has the SCK clock rate commands. I attribute it to lazy vendors.

Also, as long as you have another ISP programmer, it is so easy to update the f/w in these devices, I'd be updating the code to gain the functionality as well as eliminate the avrdude warning.

--- bill

Thanks again guys, I am learning a lot.
I tried this

avrdude -c usbasp -p m328p -v -v -v

And this is what I got below…so my main problem so far is I am not able to say what is my chip signature : 0xff95ff or 0x9edfaf or 0x9eff8f ???
The worse is if I run several time this, I will have a new signature every time…I am totally lost :frowning:

chaosbc@chaosbc:~$ avrdude -c usbasp -p m328p -v -v -v
avrdude: Version 6.0.1, compiled on Oct 21 2013 at 17:07:18
** Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/**
** Copyright (c) 2007-2009 Joerg Wunsch**
** System wide configuration file is “/etc/avrdude.conf”**
** User configuration file is “/home/chaosbc/.avrduderc”**
** Using Port : usb**
** Using Programmer : usbasp**
avrdude: usbasp_open(“usb”)
avrdude: seen device from vendor → www.fischl.de
avrdude: seen product ->USBasp<-
** AVR Part : ATmega328P**
** Chip Erase delay : 9000 us**
** PAGEL : PD7**
** BS2 : PC2**
** RESET disposition : dedicated**
** RETRY pulse : SCK**
** serial program mode : yes**
** parallel program mode : yes**
** Timeout : 200**
** StabDelay : 100**
** CmdexeDelay : 25**
** SyncLoops : 32**
** ByteDelay : 0**
** PollIndex : 3**
** PollValue : 0x53**
** Memory Detail :**
** Block Poll Page Polled**
** Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack**
** ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------**
** eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff**
** Block Poll Page Polled**
** Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack**
** ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------**
** flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff**
** Block Poll Page Polled**
** Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack**
** ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------**
** lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00**
** Block Poll Page Polled**
** Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack**
** ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------**
** hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00**
** Block Poll Page Polled**
** Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack**
** ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------**
** efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00**
** Block Poll Page Polled**
** Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack**
** ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------**
** lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00**
** Block Poll Page Polled**
** Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack**
** ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------**
** calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00**
** Block Poll Page Polled**
** Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack**
** ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------**
** signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00**
** Programmer Type : usbasp**
** Description : USBasp, http://www.fischl.de/usbasp/**
avrdude: usbasp_initialize()
avrdude: usbasp_spi_set_sck_period(0)
avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: usbasp_program_enable()
avrdude: AVR device initialized and ready to accept instructions
Reading | | 0% 0.00savrdude: usbasp_cpi_cmd(0x30, 0x00, 0x00, 0x00) => 0x28, 0xb0, 0x80, 0x9e
avrdude: usbasp_cpi_cmd(0x30, 0x00, 0x01, 0x00) => 0xff, 0xfd, 0xb7, 0xdf
Reading | ################# | 33% 0.01savrdude: usbasp_cpi_cmd(0x30, 0x00, 0x02, 0x00) => 0xac, 0xb0, 0xcb, 0xaf
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x9edfaf
avrdude: Expected signature for ATmega328P is 1E 95 0F
** Double check chip, or use -F to override this check.**
avrdude: usbasp_close()
avrdude done. Thank you.

So it's different every time?

How do you have it wired up right now? Is it in the Uno or on a breadboard? If the latter, did you forget the 0.1uf bypassing caps between power and ground?

Yes it is different every time....I gave up with the uno, it is a breadboarduino now :-) errrr between power and ground it is not 10 uf ? ok I gave 0.1uf a test : same result : always different

Lets take a step back.
What is your exact h/w?
I’m assuming you are trying to replace an AVR chip in an UNO board with a new virgin one?

The signature I get when reading a m328P-PU is 0x1e950f
(I attached the avrdude output using a USBASP device connecting to a m328P-PU AVR)

The signature you first read back in post #6 looked correct.
What changed since then?
Since the signature is changing there must be some wiring/connection issue or perhaps a SCK clock rate issue.

I’d stick with the UNO board as it should have everything in place including bypass caps, and a crystal which will be needed once the fuses are changed by burning the bootloader by the IDE.
Using the Arduino PCB instead of the breadboad helps eliminate some potential issues.

Are you using a 10 pin to 6 pin adapter or just running your own wires?

avrdude.txt (7.18 KB)

Yes I am indeed trying to replace my chip with a virgin one (actually I ordered 10 chips so I have some spares) I don't have the 10 pin to 6 pin adapter (not received yet) so I do with my own wires. In post #6, I tried to find out the signature through Extreme burner using the "chip info" menu but I am VERY unexperimented with extreme burner, I suspect this "chip info" to only read what is inside the chips.xml file

Well regarding the arduino uno, I have no problem to go back and test with this board... I'll wire it back with the usbasp and test this command to see what this dudes gives: avrdude -c usbasp -p m328p -v -v -v

0.1uf ceramic right next to chip. You may want another larger cap (any type)

That's really strange - that suggests either a bad connection, or that something fundamental is wrong with the chip.

How is it all wired, exactly?

I quickly tested my uno board and I believe it is dead because of my stupidity. I initially removed the chip to put a ZIF socket instead because I hoped to bootload chips one to one on the uno. But the problem is ZIF socket probably destroyed the uno chip socket because I cannot insert the chip on it anymore. With or without the zif socket (so with the atmega directly on the uno the least worst I can or with the zif socket, it is the same result : avrdude: usbasp_program_enable() avrdude: error: programm enable: target doesn't answer. 1 avrdude: initialization failed, rc=-1 ** Double check connections and try again, or use -F to override** ** this check.**

So my uno is not really reliable anymore. I will by another one but still I have those 10 chips I cannot bootload properly... my my my... :roll_eyes:

You should be able to bootload them on breadboard no problem though...

I don't really understand why it's not working...