Description
Bug Report
Current behavior
In cmd:
C:\Users\DataGhost\Documents\ArduinoData>arduino-cli.exe upload -p COM8 -i myfile.ino.hex -b arduinoDG:avr:leonardo:usbcon=enabled --log-level debug --verbose
I don't see any debugging or verbose output, but I do hear the USB disconnection sound, so the reset is issued. Immediately after, COM9 appears in device manager, however the port is not "found" by arduino-cli. After the bootloader times out, COM8 appears again and avrdude attempts to flash it on that port, which does not work, obviously.
If I try it again but then manually reset the board after the reset by arduino-cli (while it's in the bootloader), the port disappears and reappears, arduino-cli picks it up (not always!) and flashes it like it should. In the Arduino IDE, flashing works fine, it resets the board and correctly picks up the bootloader every time.
Expected behavior
Debugging and/or verbose output (e.g. "Waiting for upload port..." that I see in the source code), and arduino-cli detecting that COM9 is where the bootloader is listening and subsequently flashing it.
Environment
- CLI version: arduino-cli Version: 0.10.0 Commit: ec5c3ed
- IDE version: Arduino 1.8.12 (Windows Store 1.8.3.0)
- OS and platform: Windows 10 1909 x64
Additional context
After issuing reset, there is a sleep of 500 milliseconds (commands/upload/upload.go:191 in current git). I'm pretty sure this is where the race bug is, my computer is probably "too fast". By the time execution gets to waitForNewSerialPort(), the bootloader port already appeared before the first enumeration, so that function never sees any difference. I think passing ports from line 170 as an argument to waitForNewSerialPort() will fix the problem. As far as I've observed (only with Leonardo boards on this Windows 10 machine) the device port and bootloader port are always different so the new port is never in ports before the reset.
My -b arduinoDG:... is a straight fork off arduino with minor changes in .h files and build options, and with these settings it is effectively identical to the original. When I use -b arduino:avr:leonardo, it complains that incorrect FQBN: platform arduino:avr is not installed, probably because it can't access it (and doesn't know about it) in the WindowsApps directory.
I'm not sure why there's no output other than from avrdude, I see lots of messages in the code that should have been output with --verbose. Should I file a separate bug report for that, or did I just miss something silly? I glanced over it and don't see anything in the code that would cause this.