USB libraries control transfer CTRL_TRF_SETUP wIndex being masked?

[Limited_Atonement]

I made a program that sends wIndex and wValue from the PIC to the host (Windows XP, WinUSB) in the payload.  (In fact, it sends all 8 bytes of the setup packet).  What I'm finding is that wIndex is being masked.  I'm getting the least-significant byte, but not the most significant (the most significant byte is set to 0x00).  This means that I'm losing data somewhere from Windows XP (SP 3) to the PIC, but I can't tell where.  Unfortunately, I'm going through two frameworks: WinUsb and the Jan/Microchip USB libraries.

Does anybody have experience with this?  Does the Jan Axelson library mask this, or Win USB? or is there something else I should be watching for.  I could send you my code if you like, but it should be pretty easy to reproduce if you're set up to program PIC over USB.  Thanks!

[EDIT!]

I was mistaken, it's the low byte that's masked...I think.  I'm getting the most-significant byte, but not the least-significant.

[Jan Axelson]

For what it's worth, Microsoft defines Index in WINUSB_SETUP_PACKET as USHORT, as does my example code. A protocol analyzer will show if the all 16 bits are transmitting on the bus.

Jan

[Limited_Atonement]

It looks like another fellow had the same problem with his composite device (bluetooth):

http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/0657c62e788b1fad?hl=en

Apparently, he didn't bother trying the upper byte of wIndex (which I bet would have worked).  I tried using the method outlined there (calling Winusb_GetAssociatedInterface) with no luck.

I think that the bytes are probably going on the bus, it's the WinUSB component that's not working correctly, perhaps because I'm not using it properly (I'm doing what the examples recommend).

Can anyone verify that the low byte of wIndex transfers using either Microchip WinUSB Control transfers (host-to-device) or Mr. Axelson's example?  Thanks again for your time.

[Limited_Atonement]

I think the problem may reside with the specification on the bottom of page 248 of the standard wherein it is stated:

When an interface or endpoint is specified, the wIndex field identifies the interface or .

So, I tried setting bmRequestType to target Device and Other, but with no luck (also Endpoint didn't work).

So a new question that should perhaps be a separate thread: How can I use the microchip libraries (as modified by Mr. Axelson) to target the PIC Device rather than endpoint?  What is the difference?  Where can I read about what the differences between the values in table 9-2 of the 2.0 standard (namely Device, Endpoint, Interface, and Other) are?

Thanks again for your time and effort.

[Jan Axelson]

If the device declares the WinUSB function as a vendor-specific function in an interface descriptor, for WinUSB control requests,  bmRequestType should use Recipient = Interface. In this case, wIndex should specify which interface to direct the request to, even if the device has only interface zero.

Microsoft seems to suggest that a device can instead declare the WinUSB function as a vendor-specific function in the device descriptor. See instance 1:

http://msdn.microsoft.com/en-us/library/ff540207%28VS.85%29.aspx

For WinUSB control requests, bmRequestType should then use Recipient = Device, and I believe wIndex can have any use. I haven't tried this option however.

For more about control transfers, WinUSB, and other USB topics, I recommend my book USB Complete:

http://www.lvr.com/usbc.htm

Jan

[Limited_Atonement]

Thanks for the reply.  That's very good information.  I think I am describing my function (and interface) as vendor-specific.  Here's the interface descriptor:

          ===>Interface Descriptor<===
bLength:                           0x09
bDescriptorType:                   0x04
bInterfaceNumber:                  0x00
bAlternateSetting:                 0x00
bNumEndpoints:                     0x04
bInterfaceClass:                   0xFF  -> Vendor Specific Device
bInterfaceSubClass:                0xFF
*!*CAUTION:    This appears to be an invalid bInterfaceSubClass
bInterfaceProtocol:                0xFF
iInterface:                        0x00
*!*CAUTION:  0xFF is a prerelease Class ID

And the device descriptor:

          ===>Device Descriptor<===
bLength:                           0x12
bDescriptorType:                   0x01
bcdUSB:                          0x0200
bDeviceClass:                      0xFF  -> This is a Vendor Specific Device
bDeviceSubClass:                   0xFF
bDeviceProtocol:                   0xFF
bMaxPacketSize0:                   0x08 = ( Bytes
idVendor:                        0x0925 = Vendor ID not listed with USB.org as of 03-19-2008
idProduct:                       0x1456
bcdDevice:                       0x0001
iManufacturer:                     0x01
     English (United States)  "ProCure TDC"
iProduct:                          0x02
     English (United States)  "Procure Engine Control"
iSerialNumber:                     0x00
bNumConfigurations:                0x01

as dumped from USBView or whatever program WDK ships.  As you can see, the interface and the device are now defined to be vendor-specific (before I read your post, only the interface descriptor had been set to vendor specific class by default by the libraries, and device class in the descriptor had been set to 0).

Let me know if I'm missing something, but I still cannot successfully target anything besides Interface in the bmRequestType (of the setup packet), and targeting Interface still masks the lower byte of bIndex (specifying the index I now understand).

Thanks again for your help!

[Jan Axelson]

It's possible that the WinUSB driver sets wIndex to the WinUSB interface even if the descriptors say the entire device is vendor-specific.

Again, devices that have support many different requests might find it more efficient to use a different transfer type rather than lots of different control requests.
 
Jan

[Limited_Atonement]

Thanks again for your help.  I have given up reclaiming the low byte of wIndex.  I now use the high byte of wIndex to pass parameters, and it's working fairly well.

[Jan Axelson]

I think that's a good strategy.

Jan

[ganzziani]

I was having this same problem, the low byte was being masked. I confirmed it by setting the Index to 0x1234, and I was only receiving 0x1200 in the microcontroller, and the same value was shown on USBTrace.
I checked this thread and changed:
setupPacket.RequestType = 0XC1;
to
setupPacket.RequestType = 0XC0;
and now the Index is received ok!