help with request types

[ulao]

I seem to have misplaced my knowledge I once had about the report types.

I know there are interrupt and controller transfers.
I know about GETS and SETs but the input output and features are confusing me and the usb nut shell docs are not give me my answer.


I'm watching a DirrectX PID (rumble) effect. The descriptor is made my Microsoft. You can see it here.
http://www.microchip.com/forums/FindPost/378772


//the controller trasfer
set report (feature id 15 len 4) //this makes sense
get report (feature id 2 len 132)//no idea where the 132 is coming from? should be 4

//the bulk
output report id 2 len 8
output report id 1 len 16 (should be 8 )
output report id A len 4

Now aside from the wrong sizes, that all make sense to me. but dealing with it in my code is whats confusing.

for the gets and sets it is pretty straight forward.

if(rq->bRequest == USBRQ_HID_GET_REPORT)
{
if RID=x) do this
}
if(rq->bRequest == USBRQ_HID_SET_REPORT)
{
if RID=x) do this
}

but I do not see how to handle the outputs inputs and features. At one point I had this understood.  These are my defines available to me.

Code: [Select]

/* USB setup recipient values */
#define USBRQ_RCPT_MASK         0x1f
#define USBRQ_RCPT_DEVICE       0
#define USBRQ_RCPT_INTERFACE    1
#define USBRQ_RCPT_ENDPOINT     2

/* USB request type values */
#define USBRQ_TYPE_MASK         0x60
#define USBRQ_TYPE_STANDARD     (0<<5)
#define USBRQ_TYPE_CLASS        (1<<5)
#define USBRQ_TYPE_VENDOR       (2<<5)

/* USB direction values: */
#define USBRQ_DIR_MASK              0x80
#define USBRQ_DIR_HOST_TO_DEVICE    (0<<7)
#define USBRQ_DIR_DEVICE_TO_HOST    (1<<7)

/* USB Standard Requests */
#define USBRQ_GET_STATUS        0
#define USBRQ_CLEAR_FEATURE     1
#define USBRQ_SET_FEATURE       3
#define USBRQ_SET_ADDRESS       5
#define USBRQ_GET_DESCRIPTOR    6
#define USBRQ_SET_DESCRIPTOR    7
#define USBRQ_GET_CONFIGURATION 8
#define USBRQ_SET_CONFIGURATION 9
#define USBRQ_GET_INTERFACE     10
#define USBRQ_SET_INTERFACE     11
#define USBRQ_SYNCH_FRAME       12

/* USB descriptor constants */
#define USBDESCR_DEVICE         1
#define USBDESCR_CONFIG         2
#define USBDESCR_STRING         3
#define USBDESCR_INTERFACE      4
#define USBDESCR_ENDPOINT       5
#define USBDESCR_HID            0x21
#define USBDESCR_HID_REPORT     0x22
#define USBDESCR_HID_PHYS       0x23

//#define USBATTR_BUSPOWER        0x80  // USB 1.1 does not define this value any more
#define USBATTR_BUSPOWER        0
#define USBATTR_SELFPOWER       0x40
#define USBATTR_REMOTEWAKE      0x20

/* USB HID Requests */
#define USBRQ_HID_GET_REPORT    0x01
#define USBRQ_HID_GET_IDLE      0x02
#define USBRQ_HID_GET_PROTOCOL  0x03
#define USBRQ_HID_SET_REPORT    0x09
#define USBRQ_HID_SET_IDLE      0x0a
#define USBRQ_HID_SET_PROTOCOL  0x0b

this is my stuct
    uchar       bmRequestType;
    uchar       bRequest;
    usbWord_t   wValue;
    usbWord_t   wIndex;
    usbWord_t   wLength;
}usbRequest_t;

Where do I get my input output and features info?

[ulao]

ok I think I finally dug it out.  second byte in wValue after Rid holds the report type
rq->wValue.bytes[1]


but this is still not 100% clear to me. I think there are still two main types.
control and bulk
when the output bulk comes in I can not catch the output report.
if(rq->wValue.bytes[1]==2)  //never enters this if. Though I can see in usblyzer that a bulk output was attempted.
The only report types I can catch are the control types.

do bulk output reports go straight to usbFunctionWrite and skip usbFunctionSetup ?

[Jan Axelson]

HIDs transfer reports using control or interrupt transfers.

On the bus, interrupt is identical to bulk. (Scheduling, allowed speeds, packet size differ.)

Reports sent in interrupt transfers have no stages. They just transfer the data with the report ID in the first byte only if the HID uses multiple report IDs.

Interrupt transfers are allowed only for Input and Output reports, not Feature.

[ulao]

All of that make sense to me but I do not see the data in my firmware. The confusion is with the code. The code I'm using is this v-usb thing but it does follow normal nomenclature. There is a function called usbFunctionWrite and a function called usbFunctionSetup.

usbFunctionWrite  is for SET reports and I know how it works. The confusion is this usbFunctionSetup. Apparently this is the entry point for data. When the data is stuffed in to the struct I get

wValue.bytes[0]; Report ID
bRequest  Get or set reports
wValue.bytes[1] input output feaurte

I see my gets and sets in the usb sniffer and I see them in code in bRequest 
example set report (feature id15 len 4)   -  this is what I see in the usb sniffer
I have no issue understanding this.

what make no sense to me is when I see this in the usb sniffer
output report id:5 len16
I do not see this in the code anywhere. I would have excepted this
 set report (output id5 len 16) 

the difference is the first example is a control transfer while the second is a bulk.  I'm unable to figure out how this transfer enters in to the firmware.

[ulao]

ok after a lot of researching I found these two are the cause of my size issue

the get (feature rID:2 len132)
has the wrong size and it is getting the size from the report id 18
at first I though the 18 was rolling over 15 making it a 2 but changing the report ID didnt fix that. So I'm not sure how these two are conflicting.

The reason I know this is the problem is because setting the report 17 size to another number changes report id 2.




 0xa1, 0x01,                    // COLLECTION (Application)
    0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
    0x26, 0xff, 0x00,              //   LOGICAL_MAXIMUM (255)
    0x75, 0x08,                    //   REPORT_SIZE (

    0x85, 0x11,                    //   REPORT_ID (17)
    0x95, 0x79,                    //   REPORT_COUNT (127) -- the max
    0x09, 0x00,                    //   USAGE (Undefined)
    0xb2, 0x02, 0x01,              //   FEATURE (Data,Var,Abs,Buf)

    0x85, 0x12,                    //   REPORT_ID (18)
    0x95, 0x80,                    //   REPORT_COUNT (131) -- the max
    0x09, 0x00,                    //   USAGE (Undefined)
    0xb2, 0x02, 0x01,              //   FEATURE (Data,Var,Abs,Buf)
    0xc0,                           // END_COLLECTION



0x05,0x0F,    //    Usage Page Physical Interface
0x09,0x89,    //    Usage Block Load Status
0xA1,0x02,    //    Collection Datalink
   0x85,0x02,    //    Report ID 2
   0x09,0x22,    //    Usage Effect Block Index
   0x25,0x28,    //    Logical Maximum 28h (40d)
   0x15,0x01,    //    Logical Minimum 1
   0x35,0x01,    //    Physical Minimum 1
   0x45,0x28,    //    Physical Maximum 28h (40d)
   0x75,0x08,    //    Report Size 8
   0x95,0x01,    //    Report Count 1
   0xB1,0x02,    //    Feature (Variable)
   0x09,0x8B,    //    Usage Block Load Full
   0xA1,0x02,    //    Collection Datalink
      0x09,0x8C,    //    Usage Block Load Error
      0x09,0x8D,    //    Usage Block Handle
      0x09,0x8E,    //    Usage PID Block Free Report
      0x25,0x03,    //    Logical Maximum 3
      0x15,0x01,    //    Logical Minimum 1
      0x35,0x01,    //    Physical Minimum 1
      0x45,0x03,    //    Physical Maximum 3
      0x75,0x08,    //    Report Size 8
      0x95,0x01,    //    Report Count 1
      0xB1,0x00,    //    Feature
   0xC0     ,                   // End Collection
   0x09,0xAC,                   //    Usage Undefined
   0x15,0x00,                   //    Logical Minimum 0
   0x27,0xFF,0xFF,0x00,0x00,    //    Logical Maximum FFFFh (65535d)
   0x35,0x00,                   //    Physical Minimum 0
   0x47,0xFF,0xFF,0x00,0x00,    //    Physical Maximum FFFFh (65535d)
   0x75,0x10,                   //    Report Size 10h (16d)
   0x95,0x01,                   //    Report Count 1
   0xB1,0x00,                   //    Feature
0xC0     ,    //    End Collection

if I remove this conflicting portion it claims 9 bytes but really should be 5.


the entire descriptor itself has too many lines for this form.


***update on the first issue, I was in fact correct. No wonder I was so confused. ****

Using Interrupt- and Bulk-Out endpoints

Interrupt- and Bulk-Out endpoints are used to send stream type data to the device. When the host sends a chunk of data on the endpoint, the function usbFunctionWriteOut() is called. If you use more than one interrupt- or bulk-out endpoint, the endpoint number is passed in the global variable usbRxToken. You must define USB_CFG_IMPLEMENT_FN_WRITEOUT to 1 in usbconfig.h when you use this feature.

[Jan Axelson]

I'm not sure if you have it all figured out or not.

But another point to be aware of is:

Under Windows, the host uses interrupt transfers to send and receive reports UNLESS the application uses a HidD_Get/Set function OR the HID doesn't have an interrupt OUT endpoint.

[ulao]

No not all figure out.. the report mixing is still confusing me. I just figured out one of my issues. I need to know why feature report 2 shows a length of feature report 18. This really is causing issues in my code. It very clearly says the length is 4 + RID (5) not 132, and not 9. Very confused by this....




Yes I see your point. I have a two endpoints

 7,          /* sizeof(usbDescrEndpoint) */
    USBDESCR_ENDPOINT,  /* descriptor type = endpoint */
    0x81,       // bulk IN endpoint number 1
    0x03,       /* attrib: Interrupt endpoint */
    8, 0,       /* maximum packet size */
    0x08, /* in ms*/

//the output.

    7,          // sizeof(usbDescrEndpoint)
    USBDESCR_ENDPOINT,  // descriptor type = endpoint
    0x01,        // out endpoint
    0x03,       // attrib: Interrupt endpoint
    8, 0,       // maximum packet size
    0x08, // in ms

I see these endpoints and I wrote an application that uses HID get/set and I use an application that sends bulk data.

the part that was confusing me was how my driver deals with control and int/bulk separately. Now that I have that understood things are making more sense. All but this size confusion.
 

[Jan Axelson]

The comments here appear to be incorrect:

Report count is 131 decimal:

0x95, 0x79,                    //   REPORT_COUNT (127) -- the max

Report count is 128 decimal:

0x95, 0x80,                    //   REPORT_COUNT (131) -- the max

I don't know what you mean by "it is getting the size from the report id 18"

What happens when you attempt to set or get feature report 2? Is the Setup packet correct? How much data does the host or device send?

Also, HIDs do interrupt and control transfers, not bulk.

[ulao]

Also, HIDs do interrupt and control transfers, not bulk.

That helps, so I know its int. then.

About the reports.
0x80 was a test  forgot to change it back to 83
0x79 was an error sholuld have been 0x7f
0x95, 0x83,                    //   REPORT_COUNT (131) -- the max
0x95, 0x7f,                    //   REPORT_COUNT (127) -- the max
This could explain some of the stalls I get.

 "it is getting the size from the report id 18"
yeah I know hard to explain. I'll try from scratch.

feature report id 2 is a size of 5 (including the report id) as defined in the descriptor.  When I see the USB data in the sniffer The report size shows 132. If I remove the report feature 18 from my descriptor and run the sniffer the length for report ID 2 changes to 9. (now conflicting with another report I guess). Like I mentioned it should be 5.

It is almost like the descriptor is some how mangled and it reading the wrong length for that report id.


What happens when you attempt to set or get feature report 2? It works just as it should and very often stalls. When it stall I just retry. but as I said above the length is wrong. It is expecting 132 bytes not 5.


Is the Setup packet correct? - The packets show the right data.


How much data does the host or device send? for report id (feature) only 5 bytes. Even though it is asking for 132.

[Jan Axelson]

Yes, it looks like the descriptor has an error in it somewhere. One approach would be to start with a simpler version, get it working, then add to it.

Under Windows, before each change to the descriptors, use Device Manager to uninstall the device so Windows doesn't try to use the previously stored descriptors.

[ulao]

Sadly that is not possible. There are 3 sections.

1. the gamepad layer
2. the Force Feedback
3. the reports I use for my API

1 and 3 work fine without the Force feedback but the Force feedback is about 500 lines. There error is in there somewhere and I didnt write it. It was ripped from an MS sidewinder that Microsoft wrote. If I remove it my code runs as expected. if I remove my API the force feedback still has issues. To make matters even worcse, taking any part of the FFB section out, cripples it and make it unusable. I must keep that entire report in tack for it to be tested with.

So I'm forced to troubleshoot as is.  I'm just hoping to get a few tips from the experienced. I don;t mind the leg work, I just don't know what to look for.

[Jan Axelson]

Are you uninstalling before each firmware change?

[ulao]

Oh, didn;t see that note before. I never had to do that before? If that is true, that woudl explain a lot. I'll try that.

[ulao]

You fixed my stall issue.......... You have no idea how grateful I am...


Sadly it didn't fix the issue with the report size but if the stall is not a problem I can make due.

[Jan Axelson]

Yes, it's an annoying "feature" of Windows that has caused much grief for developers.