Solved: USBasp vs Arduino as ISP

I had problems to burn a bootloader to an Arduino 328P-AU (TQFP32) on my self made board. First I tried an USBasp which could not get a connection to the target. I checked all wiring around the 328-chip and found that there was no toggling on the osc pins.

After many vain trials I used an Arduino board with Arduino ISP sketch and this was successful. Now the osc pins of the 328P, TQFP, were toggling.

And after that also USBasp can load a bootloader or any sketch.

Reading a lot of postings in this forum I found a hint that some chips are configured internally to use the onboard oscillator. In such chips some fuses need to be burnt to use an external crystal or ceramic resonator. This is the only explanation I can find why initially USBasp failed to burn a bootloader.

Are there further/better explanations and is there a better firmware for USBasp which can burn a bootloader on a new 328P-AU chip?


Show us the schematic of your self made PCB.

here is the schematic around the 328 chip:


The schematic is ok because Arduino as ISP could burn the new chip and after that first upload also USBasp now is able to burn sketches.


The 7805 must have a 100nF ceramic capacitor between the input and GND as close as possible to the leads.

The Analog Vcc and other Vcc leads on the controller are sharing a common 100nF, recommended to have 3 separate capacitors close to the controller leads as possible.

Some crystals do not like the shunt 1M resistor.

All "new" chips are supposed to be configured (via fuses) to use the internal oscillator (8MHz) with another fuse set to additionally divide that by 8, resulting in a 1MHz CPU clock.

There is a a requirement that the ISP clock be less than 1/4 the CPU clock of the target CPU (so, not faster than 250kHz for the default initial configuration.) A 16MHz programmer CAN send SPI much faster than that, and if it does, it will be unable to program the slower chips.

There is an AVRdude option (-B) to slow down the progamming clock. It may or may not work with all USBASP programmers. I think some USBASP programmers have a "slow SCK" jumper that does the same thing (it's on the Original Design), but ... probably isn't well documented on many of the low-priced clones.

There is an AVRdude option (-B) to slow down the progamming clock. It may or may not work with all USBASP programmers.

Here in this forum there is a posting telling that reduction of frequency below 100 kHz could solve a similar problem. But in the Arduino IDE I can't find a way to set this option. How can I do that?

Thank you for your tips and comments. Now I can understand the upload mechanisms.

For a very new controller chip a programmer is necessary which initially reduces the clock to <250 kHz. My USBasp obviously does'nt do this, but Arduino as ISP does. It is a weak point of USBasp firmware - at least of my version.
After a very first upload via Arduino as ISP also USBasp can be used for further uploads or I can find a method to force USBasp to a very low clock frequency.

I also learned some issues about blocking capacitors.
On the other hand I wonder at the simple design around the reset pin of most Arduino boards. There is a resistor from the reset pin to VCC and a 100nF capacitor from reset pin to DTR of the USB to serial converter.
Switching of DTR to low level causes a short low pulse to the reset pin which is the expected effect. But swiching of DTR to high level causes a positive pulse much higher than VCC which is out of specification. Only in the Uno schematic there is a diode to avoid this high pulse. I will insert such a diode in my board design.

1 Like

High level pulse is actually in the specification provided it remains below 13VDC. The reset pin is the only pin that can withstand higher voltages (refer to "Absolute Maximum Ratings" in "Electrical Characteristics" (§29) in ATmega48A; ATmega48PA; ATmega88A; ATmega88PA;
ATmega168A; ATmega168PA; ATmega328; ATmega328P - spec).

Despite, a fast-switching diode is a good idea.

Yeah, but it puts the chip into HV Parallel Programming mode, which is NOT something you normally want to do on an Arduino!
The diode was added to the Uno design sometime after the original revision, because it was actually causing bad behavior in the field.

Oha! Ok, as - I guess - nobody is really interested for the parallel programming mode (never heard before, I have do admit) the diode is avoiding this for sure (even though, after cross check of data sheet, the activiation process is a little more than that).
But, defensive design is preferred (as you said), so with diode :slightly_smiling_face:

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.