Therefore my current descriptor structure looks like this. This can be done under the Microsoft Descriptor Specification 1, but I updated the whole device to support the version 2.0 with the help of this excellent guide by google. Windows requires the device to add a DeviceGUID registry entry with the help of another Microsoft specific descriptor.
In order for windows to load the WINUSB driver, just the MicrosoftComaptibleID descriptor is not sufficient.
I found the solution after reading between the lines of Microsoft Descriptor documentation. Have I made any mistake in the ComaptibleID descriptor configuration, or are there any additional steps to take in order to make sure the correct driver is loaded? When I checked with Zadig, it's clear windows had loaded the libusb driver, instead of the winusb I requested.ĭespite this issue, the CDC-ACM function works as intended with a functioning virtual serial port appearing in the device manager. However, the host side software that uses the WINUSB API calls fails to detect the device. The device manager confirms this as shown in the following screenshot. When the device is connected, I observed windows requesting for the 0圎E string descriptor followed by a request for the CompatibleID descriptor. dwLength = sizeof(USB_MicrosoftCompatibleDescriptor) + (2 * sizeof(USB_MicrosoftCompatibleDescriptor_Interface)), USB_MicrosoftCompatibleDescriptor msft_compID = This configuration works right out of the box on non-windows platforms, with both drivers correctly assigned.ĭue to WCID (Windows Compatible ID) requirements, I have setup the following descriptor indicating that windows should load WINUSB for the DFU Interface.
The device descriptor indicates the device uses IAD (Interface Association Descriptor) and the configuration descriptor reflects that, containing all the descriptors for the CDC function as well as the DFU Function.
I'm developing a USB Device containing a couple of USB Functions (CDC-ACM and DFU as of now), using windows provided drivers.
0 kommentar(er)
