Forcing Win7 to use a particular com port - Page 1
Forum section: electronics / general

author: Jester
author_rank: Frequent Contributor
timestamp: July 15, 2019, 01:02:29 pm
content: I have a ST programmer setup to automatically program FLASH as part of a production test on an embedded PC running Win7. This works fine most of the time, however from time to time after the PC has been re-booted Windows decides to use a different com port for the programmer.I'm familiar with the right click and re-assign method using device manager, however after a re-boot any port could be assigned again by Windows.Is there a way to force Windows to consistently use the same com port?

author: Ampera
author_rank: Super Contributor
timestamp: July 15, 2019, 01:32:28 pm
content: as in logical COM1 is always the same port?simple, use real COM ports, not USB ones, and ensure they aren't configured by plug and play.besides that, it's quite possible the PnP manager will just throw resources at whatever controller it feels like at near random.

author: Jester
author_rank: Frequent Contributor
timestamp: July 15, 2019, 01:39:48 pm
content: Quote from: Ampera on July 15, 2019, 01:32:28 pmI don't follow, can you translate in practical terms (I'm a hardware guy not a programmer). The ST programmer only has a USB interface.

author: Jeroen3
author_rank: Super Contributor
timestamp: July 15, 2019, 01:40:22 pm
content: Windows only gets confused about com port assignments when you have run out of all 255 of them.Or your devices have a serial number conflict. Eg: counterfeit FTDI or USB CDC example firmwares.Try Ghostbuster Portable to remove unused drivers assigned to COM ports.

author: Ampera
author_rank: Super Contributor
timestamp: July 15, 2019, 03:11:57 pm
content: Real serial ports have access to specific standardized resources on PC compatibles. They are usually set by BIOS, but only real serial ports can use these resources.USB serial ports, like what might be in your programmer, have to be provisioned with resources dedicated for USB devices, and then patched into the operating system's HAL as an abstracted serial port (which windows will identify as COM1, COM2, etc.) This means if you have multiple USB COM ports, which port gets which COM identification can change between boots, in whatever order the HAL decides to assign those values. "Real" serial ports always have the same resources, and the HAL will always assign the same COM designation based off what resources it's configured to use.If your programmer runs off RS232 straight, find a computer (it's likely your computer already has one, many modern and semi-modern machines still do) that has a serial port on the machine, and use that to connect your programmer. Otherwise you'll have to dive into whatever nonsense Windows operates under in terms of COM port assignments in order to ensure that the same device always gets the same logical COM port assigned to it. If this is the case, the best thing to do is to unplug/disable all other serial (not USB) devices that are given a COM port identifier, so that only one ever exists on the machine (this is what your software will end up using).I'd find it hard to believe that this is an issue, though, as surely your programming software allows you to change what COM port it uses, so when you reboot you can just manually tell it what port to use, no matter what it's switched to.

author: Bud
author_rank: Super Contributor
timestamp: July 15, 2019, 03:59:29 pm
content: It is an issue in that it is annoying to check every time in Device Manager which COM port it assigned to the hardware, before you can specify the corresponding setting in the software.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 16, 2019, 06:31:11 pm
content: Well, I've found that Win7 tends to assign the same COM port number to a given USB peripheral if it's the same device AND you always connect it to the same USB port. This is my limited experience though - I don't use a ton of USB virtual serial devices. Maybe using a lot of different such devices on a regular basis could end up triggering such behavior.Virtual serial devices are a complete anachronism these days anyway IMO. Good luck.

author: nali
author_rank: Frequent Contributor
timestamp: July 16, 2019, 07:05:43 pm
content: You could try the registry settingIgnoreHWSerNumif there is something screwy with the H/W serial numbers being reported. I've only used it with FTDI but apparently it works with other devices, although it doesn't seem to work with USB3.Seehttps://www.ftdichip.com/Support/Knowledgebase/index.html?ignorehardwareserialnumber.htmfor details

author: Monkeh
author_rank: Super Contributor
timestamp: July 16, 2019, 07:21:14 pm
content: Quote from: Bud on July 15, 2019, 03:59:29 pmhttps://helmpcb.com/software/serial-port-monitor

author: Jeroen3
author_rank: Super Contributor
timestamp: July 17, 2019, 06:17:03 am
content: Just check withhttps://www.nirsoft.net/utils/usb_devices_view.htmlwhat happens. Maybe the port/hub location changes on reboot, indicated cheap hub chips used instead of direct root hub connection.

author: NorthGuy
author_rank: Super Contributor
timestamp: July 22, 2019, 08:51:54 pm
content: Your software can read port mapping from HKLM\HARDWARE\DEVICEMAP\SERIALCOMM and find the com port number currently assigned to your device.