Pro Mini programming with USBasp

I’m not really sure if this is intended behavior, or something is wrong. I’ve tried to program Arduino Pro Mini using USBasp programmer I bought from eBay. Every connection is okay. As soon as I connect USBasp to USB (and Pro Mini is attached to USBasp), LED on pin 13 on Pro Mini starts blinking really, really fast. Do note that I can program the chip with no issues. I’ve uploaded basic blink sketch to Pro Mini using USBasp, but LED 13 is blinking really fast, so nothing changed. Then I tried to unplug Pro Mini from USBasp, and tried to power it using only +5V and GND connections, and LED was blinking like in sketch I’ve uploaded, meaning that code is running just fine. I don’t know why the LED blinks all the time insanely fast while Pro Mini is connected to USBasp. Here’s output from avrdude:

D:\Applications\AVRdude>avrdude.exe -c usbasp -v -v -pm328p -u -U flash:w:Blink.
hex

avrdude.exe: Version 6.1, compiled on Mar 13 2014 at 00:09:49
             Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
             Copyright (c) 2007-2014 Joerg Wunsch

             System wide configuration file is "D:\Applications\AVRdude\avrdude.
conf"

             Using Port                    : usb
             Using Programmer              : usbasp
avrdude.exe: seen device from vendor ->www.fischl.de<-
avrdude.exe: 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
               flash         65     6   128    0 yes     32768  128    256  4500
  4500 0xff 0xff
               lfuse          0     0     0    0 no          1    0      0  4500
  4500 0x00 0x00
               hfuse          0     0     0    0 no          1    0      0  4500
  4500 0x00 0x00
               efuse          0     0     0    0 no          1    0      0  4500
  4500 0x00 0x00
               lock           0     0     0    0 no          1    0      0  4500
  4500 0x00 0x00
               calibration    0     0     0    0 no          1    0      0     0
     0 0x00 0x00
               signature      0     0     0    0 no          3    0      0     0
     0 0x00 0x00

             Programmer Type : usbasp
             Description     : USBasp, http://www.fischl.de/usbasp/

avrdude.exe: auto set sck period (because given equals null)
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware up
date.
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.05s

avrdude.exe: Device signature = 0x1e950f
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be per
formed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: auto set sck period (because given equals null)
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware up
date.
avrdude.exe: reading input file "Blink.hex"
avrdude.exe: input file Blink.hex auto detected as Intel Hex
avrdude.exe: writing flash (180 bytes):

Writing | ################################################## | 100% 0.17s

avrdude.exe: 180 bytes of flash written
avrdude.exe: verifying flash memory against Blink.hex:
avrdude.exe: load data flash data from input file Blink.hex:
avrdude.exe: input file Blink.hex auto detected as Intel Hex
avrdude.exe: input file Blink.hex contains 180 bytes
avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 0.16s

avrdude.exe: verifying ...
avrdude.exe: 180 bytes of flash verified

avrdude.exe done.  Thank you.

LED is connected to SCK. So any SPI activity will cause the LED to blink while the SPI clock pin is active.

Ah, I see, thanks. What does that "cannot set SCK period" error even measn then? Because I can upload new firmware on chip just fine. Also, how can I check fuse settings with avrdude? It lists all three as 0.

I don't know on both. Did you check for usbasp firmware up date?

You can also run Nick Gammon's sketch, it will read the fuses. http://www.gammon.com.au/forum/?id=11653

kustom: Ah, I see, thanks. What does that "cannot set SCK period" error even measn then?

there is no sck "error". it is a warning only and should be ignored. there are literally thousands of complaints about this on the internet and in many cases programmers are returned to seller for no reason. lots of them are bricked trying to fix a problem that does not exist. they should change that warning but unfortunately most sellers dont even know what usbasp is or whats its for.

kustom: Ah, I see, thanks. What does that "cannot set SCK period" error even measn then? Because I can upload new firmware on chip just fine.

They all say that.

But who cares about that if the sketches are uploading?

kustom: Also, how can I check fuse settings with avrdude? It lists all three as 0.

avrdude -v ... (add all your folder settings, etc, here)

john1993:

kustom: Ah, I see, thanks. What does that "cannot set SCK period" error even measn then?

there is no sck "error". it is a warning only and should be ignored. there are literally thousands of complaints about this on the internet and in many cases programmers are returned to seller for no reason. lots of them are bricked trying to fix a problem that does not exist. they should change that warning but unfortunately most sellers dont even know what usbasp is or whats its for.

To say that it isn't a problem and should be ignored is an overstatement. It may or may not be an issue for programming, depending on the environment.

and fungus, this warning message is not issued when using all USBasp devices.

The warning is due to using outdated USBasp firmware with a newer version of avrdude.

If virgin AVR chips are to be programmed a slow sck clock period MUST be used. This means that setting the sck period may be very important and depending on the firmware in the USBasp device it may or may not be possible, and might require setting a jumper.

Here is what the warning really means. Unfortunately the way the AVR is designed, it uses the MCU clock that is controlled by fuses when ISP programming. So depending on how the fuses are configured, that clock can be literally anything. It could be using the internal oscillator at 8mhz, or 1Mhz, or using an external clock from a crystal or oscillator.

When programming using ISP, the data can only be clocked in at a particular rate using sck. The maxim sck clock rate is based on the MCU clock rate and there is no way to know what the MCU clock is from the ISP pins. This means that if the MCU clock is say 1Mhz you can't clock in (and hence) burn an image as fast as when the MCU clock using an extern crystal at 16Mhz. And if you attempt to burn an image when the MCU clock is 1Mhz using a fast sck, it will fail.

Keep in mind that a fresh/virgin AVR is shipped with the fuses set to 1Mhz internal clock so the initial burn of fuses and program must be done using a slow sck clock period.

Different ISP programmers handle this differently. Some simply always use a slow clock on the ISP interface. While this always works, it is will be noticeably slower on larger images that it could have been when the MCU is clocked at 16Mhz.

The USBasp firmware originally handled this by having a jumper. If you look at the schematic you will see JP1 labeled as "slow SCK". The firmware defaulted to using a fast SCK but could be told to slow down by installing the "slow SCK" jumper.

From what I've seen most of the USBasp devices out there, have firmware that supports this jumper and have the jumper on the boards. Unfortunately, many of the USBasp boards have the solder pads for the jumper but don't have the 2 pin header soldered to the pads to actually use it. But it can usually be added by simply soldering a 2 pin header to the pads.

The newer versions of USBasp firmware still retain this jumper setting/option but also have added new USB commands to allow setting the sck clock period from the HOST/PC. In the newer firmware, the jumper still overrides the clock. So if the jumper is installed you will get the slower clock regardless of whether the command was sent to set the sck period. Avrdude has been updated to use these new USB commands to set the sck clock period. When a USBasp device is using the older firmware, these new USBasp commands will fail and that is what the avrdude warning is telling you. It is saying: "Hey, I tried to set the sck clock period, and your USBasp device doesn't support it, because of this, the programming may or may not work".

avrdude issues the mentioned warning whenever there is an attempt to set the USBasp sck clock and the command fails.

Unfortunately, the newer avrdude code will always attempt to set the sck clock for USBasp devices even if you don't explicitly use the -B option to ask avrdude to set the rate. So the warning will always be seen when using a newer avrdude with older/outdated USBasp firmware even if not trying to set the sck clock using -B

The irony is that the USBasp command that is being sent to the USBasp device to set the sck clock when the user is not using -B really doesn't do anything and isn't needed. It attempts to set the sck period to its default clock, which the USBasp device is already using. A better approach would have been to not send the USBasp command set the sck clock rate unless the user explicitly asks to set it. Then there would be no warning unless -B was being used, in which case the warning would be appropriate. If you want this behavior changed, you should file a bugtracker report for it on savannah: https://savannah.nongnu.org/projects/avrdude

Now the tricky part of all this, is that when buying these USBasp devices off Ebay you never really know what firmware you have. Compounding this, is some vendors modify the firmware. They can make simple modifications like changing the AVR pins used for jumpers to more substantial changes like changing the behavior of the sck clock or its jumper.

The one I purchased had old firmware it in. I updated the firmware to the newer firmware. It is isn't difficult to do, but you do need another ISP programmer to do it. In my case, I also modified the firmware to change the way the LEDs worked. While ISP programming, I use a red LED to indicate writing and a green LED to indicate reading. It is nice to see the burn (flickering red LED) and the verify (flickering green LED) happening.

So back to whether this is an issue or not... The answer is "It depends". If you have a USBasp device with non original/modified firmware that always burns the images slow, then ISP updates will always work. And you can burn virgin AVRs as well as AVRs that are using the standard Arduino 16Mhz cystal.

If you have a USBasp device with older firmware that doesn't support setting sck over USB, you won't be able to burn virgin AVRs using -B to set sck to a slow rate and will have to use the JP1 jumper to slow down sck. If you board doesn't have a slow sck jumper, you will have to add it. If you board doesn't have the pads for it, you will not be able to burn virgin AVRs. But, you will be able to burn the AVRs once they have their fuses set for a faster MCU clock and/or are using the Arduino standard 16Mhz crystal.

If you have a device with modified firmware, "it depends" on what they have done.

Having the later firmware is really nice since it allows you to use the -B option to set sck so you can run fast or slow without having to resort to using a hardware jumper. And you can set the sck speed to allow the fastest possible burn for the MCU clock you have.

Unfortunately, there is no way of knowing what firmware is in your USBasp device unless you build and burn your own firmware. This can be difficult on Windows machines since Windows was/is not designed for s/w development and so it doesn't come with the necessary tools. It can be done on Windows but it requires setting up the unix tools. Actually all the needed unix tools come with the Windows Arduino IDE, but the environment will need a bit of tweaking to actually use them.

--- bill

Good stuff.

So - and of course I would not try this using Windoze - where is your up-to-date code for the USBASP devices and a description of how else it differs from the previous? May I presume it is also 2560-able?

Paul__B: Good stuff.

So - and of course I would not try this using Windoze - where is your up-to-date code for the USBASP devices and a description of how else it differs from the previous? May I presume it is also 2560-able?

Was this a question for me? If so, I don't understand the question(s). --- bill

bperrybap: Was this a question for me? If so, I don't understand the question(s).

Most certainly.

If you have generated an enhanced firmware for the common, cheap ISPasp devices which has more convenient use of the indicators and other improvements, is it publicly available, if so where, have you described your other enhancements to it and does it program the 2560 as well where the common ISPasp devices fail to do so?

I have not made it publicly available. All I did was a small tweak to Fischl's 2011-05-28 stock firmware to alter the way the LEDs worked. It doesn't add any additional new functionality or change how it works other than the color of the LED during writes vs reads.

It is 4 lines of code changes.

--- bill

Paul__B: Good stuff.

So - and of course I would not try this using Windoze - where is your up-to-date code for the USBASP devices and a description of how else it differs from the previous? May I presume it is also 2560-able?

Well first one must identify if their specific USBasp is of the design that matches the firmware attempting to upgrade, unfortionaly not all USBasp devices except the same firmware release. There are sellers that have and ship USBasp programmers that have updated firmware, but most don't have a clue what they are actually selling.

Lastly I don't think any USBasp programmer can handle above the 128KB (64K words) flash memory size limit, so don't work correctly with 2560 boards. My USBasp works fine with my 1284P board with it's 128KB (64K words) flash size,, and I don't own a 2560 board but have had many report problems trying to use a USBasp programmer.

all these issues have been discussed here a million times. well... maybe thats an exaggeration... really only half that many. 400k tops. in my experience there is no problem as long as you go for the cheapest $2-$3 usbasp and avoid those oddball fancy metal case with built-in coffee maker versions. out of literally hundreds of cases the only real issues were caused by those who felt the need to update firmware that didnt need updating. a complicated and expensive procedure that often results in a truly bricked programmer.

"if it aint broke then fix it til it is" syndrome. or maybe ive just been unbelievably lucky.

and btw there never was a usbasp problem with >128k memory. maybe you are confusing it with mkII or tinyisp which did have some noobs jumping through hoops..

john1993: out of literally hundreds of cases the only real issues were caused by those who felt the need to update firmware that didnt need updating. a complicated and expensive procedure that often results in a truly bricked programmer.

There are real world issues related to trying to burn a virgin AVR that is using the default 1Mhz internal clock. It has to be done at a slower SCK clock rate than most USBasp devices use by default. So there are case of real world issues that have come up in threads where users have not attempted to alter their USBasp firmware and yet are unable to get their USBasp to burn a virgin AVR or an AVR that is in a standalone project using the internal clock vs a crystal/resonator. They will need to do something to make it work. They can either use the slow SCK jumper to slow down SCK with their older firmware or they can update their firmware so it can be slowed down by avrdude.

BTW, just as a point of reference, the firmware that allows avrdude to adjust SCK has been out and available for a little over 3 years now. It is sad to see vendors still shipping the older firmware from 2009. (Although the latest code will not fit in some of the designs that use AVRs with smaller memories)

In terms of complicated and expensive to update the firmware. I wouldn't say it is neither. While it does take a bit of knowledge, it only requires hooking up 6 wires to the USBasp device along with setting the programming jumper and then having some other ISP programmer which could even be another Arduino.

That said, playing at this level is not for newbies. Before attempting to reprogram your USBasp device you should verify the schematic of your USBasp device to make sure it matches the firmware you are about to burn. It may require visually mapping traces and pin connections on the USBasp PCB. While it can be bit tedious, it isn't difficult and it doesn't take very long to verify the 10-12 or so critical pins. Once you know the schematic, you may have to modify the firmware to match the wiring of your device if the vendor deviated from Fischl's design. Again, not difficult. These are typical things that need to be checked and done when wanting to play at this level.

and btw there never was a usbasp problem with >128k memory. maybe you are confusing it with mkII or tinyisp which did have some noobs jumping through hoops..

I do not believe this to be correct. From what I could see, the original USBasp protocol and firmware only supported 16 bit addresses in the command messages like READFLASH, READEEPROM, WRITEFLASH, WRITEEEPROM. A "kludge" was added in the 2007-07-23 firmware release to support bigger than 16 bit addresses. A new command SETLONGADDRESS was added to send a 32 bit address. If the address is sent that way, then the 16 bit address provided in the above commands is ignored and the 32 bit address is used instead.

Have a look at the code and see if you see what I'm seeing. It is also referenced in the change log for the 2007-07-23 release.

usbasp.2007-07-23
-----------------
- changed licence to GNU GPL v2
- included new AVRUSB driver version (Release 2007-07-07); AVRUSB licence was changed to GNU GPL v2
- fixed long addressing for Mega128 (by BoskiDialer)

--- bill

this might be another case of the blind monks and the elephant with me only feeling up the "good" part. ive had less experience with the fischel version and the only ones that ive personally seen fail were $7-$10 ebay units which account for only a small fraction of the listings.

many dozens of $2 cheapies purchased for my own use and for others worked flawlessly with raw chips and with large m2560 images. from what i can tell nearly all internet complaints for those boiled down to bad wiring or failure to follow instructions. or using some of those queer and buggy gooey shells. the cli batch files i provide work flawlessly time after time.

so we do agree re-flashing these is not for noobs. "six wires' and "schematic". lol. the devil is in the details.