Arduino DUE upload problem, fixed?

Hardware Arduino Due
#1

Hello ArduPeeps,

In the past 3 weeks, I've been able to get my new DUE to do everything I want. So far, it's quite nice. Fast. Plenty of code & RAM space for my needs. 120K of code and still growing!

The one major headache has been with the upload process. It was really, really unreliable.

I'd often get the dreaded "An error occurred while uploading the sketch" message. About 9 out of 10 times. I'd then reset the DUE, press the erase button, restart the IDE, unplug/replug USB cables. Eventually I'd get the DUE to upload successfully again. Frustrating!

After a lot of Googling, and methodically shotgunning this problem, I think I've found a combination of things that helps with DUE upload reliability (at least on my Win7-x64 host PC):

  1. Always use the DUE "programming" port for uploads. It will handle the DUE's "erase" button for you, which is more convenient that having to press that yourself frequently.

  2. For your programming USB cable, make sure to plug that into a native USB port on your PC/laptop. Don't go through a hub! Using a hub doesn't make uploading impossible, but reeeealllyy makes it prone to failure. Like I mention below in #3, I think the hub is introducing a timing problem with BOSSAC.

  3. If you are using the DUE's native USB port (for example, to dump out serial diagnostic info like I often do), it's important to UNPLUG this USB cable before an upload.

WHY? My informal observations/guesses:

... When a download is initiated (via the USB-PROGRAMMING port), the native USB port "disconnects", as far as your host PC is concerned. Your diagnostic COM: port suddenly went {poof!}.

... It seems to me that the "USB device disconnect" process on the host Windows-PC is interfering with the timing on the USB-PROGRAMMING port and the BOSSAC uploader software. I'm not sure if it's just the "USB-disconnect" handling by Windows, or the playing of the Windows sound which notifies you that "hey! a usb device was just unplugged" (or both).

  1. IF point #(3) applies to you, and you are using a terminal program (I use RealTerm), it's also important to close the terminal program and then reopen it after your DUE has uploaded and restarted.

WHY? Because when the terminal program is open and a USB-based COM: port suddenly disappears... either Windows (or the terminal program) gets confused and then refuses to work with that port again, until you close/reopen your program. Annoying, but necessary.

Now that I'm adhering to the advice above, my upload success rate has greatly improved, maybe even 100% reliable. I'm still testing...

Anyone with similar experiences?

#2

AFAICT the programming port is much more easier to use for uploading a new software, although much slower too.

Unless you really need a super fast serial link for Serial writes (up to 849 Kbps with native USB), the programming port is the good choice.

I guess some DUE users could explain the issue better than me, but the USB OTG HS is clocked at 480 MHz, hence as soon as there is the least electrical issue with the USB cable/sockets, UOTGHS will try to find another COM port.

A "deep" diagnostic of the native USB issues would certainly require an extensive knowledge of USB 2.0 OTG HS protocol and/or writting a new version of SerialUSB.

#3

Time-to-time, I face similar problems while uploading sketches in my NANO/UNO/MEGA/DUE. I don't do unplug/plug-back UBS cable. What I do is the refreshing of the Virtual Serial Communication Port Driver.

Start ----> Device Manager ----> Ports ----> Arduino Due Programming Port ----->

------> Update Driver Software... ------->

#4

Good to know, thank you.

Judging by the wide range of issues I've been reading about the past few days about DUE-uploading in general... whenever Windows is involved, there could easily be a dozen reasons (simultaneously?) why it's not working. I just happen to come across a "solution" for my setup (for now). Hopefully nothing else will crop up.

I don't mind the time it takes for a successful upload... but I'm annoyed that the "upload" button causes a nearly complete re-compile every time. I also tried using BOSSAC independently outside of the IDE, never got that to work at all, unfortunately.

#5

uptoolate:
I don't mind the time it takes for a successful upload... but I'm annoyed that the "upload" button causes a nearly complete re-compile every time.

If you don't mind the time it takes to successfully upload your code, the programming port is just OK.

If you don't want to re-compile each time you upload, you can upload a previous .bin, see this thread:

Note that you can export directly a binary from your IDE window to your sketch folder: Menu > Sketches > Export binaries.

#6

I have generally found that #3 isn't required if you do #4, usually just closing the port within whatever serial software you're using will do. The biggest problem is remembering to do it :slight_smile:
What's happening is that a reset changes the USB VID/PID to the default until the software changes it again, so the PC has to re-enumerate the board. During this time, the COM port is lost, if you have a COM port program on the PC with the port still open, the PC can't enumerate the COM port back to the same one as it's effectively still in use even though it doesn't exist.

#1 is a problem for me as I've had some boards made without the programming port :frowning:

With regards to hubs (#2), I have been using a powered USB 3 hub without issue, unpowered hubs do seem to create reliability issues.

Most of my issues have been driver and USB cable related, though I have seen issues using the native port for programming when the code also uses it for PC monitoring purposes (reset button on the Due required).

#7

ard_newbie:
If you don't want to re-compile each time you upload, you can upload a previous .bin, see this thread:
How can I upload a .bin to arduino due? - Arduino Due - Arduino Forum

Thanks... I'll give that a try again.

I had previously tried to somewhat "duplicate" the command line that the IDE uses, but that always gave me an error.

#8

weird_dave:
I have generally found that #3 isn't required if you do #4, usually just closing...

#1 is a problem for me as I've had some boards made without the programming port :frowning:

With regards to hubs (#2), I have been using a powered USB 3 hub...

Thanks for all that. I didn't have any of the 3.0 hubs to tinker with. However, I will keep all this in mind should more wonky things start happening again (Win-d'ohhhs!).

I was suggesting that the USB-device enumeration process for the DUE's native-USB port was perhaps creating a timing issue with BOSSAC. Again - I didn't dive deep into this - just a casual observation. The important part (for me) is that whatever silly, supersticious wand-waving I did, I can now upload!

#9