Go Down

Topic: Fixing USBasp based on ATmega8 (Read 41 times) previous topic - next topic

john1993


Most of this thread looks to be about trying to update/re-program a USBasp device.


yes i see that many followup posts dealt with trying to reprogram the usbasp. but my reply was in response to his complaint again in his post preceding mine about  'the annoying "sck period" message' and suspicion that fuses cause it. this is not a result of trying to reprogram the usbasp with arduinoisp. neither fuses on the usbasp not the target affect that.


If trying to program a new part with the factory default fuses,
which is using the internal 1Mhz oscillator (which is controlled by fuses), sck period must be slower
so the "warning" is indicating why things are not working.


i get that message regardless of target speed so dont see the utility. we should just realise that new chips need slow clock and -B is how you do that not j3.


With the old firmware if you get this error/warning message and things are not working, often everything will work
if you simply jumper the slow SCK jumper on the USBasp device.


the usbasp i got from dealextreme does not have j3. i suppose they may have shipped different versions but all the ones from that vendor ive seen are the same. even going back 2 yrs.

so if he is trying to program the usbasp that message/jumper/command is not relevant and if trying to flash a slow raw target the -B is how you do it as i mentioned in post #6. either way the avrdude output while trying to do a read should tell whats wrong. of particular interest would be if sig is ok but fuse still reads as 0 which makes no sense. unlikely all bits are programmed and as we all know if rstdsbl is 0 there is nothing op can do except use another chip.

bperrybap

John,
Remember your avrdude thread from back in November?
http://arduino.cc/forum/index.php/topic,133005.0.html
I'm the guy that built an updated avrdude 5.11.1 windows binary from the SVN sources
for you to speed up your 1284 bootloader development - I'm very familiar with avrdude and usbasp.
For others, if you are going to be burning many bootloaders,
I highly recommend getting a later avrdude as it dramatically
speeds up the process since it will only burn the bootloader code space and not all the flash
from zero up to the bootloader.
3-4 seconds for fast SCK, 30 seconds for slow SCK compared to
30 seconds with fast SCK and about 7 minutes with slow SCK with the avrdude that ships with IDE.
(the windows binary I built and config file is attached as a zip image near the end of the thread linked above)



Just to refresh my understanding of things, and to look at the -B option and SCK clock modes
on USBasp a bit closer,
I went back and had a look at both the avrdude source code and the usbasp source code.

The recent avrdude (past few years and what ships with Arduino)
will always try to set the SCK speed on usbasp before connecting to the chip to talk to it.
It either sets it to an auto clock mode  (0, which is fast) or sets
it to a value from the avrdude.conf file or a value from the -B command line option.
The -B overrides the setting.
If the usbasp device firmware does not support setting the isp SCK through
the USB USBasp command interface, avrdude will report a warning.
From the avrdude code in usbasp.c
Code: [Select]
  int nbytes =
    usbasp_transmit(pgm, 1, USBASP_FUNC_SETISPSCK, cmd, res, sizeof(res));

  if ((nbytes != 1) | (res[0] != 0)) {
    fprintf(stderr, "%s: warning: cannot set sck period. please check for usbasp firmware update.\n",
      progname);
    return -1;
  }


The avrdude code first does a SETISPSCK command and then does a CONNECT.

If you look at the official usbasp releases on the fischle site,
http://www.fischl.de/usbasp/
support for this SETISPSCK command started in the 2009-02-28 release.
Prior to that, the usbasp firmware either ran in hardware ISP or software
ISP depending on a hardware jumper.
According to the official schematic that jumper is hooked up to PC2 and is called JP3.
It grounds PC2 to set software SPI mode.

From the USBasp firmware in main.c
Pre 2009-02-28
Code: [Select]

    /* set SCK speed */
    if ((PINC & (1 << PC2)) == 0) {
      ispSetSCKOption(ISP_SCK_SLOW);
    } else {
      ispSetSCKOption(ISP_SCK_FAST);
    }



post 2009-02-28
Code: [Select]

if (data[1] == USBASP_FUNC_CONNECT) {

/* set SCK speed */
if ((PINC & (1 << PC2)) == 0) {
ispSetSCKOption(USBASP_ISP_SCK_8);
} else {
ispSetSCKOption(prog_sck);
}


The pre 2009 code supported "slow" (s/w isp) or "fast" (h/w ISP)
and the new code supports a forced slow rate (which also uses s/w ISP)
or the value/rate sent from the -B option which defaults to to a fast h/w ISP
if not sent.
This rate/mode is controlled by the jumper - Installed == slow, removed == fast or -B mode
depending on the firmware.

This jumper setting check is in the top part of the code for the CONNECT
command. This means that even if on newer firmware that supports the
-B option which uses the SETISPSCK command, the jumper will override that
setting. (avrdude does the CONNECT after SETISPSCK)




Now that we know how avrdude and the firmware works, lets take a look
at how it interacts with a blank AVR chip.
Every single blank m328p AVR chip that I've programmed required using a slower SCK clock.
The default USBasp SCK clock rate is too fast for the default internal clock that the AVR
shipped with.

I've not programmed a large quantity, only around 10 or so, but this was true for all them.
The SCK clock had to be slowed down when using either an AVR dragon or the USBasp device I have.

Using the internal clock is controlled by fuses inside the AVR so yes the target fuses
can affect whether or not the USBasp device can program the AVR - or at least
make it not work with all the USBasp defaults.
Note: according to the datasheet the m328p clkdiv8 fuse is programmed when shipped
which gives a 1mhz clock by default for blank chips,  so I assume that the SCK clock
will need to be slowed down for all blank m328p chips and not that mine were
somehow "unluckily"  slow.

Since the firmware on my USBasp appears to be old and out of date, it requires using slow SCK jumper to slow
down the clock. (the -B option does not work as there appears to be no support for SETISPSCK in my device firmware)
The USBasp device I have also has it's jumper headers labeled differently from the official schematic.
On my USBasp device, I short out the header pins labeled j2 rather than j3.



From my experience, here is my take away from all this
when using USBasp devices.
If you have old USBasp firmware you will ALWAYS get the SCK warning.
In order to burn a  bootloader into a blank chip, the SCK will need to be slowed down.
If you have old USBasp firmware, you must use the slow SCK jumper to slow the clock down.
Not all USBasp devices label their slow SCK jumper the same or use the same label as in the official schematic.
If you have newer firmware you can use the -B option, but.....
from what I've seen so far, the Arduino IDE does not use the -B option when it burns a bootloader, so if
using the IDE, it looks like you will still need to use the jumper.
As an alternative you can use the avrdude commandline interface where you can spedify the -B option.

If the AVR is running faster than the 1Mhz default, then no jumper or -B option should be needed
but the avrdude SCK warning will still show up.


--- bill

Now I need to go update my USBasp device to the latest firmware so I can eliminate
the ugly warning message.




bperrybap

So I updated my USBasp firmware using an AVR dragon.
As expected, no more SCK warning messages from avrdude.
details below.

alx,
to update your USBasp, you will have to set your jumpers properly.
The most important one is the programming jumper which connects
the reset line on the ISP header to the reset on the processor.
Typically there are 3 jumpers
- VCC pass through (connects VCC to ISP header)
- Programming (connects ISP header reset pin to AVR reset)
- Slow SCK (grounds PC2)

It may take some sleuth work with a magnifying glass to figure what the jumpers do to
ensure you have the correct jumpers set since these devices typically
don't come with much if any documentation and the PCBs don't use
the same jumper numbers as Fischl's schematic.
The only way to figure it out is to follow the traces on the PCB
and then look at the pinout for the AVR used on your device.
Its not that bad, since all you really have to do is see which header/holes
connect to VCC, RESET, and PC2.

You will also have to decide how to power the USBasp device.
Either from the USB or from the UNO through the VCC pin on the
ISP header. If you use the ISP header you will need to make sure you
pass power through which is another jumper.

I've not seen in your previous posts how you set the USBasp jumpers.
Did you connect up the programming jumper?
Once you get the programming jumper set, get the device powered
and get it wired up, it should program ok.

--- bill



Details...

It wasn't as straightforward as I had hoped but still wasn't that difficult.
(most of the issues were linux udev permission related since I've rebuilt my machine recently)

The USBasp device I had used a atmega48 which only has 4k of flash so the latest
firmware release from 2011-05-28 could not be used. However the previous release
from 2011-02-28 has support for setting SCK clock rate so I went with that.

In order to enter programming mode, the reset line has to be connected
to the ISP header/connector.  On the official schematic that is J2 on my device
it was labeled J3. (I figured this out a while back using a strong microscope and following
the traces on the PCB)
What made it tricky was that my device has no case but uses clear shrink tubing
as a cover. It didn't have a header in place for the programming jumper.
I didn't want to cut off the protecting layer just to short out the programming jumper.
The trick was to use a bread board jumper.
I was able to pierce the shrink wrap with the pins and short out the needed trace.
The clear plastic held the jumper in place and when removed
the plastic is left with two tiny small holes from the jumper pins.
(See attached photo).
After that, it was a snap to program the software.
As an added bonus, I went in and modified the firmware to show activity on the green LED.
By default the Green LED just turns on Green and stays green while the device is plugged in.
The RED led turns on when avrdude tells the device to attach to the AVR chip.
I modified the code to turn off the green led while the firmware is actually talking to the
AVR chip and solid green while idle. The result is that the green now LED flickers while
the USBasp device is actually talking to the AVR.
But with the new avrude you have to look quick because the actual burn of a bootloader
when in fast SCK mode is about 2 seconds.
It is a nice flicker during the 30 second update when using the older avrdude.


john1993

#18
Feb 25, 2013, 07:26 pm Last Edit: Feb 25, 2013, 07:46 pm by john1993 Reason: 1
yes i recalled the favor you did. your forum name is forever burned into my mental hall of fame. thanks for saving me literally hundreds of hours developing custom bootloaders.

your usbasp experience is interesting and quite different from mine. first i will say having purchased hundreds, no exaggeration, of chinese usbasp clones (betemcu, lcsoft, etc) for clients i never saw one with a j3. 3v-5v and self program jumpers, yes. clk jumper no. and always got the warning msg regardless of fuses or target. something else a mystery is 9 out of 10 worked fine for 1mhz chips. thousands of raw mega8 and few dozen other types like tiny, 168, 328, 1284, etc w/o any need for -B or updates. but some rare lots, even from same vendor, needed to be told to slow clock. i tried updating those with official firmware which sometimes worked and other times didnt. but always bailed out by -B. so looks like its a crap shoot what you will get from china. and many variation on firmware. ive considered throwing together a diy usbasp deadbug because it would only cost $1 or so but for a couple bucks more places like aliexpress, ebay, dx always prevailed.

thanks for putting together this very interesting and informative "wiki" on usbasp history. and thanks again for helping with that avrdude hack.

btw are you considering posting hex for that usbasp code? id be very curious to give it a try. if its anything like your avrdude mod it would be a boon to hobbyists around the world. specially those many noobs who get confused by the warning.

bperrybap


your usbasp experience is interesting and quite different from mine. first i will say having purchased hundreds, no exaggeration, of chinese usbasp clones (betemcu, lcsoft, etc) for clients i never saw one with a j3. 3v-5v and self program jumpers, yes. clk jumper no. and always got the warning msg regardless of fuses or target.

wow. Very interesting. hundreds?
Are you involved with a school/students or something?
I can't imaging being involved with purchasing so many units.

I have no idea why people that make USBasp devices deviate from the Fischl's names/designators on their boards.
Maybe some of them actually go in and change the hardware and the code?
But I suspect that most of them don't and use the stock Fischl code
but for some odd reason change the designators on the PCB.

Nearly all the ones I've seen on Ebay do have the jumpers or at least the pads for the
3 options. VCC passthrough, slow SCK, programming.
(At least in the photos, but then sometimes you don't get what is shown in the photo)
Example, the photo of mine showed a jumper for the VCC passthrough. The actual
board I got had a zero ohm resistor soldered in. It can be altered/fixed with a bit of soldering.

But I'll agree it can be a bit rough for less technical folks.

Quote

something else a mystery is 9 out of 10 worked fine for 1mhz chips. thousands of raw mega8 and few dozen other types like tiny, 168, 328, 1284, etc w/o any need for -B or updates. but some rare lots, even from same vendor, needed to be told to slow clock. i tried updating those with official firmware which sometimes worked and other times didnt. but always bailed out by -B. so looks like its a crap shoot what you will get from china. and many variation on firmware. ive considered throwing together a diy usbasp deadbug because it would only cost $1 or so but for a couple bucks more places like aliexpress, ebay, dx always prevailed.

Interesting. Maybe the parts didn't have the CLKDIV8 fuse set.
With the normal/stock Fischl firmware, if you don't have support for the setting the SCK rate
you will get the SCK warning from avrdude. But that also means -B won't work as well.
Maybe some of the USBasp devices are hardwired for slow mode?

My feeling with cheap import h/w is that I can't build the hardware for what I can buy it for on Ebay.
But if needed, I can fix the software to work on whatever design they used.
So I just buy the cheap stuff, and fix it to work if I have too.
For the USBasp device I had, the hardest part was looking at the traces to verify where
all the connections went since there wasn't a schematic.

Oddly enough, there is an even an error in Fischl's code vs schematic.
On the official schematic, the green LED is hooked up to PC1 and Red to PC0
but yet the code believes that Green is on PC0 and Red is on PC1.
My board matched Fischl's code rather than the official schematic.

Quote

btw are you considering posting hex for that usbasp code? id be very curious to give it a try. if its anything like your avrdude mod it would be a boon to hobbyists around the world. specially those many noobs who get confused by the warning.


I can build and post whatever .hex people want.
Although it is  pretty easy for people to build it for themselves
or just burn the stock .hex images that come with each release.
The only difference between my code and the stock .hex is that
I tweaked the way the LEDs work. The rest of the code is unchanged.

The biggest issue with posting .hex images is that
it is a bit complicated as there are many different combinations so one .hex won't
work for everyone.
It depends on which AVR is used in the USBasp device.
It can be mega8, mega48, or mega88.
And then the mega48 can't run the latest 2011-05-28 firmware.
Complicating things further is the actual hardware design.
Not all boards are using a 12Mhz clock.
Also, if the hardware doesn't use the same ports/pins as the official Fischl design
then Fischl's firmware won't work without tweaks to make it match the hardware.


The stock LED behavior is ok so I think most users would probably be just fine
if they simply updated their boards with the proper stock .hex image supplied by Fischl.

The trick is that if the USBasp being updated doesn't match the Fischl schematic
then their board will be useless until is uploaded with the proper USBasp image for
that board.
The only way to know if the USBasp device is compatible with Fischl's stock firmware images
is to get out the magnifying glass (I used a USB microscope) and look at the connections on the PCB for
the ISP connector and see where the all go. Tedious but not difficult.

Then if it doesn't match, it is pretty easy to go tweak the code to match
the hardware and simply build the image you need.

--- bill

john1993

#20
Feb 26, 2013, 02:47 am Last Edit: Feb 26, 2013, 02:49 am by john1993 Reason: 1

Are you involved with a school/students or something? I can't imaging being involved with purchasing so many units.


actually i run an assembly house and one of my clients hires me to purchase and ship a programmer with each unit. the usbasp was by far lowest cost and unlike tiny or mkII fewer "issues" so thats what i chose.


Nearly all the ones I've seen on Ebay do have the jumpers or at least the pads for the
3 options. VCC passthrough, slow SCK, programming.


a quick search for lowest cost units (click both price lowest & buy it now) will show the reverse may be true:

http://www.ebay.com/sch/i.html?_from=R40&_sacat=0&_nkw=usbasp&rt=nc&LH_BIN=1

nearly all the lowest cost ones are betemcu design which as i mentioned have voltage and reflash jumpers but no slow clk (see attachment). the new lcsoft design is just starting to appear but they only started showing up last year or so. i always go for the lowest cost deal and since nobody will do qty discount or combined shipping on those they are out of the running.


The only difference between my code and the stock .hex is that
I tweaked the way the LEDs work. The rest of the code is unchanged.


ah.. you mentioned something special to supress that message but if not then no point posting hex. but i do think hex is far more helpful than source because i see 99%, my customer base for example, are not set up to compile or tweak but no problem flashing. sometimes we forget not everyone is a hacker/guru.

john1993

bill, i hope you dont mind me posting instead of pm. email is difficult for me and others might benefit from public info. specially those with the particular model we are discussing which seems to account for lions share of the ones out there today. i wish this info was available to me when i started out instead of having to learn the hard way.

j2 seen in my pic is definitely the re-flash jumper as ive reflashed many of the misbehaving units with either official image or supposedly "improved" versions from freaks. usually it helps, on very few occasions not. i should also mention that these really come with NO jumpers and the only pads are for j2. there are no pads for "passthrough" like you might find on dragon, mkII, or stk500 clones. but on the other side theres a 0 ohm resistor which serves the purpose of 3.3v/5v select if replaced with a jumper. basically it shorts the ldo. far more useful than a passthrough imo.

what you suspect might be pads for pc2 are definitely not but are vias which do not seem to be useable for slow clk if my continuity tests are correct. on a few units when i removed the mcu it appeared pc2 went under the chip where it was grounded in some and appeared to be cut in others. i think they did this to make it work better with whatever peculiar firmware version was being used at that time.

judging by some difference in behaviours im certain the firmware has been tweaked and looks to me like at least 3 separate versions. maybe more. this would explain differences between what you and i see in out own units.

you are right about my desire to remove the message being cosmetic. not so much for me but generally to reduce confusion when noobs see it and think there is a fatal error. probably hundreds of posts between here, freaks, robot, and rc forums. most of mine send that out regardless of target clock so you are probably right about it due to permanently wired pc2 or else tweaked firmware.

bperrybap

The thread is ok, I used PM since this is drifting away from the original topic.

The VCC passthrough jumper is useful if you need to disable the USBasp putting power on the ISP connector
because the device is already powered.
For example, say you want to use the USBasp to upload sketches on an UNO but then also want
to keep the UNO plugged into the PC to keep a live serial connection.
For this setup, you really should disable the voltage from the USBasp device
going into the ISP connector since that will be driven by the UNO.


Removing the warning message simply requires updating the firmware
to firmware that supports the SETISPSCK command.

But like I said, in order to ensure that the device is being updated with the correct
firmware, the user will have to verify a few things like
- processor type
- crystal frequency
- board layout

to ensure the USBasp device is properly put into programming mode and then
programmed with a firmware that works for that device's processor, clock speed,
and board layout.

In the case of my device, the layout, pin connections, and LED connections
matched the official Fischl design.
The only difference was that the jumper numbers on the PCB silkscreen didn't match
but that didn't affect the actual firmware.

If the device does not match the official design, by say using a different clock than 12mhz
or using other pins for the LEDs or slow SCK, then the user will
have to make a few small changes to the code and rebuild the USBasp firmware image.

My device was purchased about 6 months ago, but yet had firmware in it that was
more than 3 years old. I updated the firmware to the latest version
that would run on the atmega48 which is what is on my USBasp.
Before I did the update I also modified the code with a few of my own tweaks to change the LED behavior.

--- bill

john1993

yes, yours is the lcsoft v2 which matches that offcial schematic exactly. i have a couple of those but because they are more expensive and cable is too short do not use them for customers. btw my lcsofts have m8 instead of m48. in fact i never saw anything but m8 on any of the usbasps i bought. they all work with standard firmware but i do wish i had copies of the factory image because some worked better than others. you are lucky to find one unlocked but all mine came locked.

talking about power options i suppose its a matter of personal preference whether passthrough or 3.3v/5v select. for me i almost always power from the dongle during software development. however i often have to switch between the old 5v and the new standard, 3.3v, so a jumper that shorts the ldo is convenient. would make far more sense to have a 3 pin jumper to allow all 3 options but never seen that.

btw you mentioned my field units not needing slow clk. surprise! my customers design runs at 1mhz. the only fuses i change are bod and eesave. fortunately all of the usbasps i ship work ok, worst case needing -B. i do test for that before letting them out but do get an occasional fellow calling and saying his unit dont work when actaully it was just that warning. customers, cant live with 'em and cant shoot 'em... well you could but then whod sign the checks. lol!

bperrybap


... i do wish i had copies of the factory image because some worked better than others. you are lucky to find one unlocked but all mine came locked.

The zip images that fischle has on his site:
http://www.fischl.de/usbasp/
have .hex images for the official firmware.
Locked/unlock AVR on the USBasp doesn't matter.
You can simply erase the chip to remove the lock, set the fuses again, then burn/upload the image you want.
The supplied Makefile even has rules in it to set the fuses and burn the image.
(just fill in your target processor and AVR programmer information)

Quote

talking about power options i suppose its a matter of personal preference whether passthrough or 3.3v/5v select. for me i almost always power from the dongle during software development. however i often have to switch between the old 5v and the new standard, 3.3v, so a jumper that shorts the ldo is convenient. would make far more sense to have a 3 pin jumper to allow all 3 options but never seen that.

You could use a different programmer. Many like the newer USBtiny or the Dragon have logic levelers and will adjust
to the targets voltage level.
I typically power my targets from USB or batteries.
I plugged in my USBasp to USB for power when I updated it using my AVR dragon.
(My Dragon is setup not to provide power on the ISP connector but rather to adapt to target voltage level)

Quote

btw you mentioned my field units not needing slow clk. surprise! my customers design runs at 1mhz. the only fuses i change are bod and eesave. fortunately all of the usbasps i ship work ok, worst case needing -B. i do test for that before letting them out but do get an occasional fellow calling and saying his unit dont work when actaully it was just that warning. customers, cant live with 'em and cant shoot 'em... well you could but then whod sign the checks. lol!


I'm surprised they work at 1Mhz without a slower SCK.
Are you sure the CLKDIV8 fuse is set and the processor is running at 1Mhz?
i.e. are they really running 1Mhz or are they running 8Mhz?

If still using Windows (which seems to be quite popular)
I think I'd ship a self extracting autoexecuting zip image that autoexecutes
either some batch file or something like a autohotkey GUI as a wrapper around
avrdude to automatically do the update. That way all they do run a single executable you send them
and everything else is magically done for them.
The autoexecuted wrapper can test the return status of avrdude to confirm whether or not it worked
and post a message whether or not it work.
You can also control the avrdude commandline options to include the -B option and
even redirect all the avrdude output so they wouldn't ever see any avrdude messages
and only see the messages you supply.

--- bill


But back to Alx.
Were you able to solve/resolve your issue?
or get your USBasp device updated?




retrolefty

Yesterday I received a USBasp programmer I bought from hobby king. It too gives the clock warning messages but otherwise seems to function fine burning bootloaders or sketches via the upload using programmer option. I tested it on both a 328P based board and a mega1280 based board. Good price, and they did a 6 and 10 pin ISCP trick in the cable that seems to work fine for the arduino 6 pin ISCP pinout. I bought it because while I love my USBtiny programmer it doesn't seem to work on AVR chips with flash sizes greater then 64 K words (128KB).

Anyway it has just one jumper, I'm assuming it's for powering the target, did not even try removing it. I can live with the warning message and can always use the USBtiny to burn fuses on virgin chips if required.

http://www.hobbyking.com/hobbyking/store/__21321__USBasp_AVR_Programming_Device_for_ATMEL_proccessors.html?strSearch=USBasp

Lefty

bperrybap

Lefty,
Since you are seeing the avrdude warning that probably means you have firmware that is
from 2007 or earlier since all releases after 2007 starting in 2009 had SETISPCLK.

It would only take a few minutes of looking at the PCB to determine the necessary information
to see if works with the standard Fischl firmware (I'm assuming it will) and to identify what the jumper
really does and if there are pads for programming or slow SCK and how the LEDs are connected.
(It's only 4 AVR pins and 1 ISP pin that needs to be looked at)

In the photo, there is what looks like set of holes just below the AVR (labeled R8 or A8)
just to the left the black jumper.

Since you have a USBtiny, you could use that to upgrade the f/w in the USBasp device
then have a fully functional USBasp device rather than one that mostly works.

Even if you decide not to update the firmware, it would be nice to know what the jumper does.
It could be slow SCK or VCC power passthrough.
Should take only a few seconds to figure that out.

--- bill

retrolefty


Lefty,
Since you are seeing the avrdude warning that probably means you have firmware that is
from 2007 or earlier since all releases after 2007 starting in 2009 had SETISPCLK.

That is probably the case. No documentation comes with the product, but they do have a link to
a rather large downloadable files section, including a hex file that is probably the firmware for
the ATmega8A chip the unit uses. in the purple files tab:
http://www.hobbyking.com/hobbyking/store/__21321__USBasp_AVR_Programming_Device_for_ATMEL_proccessors.html?strSearch=USBasp  


It would only take a few minutes of looking at the PCB to determine the necessary information
to see if works with the standard Fischl firmware (I'm assuming it will) and to identify what the jumper
really does and if there are pads for programming or slow SCK and how the LEDs are connected.
(It's only 4 AVR pins and 1 ISP pin that needs to be looked at)

Well I tested the removable J1 jumper and it does provide or disable power to the target device.

In the photo, there is what looks like set of holes just below the AVR (labeled R8 or A8)
just to the left the black jumper.

Yes R8 on inspection appears to just be two solder pads. What does one do with that those, solder a jumper to force the chip into updating mode?

Since you have a USBtiny, you could use that to upgrade the f/w in the USBasp device
then have a fully functional USBasp device rather than one that mostly works.

I would be willing to give it a shot if I could be somewhat reassured that the firmware upgrade hex file
(where ever that might be located) was compatible with this specific avr8A chip. I bought the programmer on a mostly a lark to see if a $5 programmer could really work with my mega boards and the arduino IDE without a lot of drama involved and so far it does accomplish that task.
I'm not to clear on the actual physical connection I would have to make between my USBtiny programmer and this unit to perform the firmware upgrade, is it just attaching the two 6 pin ISP connector pins together?

Thanks
Lefty


Even if you decide not to update the firmware, it would be nice to know what the jumper does.
It could be slow SCK or VCC power passthrough.
Should take only a few seconds to figure that out.

--- bill



Lefty

bperrybap

Lefty,
I had a look at the files in your link.
The user manual shows that J1 is for power.
They also have zip files for 2 of Fischl's releases (2009-02-28 and 2006-12-29)
Given you are getting SCK warning, I'm guessing that your code may be the 2006-12-29 release
since the 2009-02-28 release has the SETISPSCK command and would not get the warning.
If so, your code is over 6 years old!
You guys should POUND on the vendors for shipping products with such old firmware.
There is no reason for it - Its all open source.
They could simply change the firmware build they use and make things better for new customers immediately.


For  USBasp upgrades:

To be assured that a firmware update will work, it has more do with the connections and board layout
than the actual processor. i.e. just because the code uploads and runs on the processor doesn't mean it will function correctly.

You will first have to identify the processor on the board.
If the label has been sanded off (some vendors do this - which makes no sense on a open source product)
you will have use avrdude to get the signature and then lookup the part based on signature.

After that you will need to verify the board layout and how things are hooked up to the AVR.
The most critical pins are the pins connected to the LEDs, RESET, and the connection
for slow SCK.
Attached is the typical pinout for a atmega8/48/88.
To work with Fischl's firmware,
you need to verify these AVR pins:

This will take some careful looking at the traces on the PCB and may
require the use of a magnifying glass.


29/RESET - needs to connect to a jumper and then to the RESET pin on the ISP connector
(This is the programming jumper)

24/PC1 - this is connected to the Red LED
23/PC0 - this is connected to the Green LED
25/PC2 - This is the input pin for the slow SCK option jumper
(when grounded, it forces slow SCK)

If you have those connections, then the Fischl firmware should work.
I always build my own open source code since I like to know exactly
what I'm getting. You can use a prebuilt firmware .hex image.
Go the fischl site and get the zip image
http://www.fischl.de/usbasp/
If you extract the files, look down in
usbasp.2011-05-28/bin/firmware
in there you will find images for atmega48, atmega8, and atmega88
Note: that the atmega48 image is from 2009 vs the 2011 sources as the latest firmware
is too large to fit in the 4k space on the atmega48.
If you want to build your own atmega48 code image, you will
need to grab the 2009-02-28 zip image.

To upgrade the image, insert the programming jumper,
then connect up an ISP cable from your other ISP programmer
directly to your USBasp ISP connector.
My USBasp device has a 6 pin ISP connector but many have 10 pin connectors.

Make sure your USBasp has power - It can be powered from
USB or from the ISP connector (only one not both) depending on your
other ISP programmer being used.

Then simply use avrdude to upgrade your USBasp with the .hex you built
or the proper pre-built .hex image.

--- bill







retrolefty

Bill;

Thanks for the little kick in the butt. It went quickly and very well uploading the newer firmware and now it all still works but with no silly clock warning message at the end of operations.

Lefty

Go Up