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?
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?
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!
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.
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:
===>Device Descriptor<===
bDeviceClass: 0x20
bDeviceSubClass: 0x00
===>Interface Descriptor<===
bInterfaceClass: 0x02 -> This is Communications (CDC Control) USB Device Interface Class
bInterfaceSubClass: 0x02
Dear @Matte
It’s expected to work.
Please take a few minutes to test it, and everybody in the community would appreciate if you share your result here.
Thank you and best regards
Andy
Did you connect VF61 and PXA to the Windows 10 PC and wrote the serial port application to use that?
May I know your Windows 10 update version?
This special bInterfaceSubClass to 0x2 not required for Windows 10, 2019 march update onwards. Could you test update your Windows 10 till 2019, March and do the test again.
Still, if you need this fix, May I know which is your target platform, Is it VF61, WinCE6 or PXA, WinCE5. We may need to build SerialUSBFn.dll with the bInterfaceSubClass change.
I’m sorry of late answer, but the last two weeks I was outside, and I didn’t try your suggestions before to today.
I had update Window to 1903, and I tried with WinCe6 VF61,
but the connection is not worked.
I am looking into Windows 10 update and without special driver to fix the issue.
Meanwhile, I built special serialusbfn.dll with bInterfaceSubClass is 0x2 fix that I would like to share with you for testing : serialusbfn_ce6. Could you test this driver with Vybrid, CE6 and let us know the result.
You need to follow below steps
copy the SerialUSBFn.dll in \FlashDisk\System\SerialUSBFn.dll
change the Serial_Class registers:
- Dll : \FlashDisk\System\SerialUSBFn.dll
Quickly I tested with last serialusbfn_ce6 driver, it is working for me with Windows 10. I used termterm Windows 10 application and terminal CE WinCE application.
I used this inf file on Windows 7 to set the driver.
Please let me know similar setup is working for you?
I would like to request you below test and let us know the feedback.
Try this USBFn only and verify the serial driver is working?
Set CableDetectPin to other than 137 e.g.135, manually give high or low voltage to the pin to verify the Client driver is loading or not. If you set 137 then CableDetectPol always 1, should not set to 0.
SODIMM 137 signal is 3.3v tolerant, please refer below picture Is that D1(137) connected to SD card(CN7) in your schematic?
