Quick question: "Is there something preventing USBASP from bootloading or uploading sketches to fresh chips(mine 328p and 2560 TQFP packages)? why the arduino as ISP works and USPASP not works for fresh chips and after bootloading through Arduino as ISP, the USBASP begin to bootload and upload sketch?
Detailed question below
Past week I was trying to solve the problem myself and after one week of research and searching through forums, realized no body faced similar issue and decided to ask for help.
So the problem is I made a custom board having an Atmega 2560 and Atmega 328p both SMD package and supposed to communicate each other through serial. Before making board, I made both SMD packages in independent SMD to DIP modules and bootloaded using arduino as ISP and they started communicating through each other successfully. I tried the chinese USBasp to burn bootloader to Atmega 328p DIP in breadboard and an Arduino Nano to make sure it can bootload and upload code and both worked and made the board with 10 pin connector for upload sketcht using USBASP programmer. After my custom PCB arrived I tried to upload code to Atmega 328p and I got the error
avrdude: Version 6.3-20171130
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"
Using Port : usb
Using Programmer : usbasp
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : usbasp
Description : USBasp, http://www.fischl.de/usbasp/
avrdude: auto set sck period (because given equals null)
avrdude: error: program enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
Error while burning bootloader.
So I though there might be a problem with my soldering or wiring(Even though I triple checked it), I went to bootload the 2560 and again I got the same error. Below are the methods I tried so far and their results. After 4 days of continues trial and error, I proceed to try arduino as ISP and it worked for both 328 and 2560. I made a 10 pin FRC connector for USPASP programing and used the same pins for arduino as ISP so my connections and related things in both cases are same.
Changed the 22 pF caps with new one for both 328 and 2560 - Not worked
Changed the 16 MHZ crystal with new one for both 328 and 2560 - Not worked
Changed the 328 and 2560 with fresh new ones - not worked
Soldered fresh 328 and 2560 to another same type board and checked - not worked
Finally I went on to bootload an arduino nano with USBASP and it worked. So I desoldered that working bootloaded 328p chip from NANO and solder in the position of current 328p(Removed) and USBASP started bootloading and uploading sketch(So I realized the soldering was Ok and crystal and 22 pF caps, pullup and connections were OK). - So that worked
After that used a FT232 to bootload using arduino as ISP method and it worked for another board with fresh 328p and 2560 in it. After that tried the USBASP for bootload and upload programmes and it worked for this board which now bootloaded with Arduino as ISP using FT232 which was not able to bootload through USBASP. - So that worked
So my question is "Is there something preventing USBASP from bootloading or uploading sketches to fresh chips? why the arduino as ISP works and USPASP not works for fresh chips and after bootloading through Arduino as ISP, the USBASP begin to work?
I Have access to a DSO but frankly no experience with it.. If it helps
NB: The first board Soldered with 328p and 2560 not bootloadable with arduino as ISP as well USBASP even after changing the crystal and caps(I Did tripple check wiring, 10K pullup, voltages and all possible methods known to me). Now planning to move the bootloaded chips to that board and will update status here..
If your USBasp programmer has the official firmware, you must short the JP3 jumper to program chips that are running at <=1 MHz clock speed. The factory default clock configuration is running on the internal oscillator at 1 MHz (which is why the fresh chip couldn't be used, but once the fuses had been set for a faster clock, it works). Many of the common Chinese USBasp clones come with a modified firmware that is able to work with chips running at the slower clock speeds without needing to set the jumper. There is also a alternate open source firmware provided by the community that has this functionality.
Thank you very much for the quick reply. I'll try to upgrade the firmware but I dont have another USBASP at the moment with me to upgrade current one. During my check WRF to your reply, i dont have a jP3 jumper, I have JP1 and selection jumpers of 3.3V and 5V only. Please have a look at the attached pic of the current one I have
Thank you very much for pointing that out. I missed it till you mention that. I tried to solder a jumper there and after that I'm getting the message "USB device not recognized". I'm pretty sure, I didn't do anything except solder a jumper there! Ordered another USBASP and by the mean time, any suggestion to make it work back? I can measure the 5.0 volt in all expected VCC points and none of the LED's are turning ON
Below are the message from windows
Windows has stopped this device because it has reported problems. (Code 43)
A request for the USB device descriptor failed.
Tried to install driver using Zadig and that also fails showing "The driver installation failed"
NB: I tried removing the new solder also
I'm sorry to hear you're having trouble with the USBasp. It's not clear to me from what you wrote, are you having that problem now even when JP3 is not shorted?
Thank you for your replies. Pert, you are right, the problem is there with and without the solder jumper on JP3. Please find a link below where I purchased USBASP(It's and Indian site, but the item from China I believe. The picture is little different than the one I have as in my previous post)
NB: I'll receive the new USBASP tomorrow, but I would like to repair the current one if it can be done. Thanks in advance
I would be suspicious that diode right next to the jumper might have been damaged while soldering. That's part of the USB system, so it fits with the symptoms.
The BOM for the official USBasp lists them as "3v6 Zener, Reichelt No ZF 3,6". You could try replacing the diode to see what happens.
It's never a bad thing to have a couple USBasps on hand. I have 10, more than a lifetime supply for sure, but I still don't regret it!
...
The picture is little different than the one I have as in my previous post)
...
Yes, it is different. Anyway, I do not think I was wrong advice (about jumper). It is weird to me. Here is author's schematics: https://www.fischl.de/usbasp/
In this case it is labeled as JP1 (your JP1 is self programming) but simply it should connect ATmega's pin 25 to GND. Check this carefully on your board, also whether there is a problem with traces or not. I think, it is just some HW related thing. They use same FW from Mr. Fischl regardless board shape.
pert:
I would be suspicious that diode right next to the jumper might have been damaged while soldering. That's part of the USB system, so it fits with the symptoms.
Budvar10:
They use same FW from Mr. Fischl regardless board shape.
There is apparently a modified proprietary firmware on some of the Chinese clones. The evidence is that these clones cause a spurious "update your firmware" notice from avrdude, but they actually have a superior automated clock setting that makes this jumper business unnecessary. People see that firmware update message from avrdude, "update" their firmware, and then find that their programmer is suddenly inferior to its previous functionalities. You can't reinstall that proprietary firmware because the manufacturer set the lock fuses to protect it.
Fortunately, the Arduino community came through with an open source enhanced version of the original firmware that has all the features of the clone firmware, plus more!
I didn't have a 3.6V zener. There was a 5.1V zener lying arund and I changed and the error still there. And my new USBASP arrived(2 numbers). I tried to bootload this damaged one and I could bootload it. Tried to upload the enhanced firmware in your link using AVRDUDE and that also worked(Snippet below).But still same windows error and no LED's!
Detected 1e9307 = ATmega8
usbasp-v1.05-2015-12-29-atmega8.hex: 8,192 / 8,192 Bytes (100.00%)
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
avrdude.exe: set SCK frequency to 1500000 Hz
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude.exe: Device signature = 0x1e9307
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: set SCK frequency to 1500000 Hz
avrdude.exe: reading input file "D:\Backup\usbasp-1.06\bin\firmware\usbasp-v1.05-2015-12-29\usbasp-v1.05-2015-12-29-atmega8.hex"
avrdude.exe: input file D:\Backup\usbasp-1.06\bin\firmware\usbasp-v1.05-2015-12-29\usbasp-v1.05-2015-12-29-atmega8.hex auto detected as Intel Hex
avrdude.exe: writing flash (8192 bytes):
Writing | ################################################## | 100% 61.05s
avrdude.exe: 8192 bytes of flash written
avrdude.exe: verifying flash memory against D:\Backup\usbasp-1.06\bin\firmware\usbasp-v1.05-2015-12-29\usbasp-v1.05-2015-12-29-atmega8.hex:
avrdude.exe: load data flash data from input file D:\Backup\usbasp-1.06\bin\firmware\usbasp-v1.05-2015-12-29\usbasp-v1.05-2015-12-29-atmega8.hex:
avrdude.exe: input file D:\Backup\usbasp-1.06\bin\firmware\usbasp-v1.05-2015-12-29\usbasp-v1.05-2015-12-29-atmega8.hex auto detected as Intel Hex
avrdude.exe: input file D:\Backup\usbasp-1.06\bin\firmware\usbasp-v1.05-2015-12-29\usbasp-v1.05-2015-12-29-atmega8.hex contains 8192 bytes
avrdude.exe: reading on-chip flash data:
Reading | ################################################## | 100% 46.17s
avrdude.exe: verifying ...
avrdude.exe: 8192 bytes of flash verified
avrdude.exe done. Thank you.
This tells us the microcontroller is working at least to a fair extent. Since you're using a different interface (ICSP) for flashing the microcontroller, it leaves the possibility the microcontroller pins connected to the USB are damaged.
