Surfing all the posts about upload problems it is clear that there is a flaw
in the bootloader/Driver/IDE system for the Atmega32u4 based products.
At least on the Windows platform.
I have seen one testimonial that it uploads properly, without intervention, on the MAC.
Unfortunately I missed discussion of these problems when recently choosing the Micro
for a classroom application. I am really interested in it working right!
I chose it over the chinese Nanos to avoid... well... problems uploading.
Now look what I got. Problems uploading.
Manually resetting and timing the reset just right to catch the IDE before the download is not acceptable. Especially for the classroom. It will be very discouraging to students.
The IDE should be able to reliably reset the running sketch from its sketch-time
USB stub and upload the code. Without intervention. Every time.
That is what the Arduino system is; that is what we expect when we use it.
(Further there shouldn't be limitations on sketches to insure this reliably, and there is,
but that I can live with for a while)
I've seen some posts that the USB IDs might be wrong in the configuration files.
This may be. Looks inconclusive at this time. They might be on to something.
Clearly, there is something WRONG.
Will someone from Arduino.cc or Adafruit come forward and discuss this with something more than "try hitting reset when the code has compiled" PLEASE.
What ARE you doing, are you WORKING on it? Do you INTEND to fix it?
If this can't or won't be fixed would it be unreasonable to expect Arduino.cc to
take any Micro back no questions asked... I'm thinking so.
Exactly which windows version(s) are you having problems with? (and which sketches are running at the time?)
My understanding/suspicion is that it's a timing problem. The PC resets the AVR, and it "immediately" runs the bootloader and shows up again. The PC USB system is still busy making beeping noises or something, an gets confused when a new device shows up with info matching the device it thought it was deleting. Or something like that.
Note that the software USB on the Leonardo has to be "working" in order to recognize a reset. It will always be possible to write a sketch that breaks that, making a manual RESET required. On the bright side, the leonardo bootloader runs for more than 1 second after manual reset, so it isn't quite as fiddly to use manual reset as it would be on an Uno-style board.
(If you had Nanos, you'd probably be running into the "counterfeit FTDI" driver problem about now. I'm not sure that anyone beside Gravitech themselves still sells an "authentic" Arduino Nano (and theirs is expensive, even by "authentic" standards.))
Hi and thank you for the kind response.
I may have over reacted last night when I wrote that post.
Here's how I came to that mindset:
A few days ago I uploaded the blink example via a desktop Win7 computer
and everything behaved properly.
Yesterday, using a relatively fresh Win7 desktop and IDE 1.0.6, I started trying
more examples and ran in to various failures in the upload process.
This led me to jump into googling the boards and seeing upload/USB issues all
over the place with respect to the Micro.
Without doing much else I composed the original post under the impression that the problems
are truly systemic.
After posting, I though maybe I should try more experimenting.
I noted I still had the IDE loaded from before.
I exited and restarted the IDE, and commenced to do about 8 to 10 downloads in
a row without a hitch.
So I'm thinking that though there are a lot of postings about upload problems
they may actually be rare occurrences rather than the rule.
So the questions you are asking me are about my specific situation.Thank you
for offering, if I continue to personally experience problems I'll post back.
Your interest in jumping right in to my specific problem suggests that the Micro
does NOT have a systemic problem. I'm not sure. Maybe its a robustness problem.
What I wonder is if Arduinio.cc is continuing work on improving the system
so that these problems cease to be a concern.