Hi everybody,
I'm writing because I'm having some problem flashing the USBasp I bought.
First of all, I have Ubuntu, so from my terminal I installed avrdude as such:
Then I took my USBasp and try the JP2 pinouts to shortcircuit them and set it to self-programming mode.
Here it is my USBasp, I shortcircuited the two pins over "JP2":
Then I plugged my Arduino to my PC, uploaded the ArduinoISP sketch (File->Examples->ArduinoISP->ArduinoISP sketch), then I set my Arduino as AVRISP mkII (Tools->Programmer->AVRISP mkII) and plugged my USBasp to the Arduino board as such:
Once I did that, I wanted to flash the ".hex" file I downloaded from here USBasp - USB programmer for Atmel AVR controllers - fischl.de into the USBasp Atmega8.
So I opened up my terminal, I changed directory to /firmware inside the /bin directory, and wrote the following line:
I really look forward to receive some good advices to finally solve the problem because I've struggling for a very long time now.
Thanks very much for the help!
The device sig it's reporting is for the ATMEGA328P and not the ATMEGA8A.
Looks like it's trying to flash your Arduino and not the USBASP.
You should select 'Arduino as ISP' for the programmer in the IDE and not AVRISP MkII.
IIRC, in Linux, the USB port is like /dev/ttyUSB0 or something like that.
These are just comments, they may not be pertinent.
Concerning the signature issue: I'm not sure that you should set the self programming jumper (I don't have an USBASP), since you are using an external programmer to upload.
I think avrdude indeed talks to your arduino. My guess is, it is an uno and you did no disable autoreset, so the uno resets and avrdude communicates with the bootloader.
You do need the jumper over j2.
Note the pinout you attached is not for those blue boards: pins 4 and 6 are not ground, they are tx and rx. So pick pin 8 or 10 for ground.
You must install the self programming jumper in order to re-program the avr on the USBasp device.
This connects the reset pin of the AVR to the reset pin on the 10 pin header.
As-is without the jumper, the reset pin on the 10 pin header is connected to an AVR i/o pin so that the USBasp f/w can yank it low to program another AVR chip.
If using Arduino as ISP to program the AVR on the USBasp device you must first upload the sketch
and then use the Arduino as ISP programmer type as well as disable the Arduino auto reset.
If you don't disable the Arduino auto reset the avrdude running on the PC will be talking to the UNO bootloader rather than the arduino as ISP sketch. This will cause avrdude to see a m328 instead of the real target AVR chip.
The one tricky thing that you can run into is that the jumper labels on your USBasp board may not match the official USBasp jumper labels.
i.e. the jumper labeled as "jp2" on your USBasp may not be the self programming jumper.
I had this issue so I recommend that you use a visual inspection to follow the PCB traces for the JP2 traces to make sure that it connects to the AVR reset pin as well as the reset pin on the 10 pin header.
As long as you can verify one of those trace connections, you can know it is the correct jumper.
I modify the USBasp makefile so I can use the built in rules like "flash" to program the part.
You will also want to fix your udev entry for ISP device and your group permissions so you don't need to use sudo to talk to ports.
In terms of disabling auto reset. I can't help you there since I don't use ever use Arduino as an ISP as I have another ISP programmer. I used an AVR dragon to re-program my USBasp device.
Pin 10 on the 10 pin ISP header is ground that shouldn't be connected to the self-programming jumper.
Pin 5 on the 10 pin ISP header is ISP reset. That pin should be connected to to the self programming jumper.
The self programming jumper (normally labled J2) connects the AVR reset pin to the ISP header connector ISP reset pin (ISP header pin 5)
Pin 5 on the ISP header (ISP reset) also connects to an AVR i/o pin normally PB2.
In normal operation the AVR will drive PB2 i/o pin to control the ISP reset pin on the 10 pin ISP header.
In self programming operation, the ISP programmer will be driving the ISP reset pin on the 10 pin ISP header and that is why the ISP reset pin must be connected to the AVR reset pin.
That is what the self programming jumper does.
However, not all USBasp boards label their pins the same way.
For example the one I have uses the same schematic but labels the jumpers differently.
Here is the official ones compared to mine:
Jumper Fischel KKKusbasp
J1 Target VCC Slow SCK (hooks to pin 25 which is PC2 pin)
J2 Firmware upgrade Target VCC
J3 slow SCK option Firmware upgrade (hooks to ISP reset)
So mine uses J3 instead of J2.
I had to follow the traces to see which jumper was which as there as no documentation.
Also complicating matters is that a few of the USBasp boards change the i/o pins used and ship with altered firmware. With those boards, they will no longer work when upgraded with the stock firmware. You have to go in and tweak the code and rebuild the image to work with the pins they used.
Luckily there are not very many of those as most follow the stock schematic for the i/o pins.
Beyond wiring up the ISP header connector wires, you have to make sure the AVR reset pin is connected to the ISP reset pin and then ensure that if using an Arduino as your ISP programmer ensure that the it is not autoreset when avrdude runs.
If you are seeing the 328 signature the Arduino is resetting.
If you get a signature of 0's or timeout messages then then more than likely either ISP wiring is incorrect or the AVR is not being reset by the ISP reset signal.
I thank you for the exhaustive answer, I got what you are saying, but in order to understand if I'm doing it wrong I should disable Arduino UNO autoreset so I just want to know if these sketches ( Imgur: The magic of the Internet, Imgur: The magic of the Internet) are correct in order to proceed.
I'm talking about what PeterVH said:
PeterVH:
The /dev/ttyACM0 you used first, is the correct one.
Did you disable autoreset on the uno? A 10uF cap between rest and gnd will do.
I had a look on your schematic, it looks ok to me.
I have the same blue lc technology usbasp clone, J2 is indeed the 'self' programming jumper, it should be closed.
Most people use the 10uF cap solution instead of the resistor one. I used it myself a lot. If you don't feel comfortable about the cap forcing reset high, you can also cut the RESET-EN trace. It can be cleanly closed afterwards.
angelosanzeri:
I really look forward to receive some good advices to finally solve the problem because I've struggling for a very long time now.
my advices is to stop screwing with usbasp reflash. in my experience theres never a reason to do so. at least not in windows world. maybe linux has some fundamental defect that makes it necessary but i doubt it.
on the other hand i have seen many struggling (where did i hear that word?) with this process and often accomplish little more than brick the programmer or the target or both.
john1993:
my advices is to stop screwing with usbasp reflash. in my experience theres never a reason to do so. at least not in windows world. maybe linux has some fundamental defect that makes it necessary but i doubt it.
John, I couldn't disagree more about having a reason to run the latest USBasp firmware.
Using the more recent USBasp firmware is very useful as it allows setting the ISP clock rate from avrdude. This allows setting the clock to a slow rate when programming and setting fuses in a virgin AVR. Without this capability you have to install a jumper to slow the clock because if the clock remains fast you will not be able to program a virgin AVR to be able to set the clock to 8Mhz or to set the fuses for a crystal.
To me it is a very useful feature to be able able to run the clock fast or slow when desired/needed and never have to mess with any jumpers on the USBasp device to do it.
The clock rate issue is not related to a particular OS.
Also there are some additional ISP features that can allow the uploads be be a bit quicker.
So all in all it is a useful update if your USBasp device is not running the latest f/w.
It isn't hard to reflash the USBasp device.
What can make it tricky or hard is when trying to use Arduino as ISP as there are many "gotch Yas" around the Arduino Auto-reset.
angelosanzeri,
The reason you are seeing different ways to "disable" auto-reset is that it varies depending on which revision of Arduino h/w you have.
The auto-reset circuit on the Arduino was a h/w solution to a s/w problem. And the auto-reset circuitry itself has issues, particularly on the pre-Uno boards.
There was an issue that depending on the signal being fed into the reset/auto-reset circuity, a high voltage spike/bounce could be generated on the AVR reset pin that could end up erasing the part or corrupting it in bad ways.
The auto-reset circuit was altered to include a protection diode and after that was done, the simple resistor that was being used to disable the auto-reset circuit wouldn't work anymore and that is why a cap is now used.
Which hack you use to disable the auto-reset depends on which version of the Arduino you have.
bperrybap:
John, I couldn't disagree more about having a reason to run the latest USBasp firmware.
i know you have more experience playing with the firmware but we will have to agree to disagree this. ive had a few hundred of the Ebay units pass through here for academic and business use and never saw a single case where virgin 8mhz chips needed jumper or -b. i don't know how to explain our differences but can only relate my own experience.
i will say that the particular unit op has suffers from a fatal circuit design flaw. over a dozen of the exact same version (lc 2.0, purchased from different sources) were recently sent to me for testing and 3 failed with a particular bare m8 circuit. the fault was traced to lack of output cap on the lm1117 regulator ic. This is easily verified by the photos in post #1. my theory is this is the real cause of many issues brought up here and elswhere on the net. in any case tacking a 1mf ceramic across pins 1-2 fix the defect.
as mentioned before better solution is to order the "baite" type with skewed m8 which does not suffer from this defect. only a few pennies more and which now has a 3v-5v switch instead of the current lc with jumper or previous lc rev with neither.
of course i have not checked every single unit manufactured since that version came out 4 yrs ago so who knows. ymmv.
john1993:
i know you have more experience playing with the firmware but we will have to agree to disagree this. ive had a few hundred of the Ebay units pass through here for academic and business use and never saw a single case where virgin 8mhz chips needed jumper or -b. i don't know how to explain our differences but can only relate my own experience.
Virgin 8mhz chips?
Virgin AVR chips like the m8/168/328 are internally clocked at 1Mhz by the factory set fuses and that is what can create the problem.
The way the AVR is implemented, the MCU uses the programmed MCU system clock during ISP programming.
see section 8.2.1 of the manual:
So when it is using the internal 1Mhz clock or using an external clock that is even slower, you have to slow down the ISP clock frequency during ISP programming in order to be able to program the part because the ISP clock cannot be faster than 1/4 the frequency of the MCU clock.
Many ISP programming devices use an ISP clock that is faster than than what will work with a 1Mhz AVR.
Some USBasp devices are shipped with modified USBasp firmware to always run a slow ISP clock by default or reverse the jumper operation where out means slow and in means fast.
While this ensures it will work with factory AVR parts, once the AVR is running faster it is programming the AVR much slower than what is possible.
Here is an video from Atmel that explains and demonstrates the issue:
But like I said the best option is to have USBasp firmware that supports setting the clock speed so you can run slow when you have to and fast/faster when you can.
yes, i should have said 8mhz w/div8. my point was there was never need for me to change speed with jumper or in avrdude. not in 100s of thousands of chips flashed. some rare failures but not for that.
bperrybap:
Some USBasp devices are shipped with modified USBasp firmware
this may explain our difference of opinion. i know for a fact the chinese units i am buying do not use the old or the new official firmware. the images do not match. most likely they started with the older rev and fixed the important issues like clock speed. these are not slow pokes though.
bperrybap:
But like I said the best option is to have USBasp firmware that supports setting the clock speed so you can run slow when you have to and fast/faster when you can.
i would agree but to be honest i dont recall ever having to change the speed for a usbasp. what i do know is the fischel images (old and new) caused trouble for me and chinese versions did not. im convinced most "problems" are due to beginners not knowing the difference between the harmless update warning which should be ignored and real errors. and issues encountered when following that (what i consider) bad advice.
imo statistically second to that would be misbehaviors due to hardware defects like the one mentioned above.
