I saw the blog entry, but I didn't see the github repo that Peter mentioned earlier.
I prefer working with code that is source controlled and that is one thing that is frustrating to me about the official USBasp firmware on Fischl's site. It doesn't appear to be source controlled on a public repo - if at all.
Peter is this your github code?:
It only took a few minutes to toss in some auto clock selection code.
I need to test it, but if it works, this will be very nice since it will allow updates to run as fast as possible or as slow as needed. (depending on your point of view)
Eventually, I'd like to create a new bundle release that includes:
corrected PROGMEM declarations (the original were wrong but worked with older gcc, once corrected will work with both old and new gnu tools)
Extended addressing
New LED behavior that I have working (red is writing, green is reading)
Auto SCK clock selection
Version for 4k flash devices like the atmega48
The only reason for the last one is that some USBasp devices are using AVRs with only 4k of flash.
(The device I have uses a atmega48 which only has 4k)
There is not enough room for the 2011-05-28 version in the 4k parts, I'm assuming it is the added TPI code that tips it over but the 2011 release also has newer/updated VUSB code.
I'm sure that there a bunch of those 4k devices still floating around out there and so I'm looking at how to create an update for 4k devices. (at least for my device)
If it is only the TPI support that kicks it over, then there could be 4k flash version that includes all the updates other than TPI support.
The current avrdude does do a handshake with the USBasp device to determine if TPI is supported before trying to use it - so that sounds promising.
John, our opinions seem to converge. I agree the vendor firmware in the Chinese handles over 95% of the use cases people have. Therefore it was indeed wise of you to warn people that they probably don't need the upgrade. This is certainly true if the usbasp is a locked one, because then there is no way to restore the original fw.
We can bet on two horses:
give people the above message, which is what you already did. (my blog post actually gives you an extra argument: usbasp can burn a bootloader to an m2560 and if you just use hfuse 0xD9, uploading using programmer works too, you just can't program over 128KB...)
make sure we can fall back again to an open source alternative: for the other 5% of the use cases and just for fun.
For the second horse we need to do lots of testing. As DrAzzy indicated: with multiple targets. We have time, the previous release dates from 2011.
@bill: yes that is my git hub repo. I just consecutively committed the three last Fischl releases so I could gain some rough insight in the history of the sources. Maybe clone it and add your clock adjusting code? I am really curious about it. It is best to add each feature in a separate commit.
Maybe we should contact Thomas Fischl, maybe he is still interested?
In mean time I measured the isp clock of the blue usbasp with the original fw. There is no magic clock adjustment here: it flashes every target with 100KHz.
I ordered two baite type usbasp's. It occurred to me I really had to search for a shop that alluded to special baite proprietary fw. Most of them indicated you can download the fw from www.fischl.de. Maybe they ran into licensing problems.
I always wondered why the USBasp code was doing 32 retries and that seems to explain it.
There is also one person that did an automatic slow down patch to avoid having to use the "slow" jumper.
It simply tries to enter programming mode and if that fails drops the clock to 8Khz and try again.
My approach was to start at the fastest clock and start dropping down until it works.
(but only if auto clock mode was requested)
I haven't tested it yet.
Before I start testing, I want to carefully review the AVR ISP spec to review the timing to see/verify the timing issues mentioned in that avr freaks thread above.
There may be some additional timing issues that need to be dealt with before trying to get fancy with automatic clock rate adjustment.
PeterVH:
if the usbasp is a locked one, because then there is no way to restore the original fw.
you are the only person i know that was lucky to encounter a usbasp with open firmware. could you post the file here? id like to compare with the handful of images ive collected over the years and im also curious if it has the auto-clock feature like most of my other off-the-shelf chinese versions.
bperrybap:
John, I think this latest sequence shows a possible way a user can soft brick his device when trying to update their device by reading the flash and then re-flashing it. If the fuses were locked it would have soft bricked
oh yes, thanks. because of your comment to me there i thought it was a locked image. so possibly others besides peter are unlocked and i have just been a victim of bad luck. disassembling shows this is not the 2011 or 2009 fischl or the few other images i have so i am very curious about that code and will spend some time on it.
in view of the fact that my ali dongles behave 100% in terms of clock and >128k words its possible the perfect firmware has been floating around all this time but ive been blind.
if this is not exactly the same as peters i would still be very interested to have him post his here. or any other open firmware anybody might find.
Did you see the "automatic slow jumper" patch code that was in that discussion thread I post a link to earlier?
Here is a direct link to his github repo - which is incomplete since it doesn't contain all the code but rather just the modified main.c and a hex image built from it.
That code will drop the clock down to 8khz and try again if the initial enter programming mode fails.
Simple easy hack that allows it to work on slower clock AVRs without having to use the jumper.
i actually took part in discussions on that when it first appeared a few years ago. not having trouble with existing usbasp and little interest in compiling c code for that it didnt appeal. the serial port subject is much more interesting to me. im always more curious about what actually comes installed in stock modules. i suspect current firmware uses similar tactics but probably based on even older fischl versions.
experiments showed the code in that thread still suffered from other bugs that my own chinese dongles did not. so mostly i would like to find this "perfect" image that might be useful in those (albeit very rare) cases where the oddball unit might be misbehaving. if i could get an open image that worked as well as some of my closed ones that would be great.
so any images from dongles that are not locked might prove to be the key. maybe the one from peter.
From my perspective it is easier to simply read the AVR ISP spec and then go fix Fischl's code if there are any issues - That is the direction I'm headed.
i agree. unfortunately beyond my capabilities atm. best path is probably to change one thing at a time leaving version trail as peter suggests. maybe start by fixing the m2560 issue which is a fatal flaw then auto-clock which avoid the inconvenience of using -B. or whatever.
ive just checked angelos image which appears to be a common version with auto-clock which reliably programs fresh chips but fails on extremely low like 32khz. good for all arduino users but -B not recognized so not perfect for hackers.
edit: i also did preliminary check on peters 1.5 and as expected like the fischl 2011 it was based on fails to program new chips unless -B is used. so again would warn against this version for typical arduino users who are much better off with stock chinese firmware.
bottom line angelos image has auto-clock like other ebay dongles so imo best option so far for typical arduino. thanks angelo.
Angelo's backup is identical to what was in my lc technology usbasp when I bought it. It does no fancy auto clock stuff, it uses a fixed spi clock of 100KHz.
What would help Bill is a waveform recorded from a baite type usasp while it does its auto clock magic.
thanks for letting my know they are the same. you guys got really lucky. or maybe they are all being shipped like that now. its been some years since i actually bought a blue one myself due to that hardware problem.
however i dont understand how clock is fixed yet chips with crystal program so much faster. im sure the ones ive been using switch because i can see the pulse width change at the start. no matter what using isp instead of serial has proven to be a big productivity jump for me. specially since bill got rid of that blank flash delay for me couple years ago. thankfully it has been incorporated in latest versions.
i do need to test these for the m2560 fatal bug because imo its more important than the auto-clock thing which is pretty much just a cosmetic inconvenience. im looking to replace my old test routine that checks all of flash with something smaller and quicker based on your more detailed characterizations.
john1993:
i agree. unfortunately beyond my capabilities atm. best path is probably to change one thing at a time leaving version trail as peter suggests. maybe start by fixing the m2560 issue which is a fatal flaw then auto-clock which avoid the inconvenience of using -B. or whatever.
With source control it is easy to track things, create branches, do merges etc.. and then create tags when things work.
The order isn't really that simple as the first thing is to fix the code to work with the new avr gcc tools
Easy - took about 2 minutes - I've already done that
Then for me, I have to fix the latest code to try to squeeze it back into 4k of flash.
This will require removing TPI support and perhaps even removing the new USB crc checksum checking code.
(The latest USBasp code removed support for the atmega48)
So for 4k parts you essentially end up with an updated version of the 2009 code that supports the new avr gcc tools, fixes the extended addressing, fixes the s/w spi, better LED behavior, and auto clock adjustment.
I can fix the code so that it can remove features to make room automagically at compile time depending on the target part.
That way it all happens by magic and the bigger parts get more features but the smaller parts still get some needed/useful updates.
ive just checked angelos image which appears to be a common version with auto-clock which reliably programs fresh chips but fails on extremely low like 32khz. good for all arduino users but -B not recognized so not perfect for hackers.
edit: i also did preliminary check on peters 1.5 and as expected like the fischl 2011 it was based on fails to program new chips unless -B is used. so again would warn against this version for typical arduino users who are much better off with stock chinese firmware.
bottom line angelos image has auto-clock like other ebay dongles so imo best option so far for typical arduino. thanks angelo.
I did see some ISP timing & protocol issues with the fischl code after looking at the AVR SPI spec.
This is pretty simple stuff so I'm not sure why it wasn't done correctly and according to the spec.
The issues should be fairly easy to fix. The biggest issue as pointed out in that thread from a few years back is that the s/w SPI code is really broken.
When the SCK clock is below 93Khz the code switches from the H/W SPI - which works correctly, to the s/w spi. But since the s/w spi is not correctly handling the SPI signals, it will likely have issues.
From looking at the fischl code it is amazing that the s/w spi works at all. Best I can figure is that AVR presents the next bit on the MISO signal before the clock edge rises. It must be doing it on or just after the falling edge of the previous bit and the fischl code has just enough overhead to be able to read the bit on the signal after the AVR has set it - but that is not how it is supposed to be done.
good luck on that bill. sounds great. keep us tuned in.
btw im having a problem on ide 1.6.5 with m2560 and official usbasp 2011 firmware. led does not blink using upload with programmer or flashing the hex from command line. m8 and m328 works ok from the ide as does my own blink from command line.
is ardunio13=PB7=pin26 as shown in the schematic? is there something else i need to change in tools besides board=mega2560?
john1993:
with m2560 and official usbasp 2011 firmware. led does not blink using upload with programmer
That's the very issue that was investigated and solved in PeterVH's blog post. You can either change the hfuse to D9(after which serial upload via bootloader will no longer work) or you can use the USBasp 1.5 firmware which allows Upload Using Programmer and upload via serial to both work with the default hfuse of D8.
Edit: it was using the eBay firmware(and probably the USBasp firmware version it was based on) that serial upload no longer works with hfuse D9.
Edit #2: With USBasp firmware 1.4 the first serial upload after Burn Bootloader works but after that the bootloader stops working.
thanks, peters image works. to be honest it didnt make a lot of sense to me because my own blink worked fine. i guess in that case the bootloader was being erased and the blank area simply wrapping to 0.
so basically most people are unable to use regular m2560 chips with arduino. this is more serious than we thought.
john1993:
so basically most people are unable to use regular m2560 chips with arduino. this is more serious than we thought.
Only Upload Using Programmer doesn't work with the default boards.txt setting of hfuse D8, Burn Bootloader works fine. I think most Arduino users don't ever use Upload Using Programmer so I wouldn't say "most people" but still I do agree it was a serious issue because USBasp is in my opinion the best programmer option so it is important for it to work for all uses with all standard chips. I think the USBasp firmware 1.5 fix is a better solution than changing the hfuse setting to D9 because the latter will still require a firmware update for many USBasps that are using the USBasp firmware 1.2 or the eBay firmware that's based on 1.2(I'm not sure about 1.3 because I can't seem to get it to work).
I think the USBasp firmware 1.5 fix is a better solution than changing the hfuse setting to D9 because the latter will still require a firmware update for many USBasps that are using the USBasp firmware 1.2
Note with hfuse 0xD9 you can upload sketches using programmer even with 1.2 based fw. That is why John has a point warning people they probably don't need the upgrade.
The idea is to pick up work on the opensource fw (Fischl based) such that it you can upgrade to it without regressions compared to the original fw.
You have a baite make usbasp with original fw and one with the 1.5. If you notice things that don't work with 1.5 and that do work with the original one, please let us know here.
PeterVH:
Note with hfuse 0xD9 you can upload sketches using programmer even with 1.2 based fw. That is why John has a point warning people they probably don't need the upgrade.
Yes, Upload Using Programmer works with 1.2 and hfuse 0xD9, but as I said, with that hfuse value the bootloader no longer works. I don't consider having to change the hfuse value back and forth or adding another boards menu entry a good solution. With 1.4 Upload Using Programmer and the bootloader(edit: only for the first serial upload) both work with hfuse 0xD9 but since most of the commonly purchased USBasps don't come with 1.4 people have to do a fw update anyway so might as well update to 1.5 so they won't have to change the Mega hfuse value.
I will certainly notify if I find any shortcomings of the 1.5 firmware. I am using that version in my main USBasp but keeping one with the baite fw as a backup.
The easiest way to test support for flash >128KB is to simply set the hfuse of an m2560 to 0xD8 and then upload a blink sketch using programmer and see whether it blinks.
A more speaking test is this one: I have a small (3K) hex file that spans an area > 128KB. It contains a sketch that prints a short message on the serial line. It gets that message from flash above 128KB. In the sketch's source I recorded the command lines needed to hand craft the hex file containing sketch + data.
This hex file cannot be flashed with pre 1.4 fw. (can the baite ones do this?)
1.4 can flash it if hfuse is already set to 0xD9.
1.5 can flash it with hFuse=0xD8 or 0xD9.