I've been trying out my new arduino leonardo I just received. I notice that the Tools> port is disabled. And also this device does not show up on my device manager. also , no windows bell sound. I'm running a windows 10 system.
In contrast, my Arduino Uno R3 works correctly at the same time.
Also, even though my Leonardo R3 isn't detected by the IDE, it does automatically blink led 13 on off, as if the blink test is preloaded. I hit reset and it a slow fadein / fade out led 13 blink for a bit and doesn't solve the issue.
Make sure the USB cable is completely plugged into both the Arduino board and the PC.
You may have a damaged/defective or charge-only USB cable. Try a different cable.
Either of the above can result in the power connections being made (and thus LED lights on the board), but no data connections (and thus no port for the board).
Unfortunately, double reset doesn't do anything different from a single reset on the Leonardo. They both cause the bootloader to run (indicated by pulsing "L" LED), and then time out after a few seconds.
The Sparkfun Pro Micro bootloader does have special treatment of the double reset (persistent bootloader state) and I believe that is the origin of the common misconception that it does something special on the Leonardo and Micro. Even then, a lot of people use the Chinese clone Pro Micros and those come with the Leonardo bootloader, so still don't have double reset capability.
But the standard bootloader's timeout duration is long enough that you can catch the bootloader port with the right timing.
It is not about the microcontroller. The microcontroller doesn't know anything about a double reset. It is about the bootloader. That is where the double reset recognition exists or doesn't exist.
You shouldn't have to do a double tap on the Leonardo or Chinese Pro Micro. The single tap runs the bootloader for a few seconds.
However, you do need to do it on the boards that use Sparkfun's bootloader because with that bootloader the single tap only resets the board, while the double tap is required to activate the bootloader.
We ship the Pro Micro with a modified version of the Arduino Leonardo bootloader, with one major enhancement. When a Leonardo (or any device using the "stock" bootloader) is externally reset, it goes back into the bootloader...and waits there eight seconds before it starts running the sketch. For some embedded projects, waiting eight seconds before a program runs isn't acceptable, so we modified the bootloader run time.
When a Pro Micro is externally reset (by pulling the RST pin low), it'll only briefly (<750ms) start the bootloader before continuing on to the sketch. If you need the bootloader to run longer, resetting twice quickly will get the Pro Micro to enter bootloader mode for eight seconds.
Hey, I know you are "grumpy", but I think it is very immature to get rude with me when I am only trying to share my knowledge in a completely polite and mature manner.
Maybe I'm wrong, maybe you are wrong. Either way, if we can have a civil discussion we can come out of this richer in knowledge than we were before.
I have to do this because the board disappears from the list of ports. Just like the OPs board.
You are entitled to think this, just as I am entitled to think here is someone saying something different from my experience who is refusing to acknowledge that I have had the same problem as the OP.
Anyone who has worked with the ATmega32U4 boards for any length of time has broken the USB CDC serial port.
Here's a minimal demo sketch:
int main() {
return 0;
}
When this happens, it is no longer possible to upload normally to the board because the bootloader is triggered by the Arduino development software opening the serial port at 1200 baud:
The easiest recovery technique is to activate the bootloader manually during the upload. On the boards with Arduino's bootloader, you can do that by pressing the reset button once. You can press it twice if you like, but it is not necessary. On the boards with SparkFun's bootloader, you must press the reset button twice.
You do need to get the timing of that right because there is a timeout when the bootloader exits to the application if no upload has started. The timeout is long enough on this bootloader that you might be able to get away with activating it just before starting the upload process, but, since the sketch is compiled before the upload starts, this is dependent on how long the compilation takes. Alternatively, you can watch the upload output and do the reset just as the IDE starts watching for a new port:
On my Leonardo, a double click is required to get the bootloader to run. The
behavior of the Leonardo bootloader may have changed over time. These tests
were done using a genuine (as much as I can tell) Arduino Leonardo with the
factory bootloader. I have no idea how old it is. It says on the back "Board
Model Leonardo R3".
Here is what shows up on a Linux system 'dmesg -HP' after single clicking
the Leonardo reset button. The bootloader does not run.
[Dec31 11:50] usb 1-3.1.4: USB disconnect, device number 11
[ +1.003561] usb 1-3.1.4: new full-speed USB device number 12 using xhci_hcd
[ +0.343618] usb 1-3.1.4: New USB device found, idVendor=2341, idProduct=8036
[ +0.000002] usb 1-3.1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0.000002] usb 1-3.1.4: Product: Arduino Leonardo
[ +0.000001] usb 1-3.1.4: Manufacturer: Arduino LLC
[ +0.000001] usb 1-3.1.4: SerialNumber: MIDI
[ +0.007061] cdc_acm 1-3.1.4:1.0: ttyACM2: USB ACM device
Here is what shows up on a Linux system 'dmesg -HP' after double clicking
the Leonardo reset button.
[Dec31 11:46] usb 1-3.1.4: USB disconnect, device number 8
[ +0.746380] usb 1-3.1.4: new full-speed USB device number 9 using xhci_hcd
[ +0.275759] usb 1-3.1.4: New USB device found, idVendor=2a03, idProduct=0036
[ +0.000002] usb 1-3.1.4: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[ +0.000001] usb 1-3.1.4: Product: Arduino Leonardo
[ +0.000001] usb 1-3.1.4: Manufacturer: Arduino srl
[ +0.006072] cdc_acm 1-3.1.4:1.0: ttyACM2: USB ACM device
[ +7.677169] usb 1-3.1.4: USB disconnect, device number 9
[ +0.232959] usb 1-3.1.4: new full-speed USB device number 10 using xhci_hcd
[ +0.344144] usb 1-3.1.4: New USB device found, idVendor=2341, idProduct=8036
[ +0.000002] usb 1-3.1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0.000002] usb 1-3.1.4: Product: Arduino Leonardo
[ +0.000001] usb 1-3.1.4: Manufacturer: Arduino LLC
[ +0.000001] usb 1-3.1.4: SerialNumber: MIDI
[ +0.007148] cdc_acm 1-3.1.4:1.0: ttyACM2: USB ACM device
The bootloader runs with VID/PID 2a03/0036 then 7.7 seconds later the sketch
runs with VID/PID 2341/8036. I have always used the double click reset method
to recover from bad sketches with Leonardo and clone Pro Micros.
The problem is 7.7 seconds seems like a long time but the IDE 1.8 is pretty
slow. The time between pressing Upload and avrdude running can be more than 7.7
seconds.
What works for me is pressing Upload then counting off 5 seconds then double
click reset. But the number seconds depends on how the IDE takes to compile the
sketch and all its libraries so your milage may vary.
You have plenty time if you reset the board at the moment that the IDE reporst the memory usage.
That's what I see in Windows as well for the Leonardo and it matches boards.txt; however, just like @in0, I have always managed to use the single reset to recover the board, never had to use a double reset to recover the Leonardo.
Have you tried viewing hidden devices? Perhaps there's some hidden USB port conflict, bad installation etc. If so, then with the Leonardo disconnected, you could right-click and select "Uninstall device" on the greyed out Leonardo or problematic port.
Here's how a working setup looks on my PC with Windows 10 and Arduino 1.8.15:
With that bootloader, I get the same dmesg -HP output from a single reset as from a double reset.
The arduino.org folks might have done some tinkering around with the bootloader shipped on the boards they manufactured (and I believe arduino.cc inherited some of their inventory after the legal issues were settled). .org wasn't super strong on documentation and a lot of what they did document has been lost since then (even evading my attempts at archaeology via the archive.org Wayback Machine).
Sorry for late response. Had not checked for this, but I got it working with a new usb cable.
I had 2 older ones, didn't assume this would be the case. as @in0 pointed they were probhably just sending power and not data.
