WinUSB devices, custom USB string descriptors, and debugging USB

Go To Last Post
40 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

I'm trying to create a WinUSB device using a SAM3X microcontroller and the ASF (it's an Arduino Due but I ported it to mBed using ASF since Arduino's software is shit). A WinUSB device has a special USB string descriptor at 0xEE that contains information about the device. According to Microsoft's documentation, when you plug in a USB device Windows (8 and later) automatically queries the 0xEE string, and if present and correct it will automatically load the WinUSB driver. It basically makes custom devices plug-and-play on Windows.

 

Unfortunately, the code I'm using never seems to get to the point where 0xEE is queried. Has anyone ever done anything like this? Or have any experience of debugging it? Is there a way I can manually query USB string descriptors in Windows?

 

Also, there are actually two methods for configuring WinUSB devices - the second uses USB's Binary Object Store (BOS) instead of the 0xEE string because apparently it is more reliable. Unfortunately the documentation for it is much worse so I haven't used that method.

 

Anyway, here is my code. I added an infinite blinking light loop to see if 0xEE is ever queried but the code doesn't get that far. Anyone have any ideas?

 

// In usb_conf.h: Add extra string descriptors to make this a WinUSB device, so the driver is installed automatically!
#include "WinUSB_Device.h"
#define  UDC_GET_EXTRA_STRING msos_extra_string
 
// WinUSB_Device.h
#pragma once
 
#ifdef __cplusplus
extern "C" {
#endif
 
// Allow sending extra string descriptors to make this a WinUSB device. See
// https://msdn.microsoft.com/en-gb/library/windows/hardware/hh450799(v=vs.85).aspx
// This returns the "OS String" which says how to retrieve the descriptor...
bool msos_extra_string();
 
// And this returnst the actual descriptor.
bool msos_vendor_in();
 
#ifdef __cplusplus
}
#endif
 
// And then in WinUSB_Device.cpp:
extern "C" bool msos_extra_string()
{
    for (;;)
    {
        led = !led; // It never gets to here :(
        wait_ms(100);
    }

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I actually found an example where they use the magic 0xEE string, but they seem to do it in the same way as me...

 

https://github.com/cjameshuff/m1...

 

So I'm not sure why my code isn't working.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm working on this also but I'm not using ASF.

 

It looks like Windows only reads the EE string once and puts it into the registry for that VID/PID.  I could be wrong about this.  I haven't gotten it to work yet.

 

It only reads that string under certain circumstances.  I'm using device class 0, which is what Dean uses in LUFA.

 

I downloaded the LUFA thing on this page:  I'm pretty much using his descriptors.

http://sourceforge.net/projects/libwdi/files/misc/

 

I also use info from this page:  In fact I found the LUFA link on this page.

https://github.com/pbatard/libwdi/wiki/WCID-Devices

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks very much, that is a fantastic resource! I wish I had found it before wading my way through Microsofts documentation.

 

I will give xusb a try, and also try changing the vendor/product IDs to see if that works.

 

I'm using device class 0xFF, and subclass 0x00, mainly because that's what a screenshot in Microsoft's documentation showed. But I'll give others a try.

 

Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I thought I should use 0xFF too.  That's still an option I might try.  I'm trying 0x00 now because Dean uses it in LUFA.

 

This stuff is quite confusing, and my old brain is struggling with it. 

 

I guess the VID/PID can be anything.  I picked mine out of the air.  I picked a vendor that shouldn't conflict with Atmel's stuff.  Atmel, and Dean too, may have some VID/PID for our use.  Right now I'm just trying to make something work.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I got it to work! Mostly anyway. Here's what I learnt:

 

1. If using ASF, don't use UDI_VENDOR_SETUP_OUT_RECEIVED to handle the Compat ID and Extended Properties. Use USB_DEVICE_SPECIFIC_REQUEST instead.

2. MSFT100 is unicode (16-bit). I accidentally had it as ASCII.
3. Lots of stuff is cached by Windows, so to aid debugging it helps to change your VID or PID every time.
4. For some reason if I don't use the xusb -w option, the Extended Properties query fails with a pipe error. If I do it succeeds.

 

This is explained in the xusb source:

 

    // WinUSB has a limitation that forces wIndex to the interface number when issuing
    // an Interface Request. To work around that, we can force a Device Request for
    // the Extended Properties, assuming the device answers both equally.

 

Which I assume means that it is using an interface request for the Extended Properties, and wIndex gets set to the interface number (it should be 5 for Extended Properties).

What's weird is that a) Microsoft's documentation says they use a bmRequest value of 0xC1 which corresponds to 

USB_REQ_RECIP_DEVICE | USB_REQ_TYPE_VENDOR | USB_REQ_DIR_IN

i.e. it should *always* be a device request, not an interface request. And b) How would it ever work without wIndex being 5?

 

It's weird though because I think my code should handle the interface request too. And also this bit isn't working yet - Windows doesn't set my DeviceInterfaceGUID properly yet.

 

5. If I totally disable the Extended Properties it still installs fine. It just doesn't get a DeviceInterfaceGUID under

 

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\<Device Identifier>\<Instance Identifier>\Device Parameters

 

The easiest way to debug things is to install the WinUSB driver manually using Zadig, and then to use xusb until prints the 0xEE string and the Compat ID data properly. Note that the 0xEE string may have a random character on the end depending on which Vendor Code you specify (e.g. I used vendor code 33 which means xusb prints it as "WINUSB!").

 

I'm still trying to work out why the DeviceInterfaceGUID isn't working. I'll post code when it is.

Last Edited: Tue. Oct 27, 2015 - 09:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Timmmm wrote:

3. Lots of stuff is cached by Windows, so to aid debugging it helps to change your VID or PID every time.

 

I find only the USBFLAGS thing is cached permanently.  The Enum\USB\VID-PID.. stuff will go away if you plug it in, go to Device Manager, and uninstall it.

 

The stuff in the picture below vanished when I uninstall the device.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Timmmm wrote:

I'm still trying to work out why the DeviceInterfaceGUID isn't working. I'll post code when it is.

I got the GUID thing to work on Windows 10.  My Windows 7 doesn't read the extended properties descriptor, which is where the GUID is.

Last Edited: Wed. Oct 28, 2015 - 09:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are farther along than I am.  I haven't run anything on the PC.  I have spent my time putting the proper descriptors in the Xmega and sending them correctly to the PC when asked.

 

Which Windows are you using?  Where do you get the driver you installed?

 

I think with WCID I shouldn't have to install a driver on Windows 10.  I don't know about Windows 7.

 

Even though I got the GUID to install on Windows 10, Windows didn't install a driver.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I should add that I used DeviceInterfaceGUIDs, with an s on the end.  P. Batard does it this way in case he has more than one interface.  So I just duplicated his stuff.  I think it should work with or without the s.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using Windows 10 for main development. When you plug in the device it pops up an "Installing driver" dialog and automatically installs WinUSB. It is pretty quick so I think it uses a local copy. I tested it on Windows 7 and it also installs WinUSB automatically! But for Windows 7 it has to get the driver from Microsoft's servers in the usual way, so it is a bit slower. Still completely automatic though.

 

I am still stuck on the DeviceInterfaceGUID. How do you know if it has worked? Check the registry key?

 

I found a few bugs in my code - note to future people:

 

1. The Compat IDs header is subtly different from the Extended Properties header - the 7 bytes padding is only in one, and the count is 2 byte in one and 4 in the other (why Microsoft why?!)

2. It's not really clear from Microsofts documentation but the bcdVersion field is *their* version. I.e. it must be 0x0100 for MS OS descriptors 1.0 (there is also a 2.0 version which I may switch to).

 

And I also managed to get serial debugging working on my device (yeah it was pretty difficult debugging with a single LED!). If I log all the USB SETUP packets I get this:

 

SETUP bmRequest: 128, bRequest: 6, wValue: 256, wIndex: 0, wLength: 64
in? 1, standard? 1, interface? 0, endpoint? 0
SETUP bmRequest: 0, bRequest: 5, wValue: 6, wIndex: 0, wLength: 0
in? 0, standard? 1, interface? 0, endpoint? 0
SETUP bmRequest: 128, bRequest: 6, wValue: 256, wIndex: 0, wLength: 18
in? 1, standard? 1, interface? 0, endpoint? 0
SETUP bmRequest: 128, bRequest: 6, wValue: 512, wIndex: 0, wLength: 255
in? 1, standard? 1, interface? 0, endpoint? 0
SETUP bmRequest: 128, bRequest: 6, wValue: 1006, wIndex: 0, wLength: 18
in? 1, standard? 1, interface? 0, endpoint? 0
SETUP bmRequest: 192, bRequest: 33, wValue: 0, wIndex: 4, wLength: 16
in? 1, standard? 0, interface? 0, endpoint? 0
SETUP bmRequest: 192, bRequest: 33, wValue: 0, wIndex: 4, wLength: 40
in? 1, standard? 0, interface? 0, endpoint? 0

SETUP bmRequest: 128, bRequest: 6, wValue: 768, wIndex: 0, wLength: 255
in? 1, standard? 1, interface? 0, endpoint? 0
SETUP bmRequest: 128, bRequest: 6, wValue: 770, wIndex: 1033, wLength: 255
in? 1, standard? 1, interface? 0, endpoint? 0
SETUP bmRequest: 193, bRequest: 33, wValue: 0, wIndex: 5, wLength: 10
in? 1, standard? 0, interface? 1, endpoint? 0
SETUP bmRequest: 193, bRequest: 33, wValue: 0, wIndex: 5, wLength: 148
in? 1, standard? 0, interface? 1, endpoint? 0

SETUP bmRequest: 128, bRequest: 6, wValue: 256, wIndex: 0, wLength: 18
in? 1, standard? 1, interface? 0, endpoint? 0
SETUP bmRequest: 128, bRequest: 6, wValue: 512, wIndex: 0, wLength: 9
in? 1, standard? 1, interface? 0, endpoint? 0
SETUP bmRequest: 128, bRequest: 6, wValue: 512, wIndex: 0, wLength: 69
in? 1, standard? 1, interface? 0, endpoint? 0
SETUP bmRequest: 128, bRequest: 0, wValue: 0, wIndex: 0, wLength: 2
in? 1, standard? 1, interface? 0, endpoint? 0
SETUP bmRequest: 0, bRequest: 9, wValue: 1, wIndex: 0, wLength: 0
in? 0, standard? 1, interface? 0, endpoint? 0
SETUP bmRequest: 1, bRequest: 11, wValue: 0, wIndex: 0, wLength: 0
in? 0, standard? 1, interface? 1, endpoint? 0

 

The bolded entries show the queries for the Compat ID (4) and Extended Properties (5). There are two queries for each because the first one is to retrieve the header so it can read the length. You can also see that the target for the Extended Properties is (weirdly) set to an interface. This is what that xusb command line option was going on about, so it is normal that xusb can't get your Extended Properties without the -w flag.

 

In the end though, I still haven't got the Extended Properties to work. I've tried both DeviceInterfaceGUID and DeviceInterfaceGUIDs. Neither seem to work. My data exactly matches the data they give in that article, but I still don't see a DeviceInterfaceGUID registry key. Here is the xusb output.

 

C:\Users\Me\Downloads\libusb-1.0.20\examples\bin64>xusb -w 222c:222c
Using libusb v1.0.20.11004

Opening device 222C:222C...

Reading device descriptor:
            length: 18
      device class: 0
               S/N: 0
           VID:PID: 222C:222C
         bcdDevice: 0100
   iMan:iProd:iSer: 1:2:0
          nb confs: 1

Reading BOS descriptor: no descriptor

Reading first configuration descriptor:
             nb interfaces: 1
              interface[0]: id = 0
interface[0].altsetting[0]: num endpoints = 0
   Class.SubClass.Protocol: FF.00.00
interface[0].altsetting[1]: num endpoints = 6
   Class.SubClass.Protocol: FF.00.00
       endpoint[0].address: 83
           max packet size: 0040
          polling interval: 01
       endpoint[1].address: 04
           max packet size: 0040
          polling interval: 01
       endpoint[2].address: 85
           max packet size: 0200
          polling interval: 00
       endpoint[3].address: 06
           max packet size: 0200
          polling interval: 00
       endpoint[4].address: 81
           max packet size: 0040
          polling interval: 01
       endpoint[5].address: 02
           max packet size: 0040
          polling interval: 01

Claiming interface 0...

Reading string descriptors:
   String (0x01): "My Name"
   String (0x02): "My Device"
   String (0xEE): "MSFT100!"

Reading Extended Compat ID OS Feature Descriptor (wIndex = 0x0004):

  00000000  28 00 00 00 00 01 04 00 01 00 00 00 00 00 00 00  (...............
  00000010  00 00 57 49 4e 55 53 42 00 00 00 00 00 00 00 00  ..WINUSB........
  00000020  00 00 00 00 00 00 00 00                          ........

Reading Extended Properties OS Feature Descriptor (wIndex = 0x0005):

  00000000  92 00 00 00 00 01 05 00 01 00 88 00 00 00 07 00  ................
  00000010  00 00 2a 00 44 00 65 00 76 00 69 00 63 00 65 00  ..*.D.e.v.i.c.e.
  00000020  49 00 6e 00 74 00 65 00 72 00 66 00 61 00 63 00  I.n.t.e.r.f.a.c.
  00000030  65 00 47 00 55 00 49 00 44 00 73 00 00 00 50 00  e.G.U.I.D.s...P.
  00000040  00 00 7b 00 61 00 34 00 35 00 31 00 35 00 38 00  ..{.a.4.5.1.5.8.
  00000050  38 00 63 00 2d 00 37 00 32 00 33 00 30 00 2d 00  8.c.-.7.2.3.0.-.
  00000060  34 00 30 00 37 00 36 00 2d 00 38 00 34 00 35 00  4.0.7.6.-.8.4.5.
  00000070  36 00 2d 00 39 00 65 00 35 00 34 00 34 00 31 00  6.-.9.e.5.4.4.1.
  00000080  36 00 35 00 64 00 39 00 30 00 63 00 7d 00 00 00  6.5.d.9.0.c.}...
  00000090  00 00                                            ..

Releasing interface 0...
Closing device...

Any ideas? I'm thinking of trying MS OS descriptors 2.0 instead.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Aha! Scratch that it is working! I was just looking in the wrong place in the registry!

 

:-D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good.  I got mine working too.  I had a bug in the compatible ID descriptor.  Now it installs the WinUSB driver on Win7 and Win10.

 

Win7 does not request the extended properties descriptor.  It therefore doesn't get the GUID from the device.  The "device parameters " in the registry ENUM\USB .... entry is empty except for a "default" not set thing.  I guess it will work okay though.

 

Now I will look for a sample PC program that uses the WinUSB driver.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So Timmmm, did you get a PC program working that can use it?

 

I'm having a bad time doing it.  There is a VS project to create a skeleton program that can be added to.  I can't get it to run.  I can build it, but it wants to deploy stuff before it will run.  I can't get the deploy to work, so I can't get the program to run.  The solution has two projects.  There is a "driver" project that seems to only have an .inf file in it.  I guess that's what it wants to deploy.  I don't know why I need an .inf file at this point.

 

I'm thinking it may be easier to use libusb.  Hopefully I can integrate this into a VS project.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Progress is slow and painful.  I just learned something from the internet.  Win7 does request the extended properties and thus the device interface GUID if plugged into a USB 2 port.  It does not request that if plugged into a USB 3 port.  Apparently a bug in the USB 3 driver.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any chance you guys could post some code? I'm working on this too and mine will be open source, but at the moment there isn't much to go on.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Xmega or PC code?

 

I'm currently cleaning up the PC code.  The software in the Microsoft sample drives me nuts.  It works, but I want it flexible and understandable. 

 

There are just 3 files, and not particularly big ones either.  main.cpp device.cpp and device.h.  C++ code you think?  Not a chance.  It has no classes but it has structs that are passed from one function to another function, to another function on ad infinitum. 

 

It's among the most obtuse code I can remember seeing.  Good lord, if there ever was a demonstration of why true C++ can be infinitely better than C, this is it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

XMEGA, my WinUSB PC code is working nicely thanks :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't use ASF.  I've zipped up my USB driver code.  I basically use the info from the pbatard and Dean Camera links I posted previously.

 

The 3 classes at the end of the vendor specific descriptors are what you need.  The Microsoft_OS_string_descriptor  is sent from the usb_setup_parse.h when string 0xee is requested.

 

The Microsoft_compatible_ID_descriptor and Microsoft_extended_properties_descriptor are sent from usb_setup_vendor_parse.cpp

 

 

If you have something going but it doesn't work, maybe I can help.  You can look in a couple of registry locations to see what you have.

 

You say your WinUSB PC code is working nicely.  What USB device is it working with?

 

You need to change the GUID in device.h to match the one you specify in the Xmega.

 

 

 

 

 

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I could send you my hex file. 

 

I might be able to export my Atmel Studio project.  I've done that easily in the past but I always made a stripped down project and added the files to the project with Atmel's "Add" which is actually a copy and add.  I normally use Atmel's "Add as link", and I don't know if Atmel's export template thing can handle that.

Last Edited: Thu. Nov 19, 2015 - 11:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You must specify USB version 2 in the device descriptor.  Microsoft ignores this stuff if you specify USB 1.  I think the pbatard link mentioned above explains all this stuff.

https://www.avrfreaks.net/comment/1697406#comment-1697406

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Steve, lots of help there. Windows is reading the MSFT100 string and putting my set vendor code in the registry, but xusb is unable to query the device due to the following error:

 

Reading BOS descriptor: libusb: error [composite_submit_control_transfer] no lib
usb supported interfaces to complete request
libusb: error [libusb_get_bos_descriptor] failed to read BOS (-5)
no descriptor

 

I'm having trouble with the extended properties descriptor as the device driver is not auto-installing on Windows 7. It searches Windows Update and then gives up.

 

I'll keep at it, your code was very helpful, but it's tricky to debug without xusb.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's the whole xusb output, in case it helps:

 

Using libusb v1.0.20.11004

Opening device 8282:6895...
libusb: error [init_device] program assertion failed: device address collision w
ith root hub
libusb: info [windows_get_device_list] The following device has no driver: '\\.\
USB#VID_8282&PID_6895&MI_01#7&8BC8BEE&0&0001'
libusb: info [windows_get_device_list] libusb will not be able to access it.

Reading device descriptor:
            length: 18
      device class: 0
               S/N: 3
           VID:PID: 8282:6895
         bcdDevice: 0100
   iMan:iProd:iSer: 1:2:3
          nb confs: 1

Reading BOS descriptor: libusb: error [composite_submit_control_transfer] no lib
usb supported interfaces to complete request
libusb: error [libusb_get_bos_descriptor] failed to read BOS (-5)
no descriptor

Reading first configuration descriptor:
             nb interfaces: 2
              interface[0]: id = 0
interface[0].altsetting[0]: num endpoints = 2
   Class.SubClass.Protocol: 03.00.00
       endpoint[0].address: 81
           max packet size: 0040
          polling interval: 04
       endpoint[1].address: 02
           max packet size: 0040
          polling interval: 04
              interface[1]: id = 1
interface[1].altsetting[0]: num endpoints = 0
   Class.SubClass.Protocol: FF.FF.FF
interface[1].altsetting[1]: num endpoints = 2
   Class.SubClass.Protocol: FF.FF.FF
       endpoint[0].address: 83
           max packet size: 0040
          polling interval: 01
       endpoint[1].address: 04
           max packet size: 0040
          polling interval: 01

Claiming interface 0...

Claiming interface 1...
   Failed.

Reading string descriptors:
   String (0x01): "KEIO"
   String (0x02): "SUPERPLAY Joystick"
   String (0x03): "355530333535-FF-FF19FF09"

Releasing interface 0...
Releasing interface 1...
Closing device...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is my xusb output.  I can't paste it here because it tells me it can't accept my post because of invalid characters.  What's your secret for posting?

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Steve. The bos descriptor error seems to be a red herring. I'm debugging now...

 

To post I clicked on the "code" icon and set it to plain text.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your xusb output doesn't show the 0xEE string.  I think that is the first step.  I think Microsoft only reads this once, and makes a permanent entry in the registry.  Here you can see my vendor code.  I use 6.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, I'm not sure why that is. In my registry I see the osvc = 01 22, where 22 is the vendor code I put in my firmware as a test. So apparently Windows is reading it... I keep changing PID as well, to avoid issues with caching.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried posting using the "code" thing, but apparently by that time I got my avrfreaks session screwed up and the "code" thing didn't work either, even when I clicked the "Text" thing.

 

That registry entry in "control/usbflags" is permanent, so if you screw that up, you need to change PID or VID.  The other entry in Enum\USB is not permanent.  You can get rid of it by plugging in the device so you get an entry in Device Manager.  Then uninstall the device.  Goodbye registry entry.

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I should have used the -w option for xusb because of a Windows bug.  I'll try pasting again.  Nope.  I'll try FireFox.  Nope.

 

 

 

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've noticed that Windows queries the 0xEE string, but xusb does not. I can't understand why.

 

Anyway, I got it working, kind of! My device is a composite device so I was looking in the wrong place in the registry. I can see the DeviceInterfaceGUIDs registry entry with my custom value. I just need to get it to install the damn WINUSB driver now, but that can wait until tomorrow.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mojo-chan wrote:

I've noticed that Windows queries the 0xEE string, but xusb does not. I can't understand why.

I don't understand either.  Maybe it is time to change the VID or PID or serial number string, to get another entry in control/usbflags.

 

Windows only reads the 0xEE string once for a particular device, and keeps it in the registry.  Hopefully the PC isn't reading it each time you attach.

 

I kept my device simple, with only one interface.

 

As you probably know, Windows 7 needs to download the driver.  It will do that automatically unless you turned off that option.

 

I can log all my setup packets and responses and display them on the PC.  I can confirm that Windows does not read the string 0xEE whenever I attach.  xusb does.  It sends 15 setup packets and that one is #11.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To qualify as WCID, you also need the Microsoft_compatible_ID_descriptor.  It took me a couple of tries to get it right.  pbatard gives you every byte of the descriptor.  He explains the whole thing.  You need to see this in the registry.

 

If you use LIBUSB instead of WINUSB, maybe you'll have to download that yourself.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah, that's helpful. The CompatibleIDs is being set to MS_COMP_WINUSB_USB for the HID part of the device, not the vendor specific part. That would explain why it's not loading the WinUSB driver. I'm not sure how to make it attribute all the extended stuff to the vendor interface. Research time.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Gah, obviously it's the interface number in the Compatible ID Feature Descriptor. Okay, so now it has the right CompatibleIDs on the right interface.

 

So now I have:

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I got it working!

 

It seems that my stupid Windows 7 install was not downloading the driver from Windows Update as it was supposed to. I'm not sure why... It's a corporate install, and it can be funny with updates. I'll try it at home on my Windows 7 and Windows 8 machines, but hopefully it will work now. If I change the PID it installs the right driver instantly.

 

I'll publish my code to GitHub shortly. I just want to get the device name registry entry working too, so it doesn't just say "WinUSB device".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, I gave up, for some reason even with the "Label" and "Icons" extended properties they don't work. They appear in the registry but have no effect. Probably due to this being a composite device. The Devices and Printers window picks up the icon from the HID side.

 

Code here, I'll merge it after testing: https://github.com/mojo-chan/Sup...

 

Thanks for the help Steve, much appreciated.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Guys how can i make WCID work with my existing single CDC code..I using samd21e16bu and atmel sudio 7.

 

When connect in win10 the OS doesn't query for 0xEE ?..What changes i have to do kindly suggest.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

npashine wrote:
..I using samd21e16bu
Then you are asking in the wrong place/thread. This area is for AVR not ARM.

 

Moderator.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry My bad..