i have a stack of shields on top of the DUE and can not get to the erase button. i have not quite figured out the mysterious combination of button presses that reliably allows uploading a new program. previously i would press the erase button and then reset and it worked reliably. since i can not get to the erase button now, i can some times succeed with various combinations of short and long presses of the reset button alone. i have not yet discovered exactly how long to wait and how many times to press etc.
if the program does not load successfully, the error message is that the com port is not found. then i do some random reset button pressing and it usually works the next time.
if the IDE were to check for the com port before compiling the code, this would save a lot of time. the way it is now, i have to wait for the successful compilation each time only to be told the com port is not there. is there some way to attempt to load the program without re-compiling each time? if not, i highly recommend that the IDE be modified to allow this or to check the com port first before compiling a program that can't be loaded.
or, is the best solution to bring out the erase button? unfortunately it does not seem to be on any pins that carry through to the shields so i would have to solder on a new button and let it dangle somewhere. it would certainly be nice if the button were more accessible or brought out on some pins or if erase was done by firmware when loading a program as part of the load sequence.
actually, it shows the last connection. there is no guarantee that the DUE will connect if the right sequence of buttons is not pressed. it is not a problem of not having the right port selected. it is a problem with getting the DUE to be recognized without an impossible or difficult to reproduce sequence of button presses.
this really should not have to be difficult. the teensy is the most friendly in this regard. there is a single button to press that loads the last compiled program. a single button, is all it takes.
i am going to bring the erase button out of the board so i don't have to deal with this but it really is something that could be handled better in both the bootloader firmware and the IDE.
the only explanation i can find about programming the DUE from the Arduino IDE is the following. it clearly says that the 16U2 is supposed to do whatever is needed to insure programming. what exactly is meant by "Opening and closing the Programming port connected at 1200bps" ? where do you set the programming speed, in the serial monitor speed selection or is it always at 1200 bps? what is meant by opening and closing? do you have to de-select the port and re-select it or is there some other secret? unplug and replug?
i don't understand why something so basic is so badly documented.
Programming port: To use this port, select "Arduino Due (Programming Port)" as your board in the Arduino IDE. Connect the Due's programming port (the one closest to the DC power jack) to your computer. The programming port uses the 16U2 as a USB-to-serial chip connected to the first UART of the SAM3X (RX0 and TX0). The 16U2 has two pins connected to the Reset and Erase pins of the SAM3X. Opening and closing the Programming port connected at 1200bps triggers a “hard erase” procedure of the SAM3X chip, activating the Erase and Reset pins on the SAM3X before communicating with the UART. This is the recommended port for programming the Due. It is more reliable than the "soft erase" that occurs on the Native port, and it should work even if the main MCU has crashed.
the only explanation i can find about programming the DUE from the Arduino IDE is the following. it clearly says that the 16U2 is supposed to do whatever is needed to insure programming...
Programming port: To use this port, select "Arduino Due (Programming Port)" as your board in the Arduino IDE. Connect the Due's programming port (the one closest to the DC power jack) to your computer.
This is all the direction that I've ever needed. I suggest that you take a good look at your USB connection, and maybe the DUE pcb itself, to look for hardware issues.
I have had no issues uploading new code.
I have never had to press any button on the DUE to get things going... Matter of fact, I've never used either of the two buttons on the pcb.
I find that it is easier to have the DUE USB plugged in before you start the IDE.
Are you sure that your connecting the USB cable to the programming jack right next to the DC power input?
i am definitely using the programming port. i have determined that i need to press reset to make sure that either the loaded program is running or that memory is erased. then i need to press reset again before loading the program. if i upload a program and the comport not found error occurs, the memory has in fact been erased because the program is no longer there. so there really is communication via the serial port to erase the memory. it seems that two attempts are needed each time, one to erase memory and one to program. if i press the erase button manually, i can then press reset once and succeed at uploading every time.
i have two different boards and both behave the same. they have different stuff connected and different programs. on one, the erase button is accessible so it was no big deal.
i don't mind pressing reset several times and attempting to upload a couple of times. what kills me is having to wait to compile and verify the program only to find it will not upload. IS THERE SOME WAY TO JUST UPLOAD THE LAST COMPILED PROGRAM AND NOT HAVE TO RECOMPILE?
also, what do you mean by have a look at the USB port? what should i be looking for? also what should i be looking for in terms of hardware on the board? i have two boards that behave the same so i doubt it is a mfg error unless it is a problem with a run of boards that all have the same problem. i bought both of them from Digikey in fairly close succession so maybe they are of the same batch.
Years ago, I developed a patch for Teensy to speed up compiling. It was contributed back to Arduino. I'm not sure if it's in 1.5.x, but it should be.
However, it may not work properly when directories with spaces or other special characters are used. The patch is designed to "fail safe", reverting to the old (slow) behavior of compiling every file. Only if several checks all pass does it use the previously compiled .o files. One of those checks involves parsing numerous files written by a previous run of the compiler, listing numerous full pathnames to files. If the pathnames have special characters, the compiler might add extra encoding, which the patch doesn't know how to handle. If the names don't match perfectly, it's designed to revert to the old behavior, which is slow but very safe. Since developing Teensy 3.0, investigating this and other non-critical bugs has fallen to the absolute bottom of my priority list. It'll probably be about a year until I investigate this. If anyone else wants to look at it sooner, the code is in is_alread_compiled() in Compiler.java.
In the meantime, knowing this, you might try placing the Arduino IDE in a directly with no spaces or special characters. A location like C:\Program Files (x86) has both spaces and parenthesis.
If you'd like to help on this issue, without digging into Compiler.java and arcane compiler options, it would be very helpful if someone were to meticulously investigate changing the directory name where Arduino is installed (trying many different non-alphanumeric characters) and check if the speedup does or doesn't work. Documenting what does and doesn't work, and on which platform (Linux, Mac and Windows may be different) would help others sooner, and give me or whoever eventually works on this a good start with solid info.
I can't help with Due's bootloader, but hopefully you can get my speedup patch working for a little relief from waiting for all those files to recompile every time?
i do not use folders with special characters or spaces. i have done enough windows programming to avoid them like the plague. the default folder when the IDE was unzipped did have some .s and -s in it. i removed the .s and changed the -s to _s. nothing but letters and _s now. do you consider _s to be special characters? the optimization is not working. loading the same program right after doing it once and changing nothing, the compile still happens.
so still hoping for something that will help solve this problem. i am going to add an external erase switch.
does anyone who is reporting no problems like this use win 7?
spencoid:
do you consider _s to be special characters?
It's not me... it's the compiler output that my code parses. I honestly don't know exactly what the compiler considers special. All I do know is it worked when I tested on all 3 platforms. But I rarely use Windows, so I probably just put it in c:\arduino for testing. Likewise, on Mac and Linux I'm sure I never tested with spaces in the directory name.
Did I mention the part about not having the time to investigate this..... and hoping someone might go to that trouble and submit a high quality bug report, detailing what does and does not work on various platforms?
If you turn on verbose info, from File > Preferences, when the patch is working you should see messages about using already compiled files. Try compiling an example for Arduino Uno on 1.0.3 to see it work. Or watch this video I made... before it was accepted into Arduino, when the Arduino Team wanted to see more people test it first.
The point is not that I can help you. I've already done everything I can for now. The point is this patch exists and some Windows users find it works, others don't. You might be able to get it working somehow. So far, absolutely nobody on Windows has ever submitted any good info about what does and does not work (this isn't the first time I've asked....)