Need help troubleshooting upload problem

I am unable to upload to some, but not all of my Arduinos. I have already done a bunch of troubleshooting and don't know what else to try next.

I CAN upload to my Uno, Leonardo, and 3 Megas. They all use the Arduino Serial driver, I am currently on version 1.2.2.0 dated 6/15/2015 of it. I believe this particular version came with the 1.6.5 IDE. Previously, I had a later version that came with 1.6.8.

I CANNOT upload to anything using any other serial driver, including Lilypad and Micros using an FTDI adapter, and to 4 nanos using FTDI, Prolific, and CH340 serial chips. I get the error: avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x0a

I am aware of the issues with FTDI and Prolific counterfeit clones and how the newest drivers don't work with them. I am using older drivers. I've tried numerous versions, and at the moment I am using FTDI driver ver 2.8.24.0 dated 4/10/2012 and Prolific driver ver 3.2.2.105 dated 10/27/2008. My Prolific is indeed a counterfeit clone, and 1 of my FTDIs are clones, but at least 2 of my FTDIs are genuine. I am not getting the "NON GENUINE" message.

I have performed the loopback test on all 3 of my FTDI serial adapters by connecting TX to RX. All of them loopback fine. I have performed the loopback test on the nanos by bridging TX to RX and Reset to Gnd. Again, all fine.

I can receive serial output from all of them from the existing sketches that are on them (Debug messages I put in my sketches).

I rolled back to Arduino 1.6.5 as was suggested on the forums as the last stable version for uploading. I uninstalled 1.6.8 first using Revo uninstaller to remove all traces of it.

I can successfully download and/or upload from my IR Toy, Bus Pirate, Pronto Remote, and my Christmas light controller, which use various serial chips.

I am having this problem on both my desktop computer and my laptop.

What do I do next?

:frowning:

UPDATE: I've also tried running avrdude manually from the command line. Tinkered with the -c (programmer) option, and tried all different baud rates. No luck. I should also mention I've tried multiple cables.

Example: avrdude -v -c stk500v1 -pm328 -Pcom9 -b19200 -D -Uflash:w:Heartbeat13.ino.hex

DrWizard:
UPDATE: I've also tried running avrdude manually from the command line. Tinkered with the -c (programmer) option, and tried all different baud rates. No luck. I should also mention I've tried multiple cables.

Example: avrdude -v -c stk500v1 -pm328 -Pcom9 -b19200 -D -Uflash:w:Heartbeat13.ino.hex

Have you tried ISP programming, using Arduino as ISP and the "ArduinoISP" sketch?
That should work, since it doesn't require a USB to TTL converter, and would be a temporary work-around, at least. (The downside is that you couldn't do serial prints to the serial monitor.)

If you are desperate (you said in another thread "I've wasted about 20 hours trying to get it to work.") you can bypass all these Windows drivers and crap and do your own programming of the board. I have a sketch here:

Atmega chip stand-alone programmer to upload .hex files

Do the compile with verbose compiling turned on. Copy the resulting .hex file to an SD card. Use the sketch there on a spare Uno to burn the target board. I've used that multiple times when working on targets that, for one reason or another, can't be directly programmed through the bootloader. The process takes a couple of minutes, once you've copied the file, and moved the SD card around.

You need about $15 of extra hardware (the SD card interface board). It's handy to have it lying around in general, for example if you lose the bootloader, or want to program the board without a bootloader (to get the last few hundred bytes out of program memory).

The advantage of this is that you don't have to muck around trying to convince Windows (or avrdude) to locate a specific comms port. Of course, you need to have an interface to "talk" to the programming sketch. If even that is problematic, at the end of the thread I linked is a way of doing it with a standalone board which just uploads a file by fixed name, without needing any comms interface at all.

You can buy a pre-made board which does that (mentioned in the link) or just make up your own if you don't mind a few wires, switches, and LEDs everywhere. :slight_smile:


Warning: Uploading a sketch this way erases the bootloader (since it does a chip erase). You can put the bootloader back easily enough, I'm just warning you that it happens.

Can you do the loopback test and post your results - I have had 7 'Arduino UNOs' sent to me for repair, and they were clones with fake FTDI chips that had been stung by the FTDI driver update.

Have you tried ISP programming, using Arduino as ISP and the "ArduinoISP" sketch?
That should work, since it doesn't require a USB to TTL converter, and would be a temporary work-around, at least.

That is my project for today. I might as well try uploading a new bootloader while I'm at it in case they really did get corrupted somehow (don't see how 6 separate ones would all get corrupted at once, unless there was something screwy with sketch uploads that fouled up the bootloader(?)) and may even try the 'optiboot' loader.

The downside is that you couldn't do serial prints to the serial monitor.

Not a problem, as I mentioned above, that works.

you can bypass all these Windows drivers and crap and do your own programming of the board.

Gammon: Looked at your page and that thing is really cool! I can built an easily portable programmer to update my gadgets such as the sprinkler controllers and traffic light controller without dragging the laptop out into the yard! Definitely will build one and I already have everything I need laying around. Gammon, I never cease to be amazed by many of your answers!

I was also considering getting an AVR-ISP programmer such as the Sparkfun Pocket AVR Programmer Link-Sparkfun which I can get off of Amazon Prime for $16 and have it in 2 days. I'm concerned thought that it may suffer the same problem as the FTDI, Prolific, and CH340 interfaces.

Can you do the loopback test and post your results - I have had 7 'Arduino UNOs' sent to me for repair, and they were clones with fake FTDI chips that had been stung by the FTDI driver update.

Proto-Pic: Have done many loopback tests, and they all work. Also, not all my boards have FTDI chips, and I am fully aware of the FTDI driver issues (and Prolific's) and I am using the old drivers.

Thanks everyone for their suggestions. I WILL solve this! And report back when I do.

If your programmer gets too messy, and for others that are after standalone programmers from SD cards, I have cards all made up with all the components, with No display (only programs 1 file), 1 display (select one of 16 files), and 2 displays (select 1 of 256 files).
http://www.crossroadsfencing.com/BobuinoRev17/Programmer.html
Here's the 2 display card in action.

Yep, that card of CrossRoads is quite cool. You turn the rotary encoder on the front to select which file you want, then press the Upload button. The 2-digit LED give you status codes during the programming, which is quite nice. Plus it is all compact. Not like my cobbled-together thing. :slight_smile:

Although I did assemble a custom version of my original design (that still needs the serial comms), simply because I use it so often. That's all on one board and is quite easy to use.

I can't take all the credit Nick - it's your code in the background that lets my hardware do it's thing :slight_smile:

STATUS UPDATE:
I wired up my Uno as an ISP programmer, and uploaded the ArduinoISP sketch to the Uno. If you will recall, I said the Uno, Leonardo, and Mega boards (which use the Arduino Comm driver) work. Then I connected my nano to the Uno via the ISP connector and successfully uploaded the blink sketch to it. However, it also uploaded the blink sketch to the Uno. Double-checked the 'Programmer' setting on the tools menu, and it was set to 'Arduino as ISP'. Uploaded the ArduinoISP again, and, and it went to both the Uno and the nano. Looked at the verbose output of the upload, and noticed that the -c switch for avrdude was set to -carduino by the IDE. Experimented with different programmer settings on the tools menu, and the -c switch was ALWAYS set to -carduino by the IDE, no matter which programmer I selected.

Installed Arduino IDE 1.6.5.r5 on my girlfriend's laptop, which has never had Arduino or any other kind of development stuff installed on it. Same thing. Tried uploading normally to the nano, micro and lilypad with FTDI, Prolific and CH340 chips on her laptop, no luck, same problem, the st500_getsync error.

But wait, it gets weirder. Now my main machine has started working again! I have not installed, uninstalled, reinstalled, or updated anything. Haven't even rebooted for several days. I can now upload again, the normal way, to my nanos, micros and lilypad! Checked the Microsoft installed updates log and the only thing installed recently is a Visual Studio update.

While I am quite happy that it is working again, I'm befuddled that I don't know why it broke to begin with or how it fixed itself.

I've never heard of such a thing. Try modifying blink a bit (make asymmetric blinks). I find it hard to believe that it does two uploads when it is supposed to be doing one. Bear in mind that the bootloader blinks three times normally, maybe that is what you are seeing.

The reason it uploads to both, is because avrdude was always being launched with the -carduino programmer option. So it uploads to whatever happens to be connected to the com port (the Uno), and then also the other one because it's daisy chained on the ISP connector (the Nano). I expect it would work correctly if the IDE launched avrdude with the correct -c programmer option.

My main machine (desktop) mysteriously fixed itself. My laptop is still exhibiting this problem. I'm still trying to track down WHY. They are both on IDE 1.6.5.r5.

... and then also the other one because it's daisy chained on the ISP connector (the Nano) ...

You've done what?

Please post a photo or wiring diagram.

Uno as programmer
Nano to be programmed

Uno Nano Color
Gnd Gnd Black
+5V +5V Red
10 Reset Yellow
11 MOSI Brown
12 MISO White
13 SCK Orange

So it uploads to whatever happens to be connected to the com port (the Uno), and then also the other one because it's daisy chained on the ISP connector (the Nano).

That can't be happening because if it was you would have replaced the ArduinoISP sketch on the Uno. Only one device will be programmed.

Nice mat, BTW.

because if it was you would have replaced the ArduinoISP sketch on the Uno

Yes, that is exactly what happened! But I now think I realize what I was doing wrong (?). I was just hitting the upload button on the toolbar. I didn't realize there was a "Upload Using Programmer" option on the Sketch menu.

But FYI, here's what I did:

  1. I connected only the Uno.
  2. Set COM port to COM7 and board to "Arduino/Genuino Uno"
  3. I uploaded ArduinoISP sketch to it. (Using toolbar button)
  4. On tools menu, set programmer to "Arduino as ISP", set board to "Arduino Nano"
  5. I connected Nano.
  6. I uploaded blink sketch (Using toolbar button) (actually, my variation of it called Heartbeat13 which does a double blink like a heart beating).
  7. LED connected to pin 13 of both the Uno and the Nano began blinking in a heartbeat pattern.
  8. Set board back to Uno, and Programmer back to AVR ISP.
  9. With Nano still connected, re-uploaded ArduinoISP.
  10. LEDs on both Uno and Nano stopped blinking.
  11. re-uploaded Heartbeat13 sketch.
  12. LEDs on both boards began blinking in heartbeat pattern.
  13. Checked Tools -> Programmer setting. Still set to "Arduino as ISP".
  14. Went to options, turned on verbose option for upload.
  15. uploaded Heartbeat13 again.
  16. Checked output window. IDE had launched avrdude with -carduino programmer option.
  17. Disconnected Nano.
  18. Opened serial monitor. Uno was sending "Heart...beat" to the serial port. (As it should, that's in my Heartbeat13 sketch)
  19. Disconnected Uno, connected Nano, changed COM port under Tools menu.
  20. Opened serial monitor. Nano was sending "Heart...beat".
  21. Repeated steps 1, 2, verified step 3, repeated step 4. Same results.
  22. Set programmer to "Parallel Programmer"
  23. Uploaded successfully to both boards. Checked upload log, avrdude was launched with -carduino.
  24. Set programmer to "Bus Pirate"
  25. Uploaded successfully to both boards. Checked upload log, avrdude was launched with -carduino.
  26. Set programmer to "USBasp", repeat. Same results...

Thanks for the compliment on the mat! Just got it recently, custom ordered from Amazon (comes from China) only $4 and they will put your own image on it. Huge 13" X 11". Image is of my ceiling in the Home Theater room, with plastic glow stars and a blacklight.

I was just hitting the upload button on the toolbar.

Which version of the IDE are you currently using? I found with 1.6.7 the toolbar button seemed to do "upload using programmer" but it is usually "upload". I think the menu is safer.

I had been using 1.6.8. When I started having upload problems I reverted to 1.6.5.r5, as many people on the forum have been saying it's the most stable recent release regarding upload issues. I also normally use Visual Micro (Love it! Highly recommended!), but temporarily switched back to the Arduino IDE because the upload problems.

Remove the nano and see if the led on uno still does the heartbeat13.
The pin 13 of uno and pin 13 of nano are actually connected, hence when nano blinks, uno blinks.
These are SCK pins,correct me if I am wrong.

-Malhar

Good point. Since you have connected SCK together this behaviour is quite reasonable. A much better test would be to flash a pin that is not connected to the other board.