USB Driver Installer v3822

[tobias]

After installing on Windows 7 64bit, a window pops up saying the program may not have installed correctly.

I’m used to just click that it was installed correctly, but I don’t see why it’s necessary to do at all.

PS.
Nice to see that the COM100(+) issue has been fixed.

[daav]

After installing on Windows 7 64bit, a window pops up saying the program may not have installed correctly.
I’m used to just click that it was installed correctly, but I don’t see why it’s necessary to do at all.

Please just ignore this message. We’ve planned tasks to improve user experience on Windows 7.

Nice to see that the COM100(+) issue has been fixed.

We didn’t noticed the issue before you told us, and it was trivial to fix. Nice to see that the fix works

[tobias]

New issue found with the drivers in at least version 3.8.2.2 (haven’t yet been able to test the same case with 3.8.4.0).

A customer of ours started to have problems with the USB driver when the COM port number reaches 256 (possibly 257) or above.

To help the customer, the PhiMdmCleaner was run to delete all older entries and the drivers were reinstalled so that v3.8.4.0 is installed now.

Has the newer drivers been tested for cases with COM port number 256+?
Any idea if new problems would appear at an even higher COM port number? I’m uncertain what limit Windows itself has in this regard.

[daav]

A customer of ours started to have problems with the USB driver when the COM port number reaches 256 (possibly 257) or above.

I’m forwarding the issue to the driver team. Will keep you updated.

[daav]

It sounds like Windows itself is limited to COM256 max port identifier.
Please can you elaborate on the used Windows version?
What kind of procedure was made to reach such an high COM port identifier?

[tobias]

Used windows version was Windows 7 I believe.

The product itself is a portable alarm unit that is using Q26/SL6087.

The customer has to configure each unit before sending to end user, and configuration can only take place over USB in this case.

For each new module that is connected, a new virtual COM port is created.

It would be quite a lot easier if a new virtual COM port is only created if the module is connected to a new USB port instead of insisting to create a new one for each unique module.

[daav]

Understood.
Here is a tip to workaround the issue, coming from our drivers development team:

The solution to this problem is that the user has to clear the ports that are allocated for devices.

To clear the ports, there is an entry in the registry that holds the information about the ports that are in use. The registry is at:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\COM Name Arbiter\ComDB

The value at ComDB is a 32 bytes long with each bit representing a port (a value of 1 means that the port is reserved and a value of 0 means the port is not reserved and free). (32*8 = 256 ports)

The customer can set a value of 0 for the bits for the com port that are not used. If all the values are set to 0 and then the PC is restarted then all the ports will be available (the internal com ports would again be reenumerated by the PC).

Hence, the solution to this problem can be to set the bit value of 0 for all the ports that are to be freed (in comdb).

I guess this will be useful to address your customer’s issue.
At the same time, we’ve planned an evolution to enhance the USB driver configuration tool, in order to be able to “preconfigure” the COM identifier that will be used when a device is plugged (even if different devices are used).

[gregorbader]

At the same time, we’ve planned an evolution to enhance the USB driver configuration tool, in order to be able to “preconfigure” the COM identifier that will be used when a device is plugged (even if different devices are used).

Any progress on this?