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.
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?
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.
Understood.
Here is a tip to workaround the issue, coming from our drivers development team:
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).