Adafruit STM32F405 'Feather' which has an in-ROM bootloader showing up as a 'Universal Serial Bus Device > STM32 BOOTLOADER when properly configured and plugged in to WIN10. Blink OK.
One of the features of this thing is the availability of an aux Lithium-type battery for which code is provided (by Adafruit) to check the voltage level. It is necessary to use the IDE 'Serial Monitor' to do so, but 'Serial Monitor' apparently doesn't understand the 'Universal Serial Bus Device > STM32 BOOTLOADER' and wanted COM1. And I complied. The OS complained, with various bells and clanging noises which included a message that my USB device 'was no longer recognized'.
So I went back to the 'Port' parameter to try to back out of the thing, and un-check COM1, but the IDE won't allow me to un-check COM1. 'Preferences.txt' includes three statements about Serial Ports, but rather than fight it I just re-installed the IDE. Not my hill to die on today (last night)
Does this mean I can't use the Serial Monitor when this thing is communicating via this 'Universal Serial Bus Device > STM32 BOOTLOADER'? I hope not.
Solved. Bringing up the ROM bootloader involves shorting the RESET pin to B0, and the order of reversing this operation seems to be important. Once the device is programmed, seems like first unshort the pins, unplug the USB cable, hit reset, plug the device back in, (COM5 shows up), open the Serial Monitor and choose COM5, hit reset again and voila!
PS. It was also necessary to add: Serial.begin(9600); to the setup phase (!!!). The Adafruit people left that out of the code. The read and calculations are now in the loop() with a five second delay and the Serial Monitor showing the battery voltage at the five second intervals. 4.19 .... 4.19 .... etc .... etc
If this is under WINDOWS then normally COM1 and COM2 are RESERVED for windows own internal use.
Other COM port devices should start at COM 3 to as high as COM255 < upper limit.
A failure to see other COM ports is often a lack of drivers or incorrect drivers.
That can often be fixed by visiting the site from the place of purchase.
Don't have a "feather" so cannot comment on which driver that may be ?
You may want to try a FORUM SEARCH for "feather driver".
Thanks to sterretje and Ballscrewbob for their comments!
Bottom line: When being programmed this thing communicates via the 'Universal Serial Bus Device' > STM32 BOOTLOADER and then when that is completed and plugged back in it is dealt it's own Port and acts 'Normally' (?). That is assuming this all occurs in the correct order. I have no idea how or why the IDE chose to argue with me. Probably something I said last night!