For the past few weeks, I've been happily playing with my Arduino Uno Elegoo R3, which worked "straight out of the box". I had a delivery from Amazon this afternoon of 3 AITRIP Nano V3.0's with USB cables. I've been trying to upload the (unmodified) blink sketch, to eliminate anything really stupid I may be doing, but without success.
Info:
OS: windows 10
Selected in the IDE:
Board: Arduino Nano
Processor: ATmega328P (which matches the chip on the board)
Port: COM6
Programmer: ArduinoISP (but I've also tried most of the others)
Error messages:
Arduino: 1.8.13 (Windows 10), Board: "Arduino Nano, ATmega328P"
Sketch uses 924 bytes (3%) of program storage space. Maximum is 30720 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2039 bytes for local variables. Maximum is 2048 bytes.
C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -carduino -PCOM6 -b115200 -D -Uflash:w:C:\Users\44793\AppData\Local\Temp\arduino_build_56906/Blink.ino.hex:i
avrdude: Version 6.3-20190619
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 : COM6
Using Programmer : arduino
Overriding Baud Rate : 115200
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x3e
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x3e
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x3e
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x3e
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x3e
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x3e
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x3e
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x3e
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x3e
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x3e
avrdude done. Thank you.
Problem uploading to board. See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.
This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.
I've tried the loopback test, and it works fine. I've tried all 3 boards and all 3 cables with the same outcomes. I've searched in various places, and found others with similar problems, but did not find a satisfactory resolution.
Any and all help gratefully received.
Unfortunately, I don't know what causes this "protocol error" error. I have a small collection of similar reports I have been meaning to review to see if the related discussions ended up revealing any explanations or solutions, so you might take a look at these:
Thanks for responding. I'll follow the links, and also try different programmers, using the "Old bootloader" setting. But it's nearly my bedtime, so might have to wait 'til tomorrow.
Bingo! I tried the AVR ISP progammer, being the first on the list, and it worked! Confirmed by changing the blink delays and re-uploading. Many thanks (and a bit of karma!).
Unfortunately, I don't know what causes this "protocol error" error.
Addendum: I tried using a longer (1m), poorer quality cable today and uploading was very hit'n'miss. I thought the previous error had come back, but it worked about once in 5 or 6 attempts. Changed back to cable supplied with board (300mm, looks good quality, well screened) and (touch wood) it works every time.
Don't know if these boards meet USB standard - rather doubt it, because the suspect cable works fine with other devices.
Bear in mind if you are using a programmer rather than the USB connection you will over write the bootloader with your sketch and the USB won’t work for uploading .
Hi I'm a newb at all this and had the same issue, although I found that selecting the "Arduino Duemilanova or Diecimile" solved the problem and did not cause any issues on reboot. I'm using version 1.8.13 on windows 8.1
jofi62:
Hi I'm a newb at all this and had the same issue, although I found that selecting the "Arduino Duemilanova or Diecimile" solved the problem and did not cause any issues on reboot. I'm using version 1.8.13 on windows 8.1
This means your Nano has the old bootloader. It would likely be less confusing to just do as Arduino's developers intended and select Tools > Processor > ATmega328P (Old Bootloader), but if you prefer using the "Arduino Duemilanove or Diecimila" board selection for your Nano, you're welcome to do so.
Further news on my Nano (or cable) problem. I currently have two (apparently) identical Nanos - bought at the same time from the same vendor - connected, with the 300mm cables supplied, to an unpowered USB hub (I'm experimenting with inter-Arduino I2C communication). I have 2 instances of the Arduino IDE running. During the day (9am to about 4:30pm) I can upload to either board with no problem.
After about 4:30, uploading to one of the boards fails. At first it's hit-and-miss, but gets worse as the time goes by. This has happened on 3 successive days. Last night, the COM port associated with the "dodgy" board disappeared. I have yet to experiment with swapping the boards, cables and hub ports. I have a 3rd Nano (with cable) from the same batch, so I might throw that into the mix - tho' I'd rather not, as it's wired up in another project.
All I can think of at present is that one of my close neighbours is using something noisy (perhaps a light dimmer), but why it only affects one system, and why it gets progressively worst, is beyond me.
Whilst noisey electrical systems can and have been seen to cause some issues with Arduino's they are not usually an issue during uploads unless extra circuitry to the Arduino is involved.
If that is the case simply try removing it prior to an upload.
Other hit and miss can have a few causes not least of all is USB 3.x ports in which case USB 2.0 ports or a USB powered HUB usually fixes most of those.
As you have seen USB cables themselves can also play a large part and the quality of the cable can be questionable with the investment in a good quality one often being well worth the expense.
My own preference is for the thicker ones with the ferrite cores as part of the cable as they tend to operate over longer lengths much better.
