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”?
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).
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.
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.
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
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:
The DeviceArrayIndex actually changes the behavior of the driver.
The idProduct setting instructs the Windows 10 PC to load a different driver - “Palm Treo Modem”.
It seems to be a bug in the driver that this setting is required at all (The driver sets the Product ID to a fixed value of 0x0079, then overwrites it with the mandatory registry setting 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.
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.
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.
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?
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.
bDeviceClass: 0x02 -> This is a Communication Device
bInterfaceClass: 0x02 -> This is Communications (CDC Control) USB Device Interface Class
Thanks for helping me with this, I feel that we are close to a solution!
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.
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
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:
bInterfaceClass: 0x02 -> This is Communications (CDC Control) USB Device Interface Class