USBasp Update Warning

******************************************** newer update *****************************************

thanks again for all the hard work put in from those who enhanced the firmware. unfortunately myself and few others on this end depend on tpi protocol which seems to be broken in the new versions. so ive attached to 1st post an older rev which still works. this one does seem to cover most of the issues we deal with on a daily basis. file is usbasp11.hex.

************************************************ older update *******************************************

edit: it looks like falling for that harmless avrdude warning message and upgrading usbasp with official/fischl firmware causes more trouble than suspected. since posting an avrdude example flashing fischl 2011 file ive been contacted by more than one individual claiming the programmer developed problems. wont program m2560 or raw (1mhz) chips correctly anymore.

imo its generally better to leave well enough alone and use stock chinese usbasp firmware. any problems are probably due to wiring or other issues. however if for whatever reason it does become desirable a few files are now attached at the end of this post that might come in handy.

"chinese1.hex" is copied from a typical ebay usbasp as discussed in Can't Update The Firmware On My USBasp Atmega8 Using Arduino - Microcontrollers - Arduino Forum. like o'fischl firmware not optimum for some mega2560 setups. however unlike o'fischl it programs raw chips ok so good choice for most arduino users.

"usbasp-v1.5.hex" is a version modified from fischl 1.4 by 9x guru gruvin and brought to us by petervh to fix the mega2560 bug described at The usbasp and atmega2560 mystery… | PeterVH. like original fischl wont program 1mhz chips by default. however it does allow -B option which comes in handy for ultra low clock speeds (ie 32khz) and works for all m2560.

"flaw2560.hex" is an m2560 program originally written by me to check ability to write to its own flash but i found it can double as test for usbasp >128k bug. its much faster and easier than flashing a bootloader and trying sketches. modify the avrdude line below to upload it. 3 blocks printed out at 57kbps. if last block all ff then it failed to flash correctly.

"usbasp-v1.06-alpha-2016-04-17-atmega8.hex" from petervh/bperrybap solves all these issues. myself and friends been using it for couple months now. big improvement. more info and other versions: GitHub - bperrybap/usbasp at 1.06-alpha.

hopefully these files will be of use to somebody here too.

************************************************ original post *******************************************

a recent discussion in another thread prompted some offline questions regarding currently available usbasp dongles. last few years quite a large number have passed through my hands due to business and academic involvements so it seemed like a good idea to share some experiences here. lets start with a couple links to units that are popular on ebay atm:

http://www.ebay.com/itm/USBISP-3-3V-5V-AVR-Download-Programmer-USB-ATMEGA8-ATMEGA128-USBasp-/361343449788

both available for a dollar or two free shipping but there are some slight differences. most important i think is that the first (LC 2.0 aka blue) while a bit cheaper, suffer from a potentially fatal design flaw. there are no caps on the regulator. sometimes you get away with this on n-pass types like classic 7805 but LDO have a tendency to oscillate without at least one on the output. out of a dozen or so sent to me recently for testing 3 failed on a bare m8 board. usually fixed by simply tacking on 1mfd ceramic cap between lm1117 pins 1-2 as shown in the photo.

the other type (baite aka black) has no problem there. it also has the advantage of 3v-5v switch instead of jumpers used on the blue one. its not shown in the listings but units received lately did actually have that as you can probably just make out in my photo. another nice thing the cable is about 10x longer. costing only half dollar or so more than the blue its highly recommended.

all units purchased last couple years came with firmware which appears to be a modified version of older fischl source. it has that annoying but generally harmless warning to upgrade. beginners sometimes incorrectly interpret this as an error and feel obligated to attempt reflash. imo this often causes more problems than it solves. popular belief that these are incapable of programming new chips in my experience has proven unfounded.

however there are a few valid reasons to justify reprogramming. for example using very slow clock (ie 32khz xtl or 128khz internal osc) is much easier with the -B option but requires updating the firmware. or as the case with me and a few locals, using the usbasp as a micro-controller instead of as a programmer. the built in usb interface can be quite handy for some applications and a great bargain for a buck and change. half the price of pro-mini which does not have usb.

so heres a quick description of the easy method we use to re-program these. best is with another usbasp connected end-to-end using stock cable as seen in my pic. j2 must be shorted on the destination unit (removed afterwards in order to run). for example to reflash with a recent fix heres the avrdude command line:

avrdude -pm8 -cusbasp -Uflash:w:usbasp-v1.06-alpha-2016-04-17-atmega8.hex

its as simple as that. both types shown in photo with programmer on the left and target on the right. aside from having spares for backup this is a major reason to buy at least 2 or more units. considering they only cost a dollar or two and the long ship time from china its foolish to order just one.

its also possible to use another type of programmer like mkII or arduino-as-isp but leads to hardware and software complications so i prefer the easy path.

IMG_0010b.JPG

below is pinout for most usbasp. older baite/black versions had gnd/gnd on 4 & 6 instead of tx/rx. this has caused considerable trouble in some cases so best not to use those two pins unless there is need for serial i/o which is rare for most users.

 mosi 1o v
   nc oo tx(was g)
  res oo rx(was g)
  sck oo g
 miso oo g

personally i prefer this to the 6 pin version on my target pcbs too. i do use serial signals a lot and the nc pin serves as polarizing key to prevent plugging in wrong. not much more board space yet significantly safer and more flexible than the 6 pin. no wacky adapters required either.

chinese1.hex.txt (9.58 KB)

usbasp-v1.5.hex.txt (12.9 KB)

flaw2560.hex.txt (731 Bytes)

usbasp-v1.06-alpha-2016-04-17-atmega8.hex.txt (12.9 KB)

USBASP11.HEX.txt (12.9 KB)

One other thing probably worth talking about is how to power the target USBasp device during re-programming.
How that is done will depend on the ISP programmer being used as well as the USBasp device.
For example, if using something like an AVR dragon (and I assume the mkii will be similar), it cannot supply power since the power pin on that ISP device cannot supply power.
In that case the USBasp target must be plugged into a USB port while being re-programmed.

The really sad part about all this ISP clock rate complication is that Atmel could have designed the AVR to always use the 8Mhz clock during ISP programming. That way there would never be any clock rate issues. (PICs don't have any clock issues like this).

I've considered looking at what it would take to update the fischl code to auto-detect the proper clock rate.
Currently the firmware uses a default fairly slow clock rate when powering up or when told to use its "auto" clock mode.
That clock speed is currently 1/32 of the MCU master clock which is normally 12Mhz so you end up with 375Khz.
I have seen some USBasp devices use a 16Mhz crystal and when using one of those, the default clock will be 500Khz
It should be possible to auto detect the correct ISP clock speed since you can do a handshake with the target AVR and if you don't get a valid response you can try another speed.
There are only 12 different speeds supported by USBasp.
That way if the user does not specify a speed when using avrdude, avrdude sends the "auto" clock mode (which it currently is already doing and that is why the older firmware caues the warning since the older firmware doesn't support that message)
the f/w could then go off and figure out what works rather than just using a clock speed of 1/32 of the MCU clock, which I have had problems with on virgin AVR chips, particularly the atTiny85.

It looks like there is about 3k of code space available so there should be plenty of room for it and that should allow the code to be smart enough to automatically run slow when needed and fast when it can while still allowing the user to manually override the clock with the -B option, offering the best of all worlds.

--- bill

OK, so I have a few of the boards now - probably all blue as obtained on eBay auctions (that capacitor must be expensive! Or maybe it is the switch) - but have yet to use one in anger so I would like to start on a good foot and be updated if it makes things safer.

I note some discussion suggesting that the fischl.de firmware has problems (possibly in relation to 2560s) and that the Chinese version is preferable. Care to comment on this?

Also you might care to provide the link to the fischl.de source (or any better one) and link-ify your eBay references. I feel this is going to qualify for a "sticky" - what say you Nick or CB?

I am inclined to opine that the "safest" option is to not update the firmware on the USB Asps unless you have to. I've seen a lot of posts where people see the "upgrade firmware" message, and go rush to update it, and end up bricking the USB Asp, or getting it into a state where it breaks when programming some but not all chips.

I am supicious that the chinese firmware may already automatically figure out the right clock speed to use, and just not respond the way avrdude wants it to (or it always picks a lower speed).... Despite that 375 khz should be too fast with a 1mhz clock for reprogramming, I've never had a problem programming virgin (1mhz) chips with fresh-from-china USBAsps. Nor with putting the 4313 into 0.5mhz speed and taking it back out...

beginners often incorrectly interpret this as an error and feel obligated to attempt reflash. imo this often causes more problems than it solves.

Can't we fix this situation? The sources are available, it should be possible to address possible problems caused by an upgrade. What kind of problems did you observe e.g. with fw 1.04? (You also mentioned this in another thread).

That brings me to the problem of support for flash >128KB, upload using programmer with hfuse=0xD8.... I thought this is worth mentioning in an update on usbasp.

popular belief that these are incapable of programming new chips in my experience has proven unfounded.

I see two explanations:

  • The usbasp's you worked with figure out the isp speed automatically using a mechanism like the one Bill suggested.
  • The usbasp's you worked with use the same default speed as Fischl fw: 375KHz. As Bill explains this is out of spec. But it may have worked all the time.

We could take some usbasp models and program a t85 and measure the isp speed to see whether the usbasp automagically adjust their speed. Unfortunately I have only the blue kind.

If these chinese fw's indeed auto select speed, working out Bill's suggestion might be a good idea.

PeterVH:
Unfortunately I have only the blue kind.

I have attached the firmware that came with the black "baite" www.betemcu.cn USBasp: http://www.ebay.com/itm/251538370202 in case that would be useful. If the actual programmer is needed I'm willing to donate one.

Edit: the forum wouldn't let me attach that file type. Here it is: https://github.com/per1234/misc/archive/ebay-usbasp-firmware.zip

as usual that does not appear to be an actual code image as can be seen from this snippet:

:2000000000000101020203030404050506060707080809090A0A0B0B0C0C0D0D0E0E0F0FF0
:2000200010101111121213131414151516161717181819191A1A1B1B1C1C1D1D1E1E1F1FD0
:2000400020202121222223232424252526262727282829292A2A2B2B2C2C2D2D2E2E2F2FB0
:2000600030303131323233333434353536363737383839393A3A3B3B3C3C3D3D3E3E3F3F90

simply incrementing bytes typical of data read from a protected part. i periodically dumped many dozens of these over the years and have yet to see valid code. as mentioned in the other thread it would be foolish for them to release proprietary firmware to public domain.

there are images available for purchase (ive seen a few) and illegally downloaded on bit torrent sites if you are willing to risk that channel. some are what is being shipped in ebay dongles but others unknown or undependable. my best luck so far has been using unmodified usbasp from reliable sources and its been quite a long while since any problems cropped up or ive seen need to reflash.

but when it comes to ebays deals as forest gumps mother said "you never know what youre gonna get". so far ive been very lucky. ymmv.

john1993:
as usual that does not appear to me an actual code image as can be seen from this snippet:

Oops, I never tried to reflash it after reading it from the USBasp, indeed it doesn't work. Maybe that's one of the causes of the "bricking", when they try to revert to the original firmware.

maybe but i think it unusual to read and then flash with the same image. and it dont really brick because you can always reflash with official (irish form of "fischl"? lol) which is more or less functional. i suspect a fuse gets accidentally changed which is actually the main cause of bricking.

Paul__B:
you might care to provide the link to the fischl.de source (or any better one) and link-ify your eBay references.

used to be many years ago on the old forum just posting a link was clickable. now they look like inline text. id greatly appreciate if anybody can tell me how to properly "link-ify".

john1993:
maybe but i think it unusual to read and then flash with the same image.

I was thinking if they tried to revert back to the original firmware and then still it doesn't work they will assume the USBasp is bricked.

john1993:
used to be many years ago on the old forum just posting a link was clickable. now they look like inline text. id greatly appreciate if anybody can tell tell me how to properly "link-ify".

Use the chain links icon or you can just use the tags like:

[url=http://www.ebay.com/itm/251538370202]http://www.ebay.com/itm/251538370202[/url]

It frequently gets me confused when I jump back and forth from GitHub, where the markdown automatically linkifies, to here, where it doesn't.

thanks, fixed. i think this is the 10th time ive been shown how to do that. not my forte. assembly/c yes, html not so much.

john1993:
as mentioned in the other thread it would be foolish for them to release proprietary firmware to public domain.

I'm guessing that at least some of these USBasp products are violating GPL copyrights since I bet at least some of them are probably either based on Fischl's code or using the USBtiny code for the USB support.

The USBtiny code, which is the low level USB support used in the USBasp f/w and is licensed GPL V2 or GPL v3.
This means that the official Fischl's USBasp code must be GPL V2 or GPL v3. (which it is)

Any project/product that uses GPL V2 source code must return any updates/modifications made to the code while GPL V3 code cannot be used in closed source projects/products
You have the right ask for the GPL source code and the vendor must provide it - that is the price for using open source.
(Actually they are mandated to make it accessible, which these days means putting it out on a server somewhere)

It terms of leaving the fuses open for reading the flash, if the code is fully open source, then there is little point in blocking reading of the flash image since anyone who purchases the device is entitled to the source code.

--- bill

yes, i should have said foolish to leave ANY chips unlocked (always keep the competition guessing). not that these guys care about ANY licenses, gpl or otherwise. seems like half those who do release source its "fake" source. little chance of actually matching the binary even if somebody does manage to compile.

i periodically dumped many dozens of these over the years and have yet to see valid code.

Did you dump the blue one? Mine was not locked.

I'll ask angelo in the other thread to post his.

PeterVH:
@pert: are you sure the target was properly powered? I got those images also when the target was not correctly powered.

I just read the eBay firmware from another one of my USBasps(the one I got the eBay firmware I shared I have already flashed with the 1.5 firmware) and the diff shows it's identical to the last one. I got no error messages during the dump. I have tried it using a USBasp and an AVRISP mkII and get the same hex file every time. I can dump the 1.5 firmware and then reflash the dumped 1.5 hex and it works fine.

Ok. It was unlikely anyway, which is why I removed it from msg #13, but you already read it by then.

PeterVH:
Did you dump the blue one? Mine was not locked.

ive had a few dozen of the blue and many hundreds of the black and random checks over the years never revealed anything but standard locked non-data. same for all commercial avr products ive ever checked except for some whitespy multiwii chips which were probably left unlocked on purpose.

pert:
I just read the eBay firmware from another one of my USBasps(the one I got the eBay firmware I shared I have already flashed with the 1.5 firmware) and the diff shows it's identical to the last one. I got no error messages during the dump. I have tried it using a USBasp and an AVRISP mkII and get the same hex file every time.

if we are talking about the file you posted we should expect the same thing to be read from any locked avr whether usbasp or anything else. reader wouldnt matter either. as usual just incrementing addresses from start to end. no errors expected because avrdude cant tell garbage from code. it could however verify programmed state of lock bits.

pert:
I can dump the 1.5 firmware and then reflash the dumped 1.5 hex and it works fine.

reflashing automatically by definition unlocks the chip so no surprise there. looking at peters 1.5 hex shows an obviously functional program. furthermore disassembly with objdump clearly indicates working usbasp code. i do have a program that self checks images and will try his utility on an m2560 when i get some time. if its ok i will put a copy up on post #1 as best usbasp firmware so far.

if peters blog is correct this is the only truly 100% functional open source program and he is indeed king of usbasp firmware. if anybody were to incorporate bill perrys idea for auto-clock we would have the first perfect program worthy of reflashing usbasp ever.

pert:
I can dump the 1.5 firmware and then reflash the dumped 1.5 hex and it works fine.

1.5 firmware?
What f/w is this and where is it from?
I've always gone here for the usbasp f/w: USBasp - USB programmer for Atmel AVR controllers - fischl.de
and the latest I see is the 2011-05-28 version which is 1.4

--- bill

bperrybap:
1.5 firmware?
What f/w is this and where is it from?
I've always gone here for the usbasp f/w: USBasp - USB programmer for Atmel AVR controllers - fischl.de
and the latest I see is the 2011-05-28 version which is 1.4

--- bill

update: I'm assuming this is peter's version "1.5"?
(I did notice that over on github a few days ago)

peter has put together an in depth analysis of issues associated with the fischl firmware and created a version fixing the 2560 bug:

it explains some of the rare but reproducible problems i had when reflashing w/official firmware and if really fixed would change my opinion about (not) recommending that to others.