Windows COM port number

The official pyboard running MicroPython.
This is the reference design and main target board for MicroPython.
You can buy one at the store.
Target audience: Users with a pyboard.
Post Reply
smhodge42
Posts: 5
Joined: Sat Nov 13, 2021 6:17 pm

Windows COM port number

Post by smhodge42 » Wed Dec 08, 2021 6:35 pm

Is there a way to fix the COM port number? When I get a new board, or after I do an upgrade of the firmware or reset to factory state with the USR and RST buttons, the COM port number is a certain value. However I use a boot.py file of
import machine
import pyb
pyb.usb_mode('VCP')
for my normal use of the board, because I do not want to use it as a storage device, only a serial one. This always seems to change it to another COM port number the first time I use that boot.py file, and this is a never-ending hassle with batch files I use for various purposes.

Can I use the use the "pid" argument to pyb.usb_mode() to fix it to the original factory reset value?
e.g., pyb.usb_mode('VCP", pid=xx)

Or is there another (better?) way to fix this issue? For example, changing it back in Windows Device Manager?

I'm reluctant to try these things as it seems I have a knack for messing up pyboards.

Thanks.

User avatar
dhylands
Posts: 3821
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Windows COM port number

Post by dhylands » Wed Dec 08, 2021 10:09 pm

IIRC windows will change COM port just by plugging the board into a different USB port.

I've written some helper stuff that will find a USB device.

https://github.com/dhylands/dotfiles/bl ... nd_port.py will print out the port for a given VID/PID. I use this from within a script (mostly bash - not sure if there are shells under Windows which can help).

stijn
Posts: 735
Joined: Thu Apr 24, 2014 9:13 am

Re: Windows COM port number

Post by stijn » Thu Dec 09, 2021 7:13 am

Don't know which driver pyboard uses but some allow setting the port number (via Device Manager), have you tried that (right-click the port, look for 'COM port number' under Advanced in the Port Settings tab)? In any case the device-port mapping is stored in the registry somewhere and can be changed there as well. Don't know by hert, searching for COM port number should do the trick.

Arguably it's not normal that new or a reset firmware changes port number. In fact that's more like a bug somewhere. Windows keeps the same port as long as it sees the same device in the same port. Or if plugged into another port is assigns a new number, but that is also remembered. 'Same device' is the combination of VID/PID/serial number (if any). Can be checked with devcon.exe As such setting the pid could work, at least of one board it should, but still I wonder how firmware or even a simpe reset could change this.

smhodge42
Posts: 5
Joined: Sat Nov 13, 2021 6:17 pm

Re: Windows COM port number

Post by smhodge42 » Thu Dec 09, 2021 7:11 pm

I tried adding <pid> to the boot.py file, "pyb.usb_mode('VCP', pid =nn)", where nn was the original "from factory/after reset" number. That did not work. Windows promptly just assigned yet another new COM port number.

However, by using Windows Device Manager I was able to get things working with the (new) the COM port number that appears when
<pyb.usb_mode('VCP') is used. First i uninstalled the driver for the original "from factory/after reset" number, and then I changed the COM port number of the (new) COM port back to that of the original. After re-booting the computer that worked.

It still seems like a firmware upgrade or reset should not change the COM port number.

At any rate, issue solved, albeit with several hoops to jump through.

stijn
Posts: 735
Joined: Thu Apr 24, 2014 9:13 am

Re: Windows COM port number

Post by stijn » Fri Dec 10, 2021 10:36 am

smhodge42 wrote:
Thu Dec 09, 2021 7:11 pm
I tried adding <pid> to the boot.py file, "pyb.usb_mode('VCP', pid =nn)", where nn was the original "from factory/after reset" number. That did not work. Windows promptly just assigned yet another new COM port number.
Yes that's expected the first time. Point is that afterwards it should not change anymore (at least if setting the pid has the desired effect, which it might not).

Post Reply