I am using the virtual COM port feature and it does work very well. On the PC I access the port using \.\wceusbsh001.
Most other virtual COM port drivers create a virtual port on the PC called something like “COM6”. This is much more intuitive for end users and allows them to use any terminal program that they choose.
Is it possible to configure the T20 so that the virtual COM port shows up on the PC as an eumerated port like “COM6”?
Hi @raja.tx,
It’s really quite important to me as I am bidding to replace an existing product with a new version based on a Toradex module. The existing product uses an STM32 microcontroller which exposes a virtual serial port as a conventional COM port, and the customers are used to using it this way. If I can’t reproduce that behavior then I think I’ll most likely lose this business.
Another way to ask the same question is: can the USB port be set-up as a CDC device? (i.e. the standard USB serial communications class driver).
Mike
Dear @MikeS,
There is no possibility to change the COM port name(wceusbsh001).
The USB-CDC client class driver support is available, please refer here for more information: https://social.msdn.microsoft.com/Forums/en-US/c89f9222-c925-4072-9b11-5ca2f2a8b0dd/usb-host-cdc-in-wec7?forum=winembplatdev. Functional device has to be attached with WinCE system to use that.
We would like to suggest you another solution, you would try FTDI UART to USB converter, please refer here for more information : https://developer.toradex.com/knowledge-base/usb2serial.
You need to use one of the serial port on WinCE side and PC side USB-CDC class driver wil be loaded(usbser.dll) that you can use as a COM port.
Please let us know if you have any other question.
Hi @raja.tx,
I think I might have caused confusion about USB host drivers versus USB client drivers. The link you sent was about enabling a USB CDC host driver on the WinCE device to allow USB CDC devices to be connected to the WinCE device.
But I want to do the opposite thing. I want the WinCE device to appear as a USB CDC device when connected to a PC acting as the USB host. I want the PC to load the usbser.sys driver for desktop Windows when the USB cable is connected to my WinCE device.
I found a blog post which describes exactly what I want to do:
I’ll try to follow that post and see how far I get.
Mike
Dear @Mike,
That you would work and serve your purpose. Just update below registry and Save registry and then Reboot. The other required registry and drivers already included in the image.
[HKEY_LOCAL_MACHINE\Drivers\USB\FunctionDrivers]
"DefaultClientDriver"="USBSER_Class"
Please let us know if it works for you and also write a short description of how you are using it. It would help other community users.
Hi @raja.tx,
This actually worked. Changing the registry on the T20 was the easy part, the hard part was creating a .inf file for Windows to tell it which driver to load. I found this article from Microsoft which contained some clues but was not very specific:
How to use or to reference the Usbser.sys driver from universal serial bus (USB) modem .inf files
Then I found an example .inf file from someone else which worked with my T20:
After that I edited the VID, PID and descriptor strings in the T20 registry and in the above .ini file to match my company.
My understanding is that WIndows 10 does not need a .ini file for a CDC class device, it just automatically loads the right driver. But previous versions of Windows do need a .ini file for this. I am using WIndows 7 right now, and I’ll test this on Windows 10 soon.
Mike
Dear @MikeS,
Thanks for knowing your progress. Is the functional driver working with both Windows 7 and Windows 10? Do you face any problem with that? Please let us know.
Hi @raja.tx,
So this does not work on Windows 10, but it does work on Windows 7. I think the problem may be that Windows 10 expects a CDC device to have a class of 2 and a subclass of 2, but the Toradex CDC device has a class of 2 and a subclass of 0xFF.
This situation reminds me a discussion we had in 2016 about getting the RNDIS driver to work on Windows 10. In that case we also had to change the class and subclass of the USB driver to make it work in Windows 10. That change can’t be made in the registry, Toradex had to create a new driver. See the discussion here:
RNDIS on Windows 10 to connect to CE7 running on T20
Mike
Hi @raja.tx, any news?
Dear @MikeS
I modified the driver to test changing the Interface Class / Subclass to 0x02 / 0x02, and it didn’t work. This was expected, as the subclass defines the CDC control model (0x02 = Abstract Control Model, 0xff = vendor specific control model).
However, I found another setting which could work:
[HKLM\Drivers\USB\FunctionDrivers\Serial_Class]
DeviceArrayIndex = 0x0001
idProduct = 0x0079
DeviceArrayIndex actually changes the behavior of the driver.idProduct setting instructs the Windows 10 PC to load a different driver - “Palm Treo Modem”.idProduct). So maybe there’s a better way to configure the combination Colibri / PC.Anyway, WinCe still attaches WMDC to this interface. So if you open a terminal program on the PC, you will see some messages CLIENTCLIENTCLIENT or similar. Please refer to the following article how to disable ActiveSync:
Actually we never used the serial connection like this before. Therefore I would appreciate your feedback whether this is a good solution or if there are any important things I missed in my description.
Regards, Andy
Hi @andy.tx,
Thanks for your answer, but I think your answer is for a different question than the one I asked.
I already have [HKLM\Drivers\USB\FunctionDrivers\Serial_Class] working for both Windows 7 and Windows 10 with my own VID and PID. What I do is disable ActiveSync on the Colibri and then I wrote an inf file for Windows to recognize my VID and PID. I then use the low-level WinUSB driver in Windows to open a USB end-point on the PC which is connected to COM0 on the Colibri module. This works well, but using WinUSB is really only practical in my code and it’s not something that most of my end-customers want to deal with in their own code. I have created a DLL for my customers which hides the complexity of WinUSB from them and provides a simple API. There is a page elsewhere on the Toradex site that talks about how to do this:
The topic I was discussing with @raja.tx in this thread is about [HKLM\Drivers\USB\FunctionDrivers\USBSER_Class], which is different from the [HKLM\Drivers\USB\FunctionDrivers\Serial_Class]. The function driver in [HKLM\Drivers\USB\FunctionDrivers\USBSER_Class] causes Windows to load the usbser.sys driver, which creates a virtual COM port which can then be opened by any terminal client on the PC by opening a port with a name like “COM40”. This is way more convenient for end users than grappling with WinUSB. I have this working very well already on Windows 7, but it doesn’t work on Windows 10.
Here’s a web post on the Microchip forum which describes the same problem that I have run into with Windows 10. This post also suggests that for Windows 10 this feature needs to use class 2 and subclass 2.
Mike
Dear @MikeS,
I built the driver with class is 2 and subclass is 2, please download it from here, please overwrite it in the \Windows directory or put it in \FlashDisk\System directory and adjust registry path to locate the driver.
[HKEY_LOCAL_MACHINE\Drivers\USB\FunctionDrivers]
“DefaultClientDriver”=“\FlashDisk\System\USBSER_Class”
Please let us know your test result.
Thank you.
Hi @raja.tx,
Thanks for getting back to me and sorry for the delay in my response. When I use the new driver that you built I still see that the class is 2 and the subclass is 0xFF, could you double-check that file?
To test it, I followed the same process which I am already using for the modified RNDIS function driver which Toradex sent to me a couple of years ago. I renamed the new file to serialusbfn2.dll and I put it in the \FlashDisk\System folder.
Then I changed these registry keys:
HKLM\Drivers\USB\FunctionDrivers\USBSER_Class\Dll from “serialusbfn.dll” to “serialusbfn2.dll”
HKLM\Drivers\USB\FunctionDrivers\DefaultClientDrive to “USBSER_Class”
HKLM\Comm\USBFNSER\ImageName from “serialusbfn.dll” to “serialusbfn2.dll”
But the USB Subclass is still 0xFF.
I thought that maybe I was not correctly pointing WinCE to the new file, so I tried leaving the registry set to “serialusbfn2.dll” and I deleted the file \FlashDisk\System\serialusbfn2.dll. When I did that the PC reported that I had an “unkown USB device”. That makes me think that the Colibri module actually is using the new DLL that you sent to me when I put it in the \FlashDisk\System folder, but the new DLL still uses a Subclass of 0xFF.
Am I doing something wrong with the registry settings?
Mike
Dear @MikeS,
I am able to see the changes, please refer my attached USB descriptor details here : USB Descriptor, Could you run UVCView on your PC and catch the similar USB descriptor details and share with us?
Hi @raja.tx,
Those files which you sent are very useful. I see the same USB descriptors on my PC that are in the text file that you sent. I can see that you did change the subclass from 0xFF to 0x02 in the USB device descriptor, but the subclass is still 0xFF in the interface descriptor (See below). I’m not sure about the difference between the device and interface descriptor, but I think Windows may look at the interface descriptor first because this device shows as subclass 0xFF in the Windows Device Manager.
Could you look at the DLL source code and see if there a place to change the interface descriptor subclass as well as the device descriptor subclass? Then we can try it again on Windows 10.
===>Device Descriptor<===
bDeviceClass: 0x02 -> This is a Communication Device
bDeviceSubClass: 0x02
===>Interface Descriptor<===
bInterfaceClass: 0x02 -> This is Communications (CDC Control) USB Device Interface Class
bInterfaceSubClass: 0xFF
Thanks for helping me with this, I feel that we are close to a solution!
Mike
Dear @MikeS,
I modified the driver as you requested, could you try this driver and let us know the feedback. Meanwhile, I will try to read this topic to understand better.
Thank you.
Hi @raja.tx,
That version works on both Windows 7 and Windows 10! On Windows 10 it works without me having to provide a .inf file, it’s truly plug-n-play. On Windows 7 I do still need to supply a .inf file to make it work, but that was expected.
I realized that with both the original version of the driver and the intermediate one you sent with with a device descriptor subclass of 2 actually can be made to work with Windows 10 by careful use of a .inf file. But Windows 10 is more fussy than Windows 7 about .inf files so the plug-n-play solution using subclass 2 in both the device and interface descriptors is very attractive.
I think that I have everything that I need now as I can deploy the modified driver that you sent me. You might want to consider including that driver in a future version of the WinCE image so that everyone else can benefit from it more easily. The change seems to have no impact on Windows 7, but it makes using it with Windows 10 much easier.
Thanks for all your help with this,
Mike
Dear @MikeS,
Thank you for your testing and letting us know the update.
It seems bInterfaceClass and bInterfaceSubClass is important for class specification but bDeviceClass and bDeviceSubClass is not really important. So I made undo the bDeviceClass and bDeviceSubClass changes and only bInterfaceSubClass is set 2 and the driver is built and uploaded
Could you test with this driver and let us know the feedback then we would like to integrate this chance to our standard release image.
Hi @raja.tx,
The latest file you sent also works on Windows 7 and Windows 10. It appears to be functionally identical to the previous file which you sent. It shows up as class 2 and subclass 2 in the device manager of both Windows 7 and Windows 10.
I see this in the USB device viewer that you sent to me:
===>Device Descriptor<===
bDeviceClass: 0x20
bDeviceSubClass: 0x00
===>Interface Descriptor<===
bInterfaceClass: 0x02 -> This is Communications (CDC Control) USB Device Interface Class
bInterfaceSubClass: 0x02
Mike