help!
My units are coming in with version 0.6.0 now (latest release).
Our programming station for this device works like this.
Plug in the device to a USB of our programming station
Set Baud on that port to 14400
program via dfu-util.
Now when every we plug in a new photon the com port being used increments (com5 next one is com6, then com7, then com8). This makes our batch file stop working… Are we doing something wrong, or was this changed in 0.6.0?
This is on a Windows 7 professional machine
It’s not new for me.
This is what I kept seeing with all my devices from 0.4.x on. I’m rather surprised that you ever got Windows to accept a new device on an already “used” port.
There may be some workarounds, but only on the Windows side. USB devices have no say in that respect and have to accept what Windows dictates.
One way that definetly works is scanning the ports for attached Particles (like CLI does).
Or there might be something on the web about how to force Windows to reuse an already “used” port.
Maybe something like this
http://woshub.com/how-to-clean-up-and-reset-com-ports-in-windows-7/
We are looking at it from the Windows side. However it doesn’t happen with 0.5.2.
Some more details:
When I run the update going from 0.5.2 to 0.6.0 Windows installs a driver each time I do the update. If I update 4 devices it installs the driver 4 times. Am I not installing the driver correctly?
Also I saw on git hub a feature of adding hid mouse and keyboard stuff. Apparently there is a macro to turn on and off this stuff. Could this be affecting it?
I clean up COM ports in device manager on a regular basis. Even Windows 10 has a tendency to go to town on assigning COM ports all over the place, even for the same devices.
USB HID support is an opt in feature - if you don't use it, it won't be compiled into your app.
The thing is - and always was on my Win 7, 8.1 & 10 machines -, that each and every device (Particle or other) that supports virtual COM over USB I plug in fresh got and gets a new port number. The USB enumeration must contain a unique ID for the device that will allow you to talk to several devices even when plugged in at the same time.
I usually override the auto-assigned port number with a default one for all Particle devices after that and henceforth they'll all share the same number, but parallel plugging multiple of them causes conflicts then.
Thanks for the info on the opt in nature of the USB HID feature. I guess what I don’t understand and the key issue is why did this change from 0.5.2 and 0.6.0? If I plug in devices running 0.5.2 they attach to com11 all day long. As soon as I plug in a 0.6.0 it opens up a new com port.
There was a change around the 0.6.0 release that made the default USB enumeration not try to open both high and low power connections. This fixed something so that HID could enumerate.
Perhaps @BDub or @avtolstoy could comment on this.
As @ScruffR says, there is no way I have ever heard of to force Windows to put a specific device on a specific port.
I can answer why this is probably happening. With 0.6.0 the devices expose their DeviceID as an iSerial USB string in the USB descriptor. If you are plugging different devices I guess Windows decides to assign them different COM port numbers because the serials differ (which sounds sane IMHO).
As for the drivers, I assume you are talking about a dialog popping up that Windows is installing drivers for a newly plugged device, right? That is also probably related to the serials being different and 0.6.0 devices also include a so-called Control Interface which uses WCID to tell Windows to assign WinUSB driver (the same one that dfu-util uses) to this interface automagically, which will also cause Windows to shows this dialog for a new device once.
Thanks for the explanation. the exposed DeviceID now this makes sense. Is there a way to suppress this?
Otherwise I think we will need to use 0.5.2 until we can redo the programming program.
Thanks
Jerome
There is no way to disable this behavior from the device. I’m not sure if something could be done Windows-side.
I suggest you try 0.5.3 though. It has the USB CDC (Serial) driver backported from 0.6.0, but doesn’t expose DeviceId in USB descriptors. It also includes most of the fixes that 0.6.0 has.