This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

MCSTR9 USB can't change the InputReport >64 Bytes

I'm trying to change the input report to 100 but it doen't work. I read almost all the threads of Tsuneo, but i can not get it to work. When I use the "SimpleHIDwrite" and try to get the reports i get "Get Report Error: Data Error (Cyclic redundancy check) (17)".

This only happens when i tried to make the input_report > 64 Bytes, otherwise works perfect
other thing is that i read that if the packet that you send is smaller is automatically reduced, but not to me :(.
From USBcfg.h i have the nexts defines

#define USB_MAX_PACKET0     64
#define InReport_length         100

Here i will put my report descriptor:

const BYTE HID_ReportDescriptor[] = {
  HID_UsagePageVendor( 0x00                                   ),
  HID_Usage(           0x01                                   ),
  HID_Collection(      HID_Application                        ),
    HID_LogicalMin(    0                                      ),
    HID_LogicalMaxS(   0xFF                                   ),
    HID_ReportSize(    8                                      ),  // bits
    HID_ReportCount(   InReport_length                        ),  // bytes
    HID_Usage(         0x01                                   ),
    HID_Input(         HID_Data | HID_Variable | HID_Absolute ),
    HID_ReportCount(   4                                      ),  // bytes
    HID_Usage(         0x01                                   ),
    HID_Output(        HID_Data | HID_Variable | HID_Absolute ),
  HID_EndCollection,
};
const WORD HID_ReportDescSize = sizeof(HID_ReportDescriptor);

This part is in USBconfigdescriptor[]

const BYTE USB_ConfigDescriptor[] = {
.....
.....
 USB_ENDPOINT_DESC_SIZE,            /* bLength */
  USB_ENDPOINT_DESCRIPTOR_TYPE,      /* bDescriptorType */
  USB_ENDPOINT_IN(1),                /* bEndpointAddress */
  USB_ENDPOINT_TYPE_INTERRUPT,       /* bmAttributes */
  WBVAL(0x0040),                     /* wMaxPacketSize */
  0x02,           /* 2ms */          /* bInterval */
/* Terminator */
  0                                  /* bLength */
};

I think that the problem may be is in hiduser.c but i could't check it because i didn't find code for this

BOOL HID_GetReport (void) {
  int i;
  /* ReportID = SetupPacket.wValue.WB.L; */

  switch (SetupPacket.wValue.WB.H) {
    case HID_REPORT_INPUT:
      GetInReport();
      for(i=0;i< InReport_length ;i++)
                EP0Buf[i] = InReport[i];                /*Copy all the report to send*/
          break;
    case HID_REPORT_OUTPUT:
      return (FALSE);          /* Not Supported */
    case HID_REPORT_FEATURE:
      /* EP0Buf[] = ...; */
      /* break; */
      return (FALSE);          /* Not Supported */
  }
  return (TRUE);
}


where EP0Buf[] is define in USBcore.h

extern BYTE  EP0Buf[USB_MAX_PACKET0];


Of course i realized that EP0Buf was smaller so i tried doing

extern BYTE  EP0Buf[InReport_length];

but was the same
Endpoint 1 is

void USB_EndPoint1 (DWORD event) {
  InEP_empty = TRUE;
}

If you need more info to deduce my problem just tell me..
Thanks

Parents
  • "The problem is in the Input report, you can noticed that i'm only replying when i have data to do it."

    Ummm... I din't notice it.
    Your above code for Get_Report( INPUT ) always returns a valid input report. But if you return STALL to Get_Report( INPUT ), it'll cause error and the host will reset the device by bus reset. Get_Report( INPUT ) has to be always answered, regardless of the reason of the device side.

    Unfortunately, the HID spec doesn't describe this restriction clearly.
    It notes that the support of Get_Report is mandatory:
    This means the device should always return a valid reply to Get_Report request. STALL to Get_Report occurs just when any one of the SETUP parameters is invalid (wValue, wIndex and wLength).

    For above strategy, use the interrupt IN endpoint, instead.

    Also, Get_Report and Set_Report doesn't fit to repeated access.
    For repeated access, use interrupt IN/OUT endpoint.



    "I solve my problem in a rustic way, i split my self the packet, but i would like to know what is the problem here."

    I copied your modification to this example, and it works fine.
    I suppressed the interrupt IN EP handler temporarily.

    LPC2368 / LPC2378 USB HID (Human Interface Device) Example
    http://www.keil.com/download/docs/335.asp

    As I can't find any error on your modification, it was required to check it on a working board, to ensure my answer. When I see some error, I just point it out without running it. :-)

    Doesn't the problem lie in the input report from the interrupt IN endpoint ?

    Tsuneo

Reply
  • "The problem is in the Input report, you can noticed that i'm only replying when i have data to do it."

    Ummm... I din't notice it.
    Your above code for Get_Report( INPUT ) always returns a valid input report. But if you return STALL to Get_Report( INPUT ), it'll cause error and the host will reset the device by bus reset. Get_Report( INPUT ) has to be always answered, regardless of the reason of the device side.

    Unfortunately, the HID spec doesn't describe this restriction clearly.
    It notes that the support of Get_Report is mandatory:
    This means the device should always return a valid reply to Get_Report request. STALL to Get_Report occurs just when any one of the SETUP parameters is invalid (wValue, wIndex and wLength).

    For above strategy, use the interrupt IN endpoint, instead.

    Also, Get_Report and Set_Report doesn't fit to repeated access.
    For repeated access, use interrupt IN/OUT endpoint.



    "I solve my problem in a rustic way, i split my self the packet, but i would like to know what is the problem here."

    I copied your modification to this example, and it works fine.
    I suppressed the interrupt IN EP handler temporarily.

    LPC2368 / LPC2378 USB HID (Human Interface Device) Example
    http://www.keil.com/download/docs/335.asp

    As I can't find any error on your modification, it was required to check it on a working board, to ensure my answer. When I see some error, I just point it out without running it. :-)

    Doesn't the problem lie in the input report from the interrupt IN endpoint ?

    Tsuneo

Children
No data