Go Down

Topic: usbasp and zombie arduino uno : "cannot set sck period" error of death (Read 3330 times) previous topic - next topic

chaosbc

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.

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.

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 combatability - 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?
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

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....

DrAzzy

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?
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

chaosbc

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...

chaosbc

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

chaosbc

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... :smiley-eek:

DrAzzy

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.
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

chaosbc

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... :smiley-red:
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 :
  <CHIP>
      <NAME>ATmega328P</NAME>
      <FLASH>32768</FLASH>
      <EEPROM>1024</EEPROM>
      <SIG>0x000F951E</SIG>
      <PAGE>128</PAGE>
      <LFUSE layout="2">YES</LFUSE>
      <HFUSE layout="5">YES</HFUSE>
      <EFUSE layout="4">YES</EFUSE>
      <LOCK>YES</LOCK>
      <CALIB>YES</CALIB>
      <PLACEMENT>.\Images\Placements\ZIF_DIP_40.bmp</PLACEMENT>
   </CHIP>

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

bperrybap

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

DrAzzy

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.
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

bperrybap

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

chaosbc

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 :-(

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.

DrAzzy

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?
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

chaosbc

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

Go Up