USB_FS SendReport data loss

licencje1 · ‎2014-08-13

Posted on August 13, 2014 at 13:32

Hi,

While I'm trying to send some test value through USB (using USBD_HID_SendReport -> comes from STCube library) first few data is being lost but I don't know while.

Here are my descriptor:

HID_DEV_ReportDesc[HID_DEV_REPORT_DESC_SIZE] =

{

0x06, 0x00, 0xff, // USAGE_PAGE (Vendor Defined Page 1)

0x09, 0x01, // USAGE (Vendor Usage 1)

0xa1, 0x01, // COLLECTION (Application)

0x15, 0x00, // LOGICAL_MINIMUM (0)

0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (255)

0x75, 0x08, // REPORT_SIZE (8)

0x85, 0x01, // REPORT_ID (1)

0x95, 0x01, // REPORT_COUNT (1)

0x09, 0x01, // USAGE (Vendor Usage 1)

0x81, 0x02, // INPUT (Data,Var,Abs)

0x09, 0x01, // USAGE (Vendor Usage 1)

0x91, 0x02, // OUTPUT (Data,Var,Abs)

0xc0 // END_COLLECTION

};

USBD_HID_CfgDesc[USB_HID_CONFIG_DESC_SIZ] =

{

0x09, /* bLength: Configuration Descriptor size */

USB_DESC_TYPE_CONFIGURATION, /* bDescriptorType: Configuration */

USB_HID_CONFIG_DESC_SIZ,

/* wTotalLength: Bytes returned */

0x00,

0x01, /*bNumInterfaces: 1 interface*/

0x01, /*bConfigurationValue: Configuration value*/

0x00, /*iConfiguration: Index of string descriptor describing

the configuration*/

0xE0, /*bmAttributes: bus powered and Support Remote Wake-up */

0x32, /*MaxPower 100 mA: this current is used for detecting Vbus*/

/************** Descriptor of Joystick Mouse interface ****************/

/* 09 */

0x09, /*bLength: Interface Descriptor size*/

USB_DESC_TYPE_INTERFACE,/*bDescriptorType: Interface descriptor type*/

0x00, /*bInterfaceNumber: Number of Interface*/

0x00, /*bAlternateSetting: Alternate setting*/

0x02, /*bNumEndpoints*/

0x03, /*bInterfaceClass: HID*/

0x00, /*bInterfaceSubClass : 1=BOOT, 0=no boot*/

0x00, /*nInterfaceProtocol : 0=none, 1=keyboard, 2=mouse*/

0, /*iInterface: Index of string descriptor*/

/******************** Descriptor of Joystick Mouse HID ********************/

/* 18 */

0x09, /*bLength: HID Descriptor size*/

HID_DESCRIPTOR_TYPE, /*bDescriptorType: HID*/

0x11, /*bcdHID: HID Class Spec release number*/

0x01,

0x00, /*bCountryCode: Hardware target country*/

0x01, /*bNumDescriptors: Number of HID class descriptors to follow*/

0x22, /*bDescriptorType*/

HID_DEV_REPORT_DESC_SIZE,/*wItemLength: Total length of Report descriptor*/

0x00,

/******************** Descriptor of Mouse endpoint ********************/

/* 27 */

0x07, /*bLength: Endpoint Descriptor size*/

USB_DESC_TYPE_ENDPOINT, /*bDescriptorType:*/

HID_EPIN_ADDR, /*bEndpointAddress: Endpoint Address (IN)*/

0x03, /*bmAttributes: Interrupt endpoint*/

HID_EPIN_SIZE, /*wMaxPacketSize: 4 Byte max */

0x00,

HID_POLLING_INTERVAL, /*bInterval: Polling Interval (10 ms)*/

/* 34 */

0x07, /*bLength: Endpoint Descriptor size*/

USB_DESC_TYPE_ENDPOINT, /*bDescriptorType:*/

HID_EPOUT_ADDR, /*bEndpointAddress: Endpoint Address (OUT)*/

0x03, /*bmAttributes: Interrupt endpoint*/

HID_EPOUT_SIZE, /*wMaxPacketSize: 4 Byte max */

0x00,

HID_POLLING_INTERVAL, /*bInterval: Polling Interval (10 ms)*/

/* 41 */

} ;

Can somebody help me to deal with that problem?

#hid #usb #send_report

tsuneo · ‎2014-08-13

Posted on August 13, 2014 at 17:26

> first few data is being lost

I'm not sure, what you mean by ''first few data'' a) How many bytes exactly are the data lost from the reports? Your report descriptor defines just two-bytes input/output reports of this format, byte# 0: report ID (1) 1: 1 byte data The first byte should be always 0x01, both for input/output reports. The second byte holds the one byte data. And then, ''first (a) few data'' means entire report, either for input or output 😉 b) Which endpoint drops the data? Your report descriptor defines both of input and output reports. Your config descriptor set declares interrupt IN and OUT endpoints. You have four ways to exchange reports between your device and host, 1) input report over the interrupt IN EP 2) input report over the default EP0 (Get_Report request) 3) output report over the interrupt OUT EP 4) output report over the default EP0 (Set_Report request) As the ST's code provides just the 1) way, using USBD_HID_SendReport(), you may talk on this way. To satisfy the format of your report descriptor, USBD_HID_SendReport() is called in this way,

report[0] = 0x01; // report ID
report[1] = your_one_byte_data;
len = 2;
USBD_HID_SendReport(&USBD_Device_FS, report, len);

Your firmware should call USBD_HID_SendReport(), just when it has new data to send. The cube code calls USBD_HID_SendReport() regularly in SysTick_Handler (or Callback), like

STM32Cube_FW_F4_V1.3.0\Projects\...\Applications\USB_Device\HID_Standalone\Src\stm32f4xx_it.c
void SysTick_Handler (void)
{
...
USBD_HID_SendReport(&USBD_Device_FS, HID_Buffer, 4);
STM32Cube_FW_F4_V1.3.0\Projects\...\Demonstrations\Src\main.c
void HAL_SYSTICK_Callback(void)
{
...
USBD_HID_SendReport (&hUSBDDevice,
buf,
4);

They are bad implementations, as a HID device. Tsuneo

licencje1 · ‎2014-08-14

Posted on August 14, 2014 at 09:54

Writing about loss of data I thought about such kind of situation:

In main.c inside while loop I've got some condition to chceck if the button is clicked, if yes I'm sending data as you show above. After first few click (two or three) I don't receive any correct data (which is buffer[] = {0x01, 'P'}) but after that I receive too many data (duplicated). You can see it in included screenshot of USBlyser sniffing (first incorrect data marked red next three marked blue (each one should be only 0x01,0x50)).

P.S I'm using library V2.2 so I haven't got any bad implementation in SysTick or Callback as you mention.

tsuneo · ‎2014-08-14

Posted on August 14, 2014 at 12:11

> You can see it in included screenshot of USBlyser sniffing (first incorrect data marked red next three marked blue (each one should be only 0x01,0x50)).

You are interpreting the USBlyzer log wrongly. The #0002 - #0004 three lines represent just a single transfer request, which sequentially goes down three components on the host driver stack. This request is pended, until #0008 - #0010 lines come. Though you’ve cut off the log table, you should see the same IRP value on these three lines. Also #0005 - #0007 are the second request, which is also pended. #0008 - #0010 lines are the completion of the first pended request (#0002 - #0004) #0011 - #0013 lines are the third pended request, reusing the first IRP object. #0014 - #0016 lines are the completion of the second pended request (#0005 - #0007) #0017 - #0019 lines are the fourth pended request, reusing the second IRP object. etc. Windows keep two outstanding requests for the interrupt IN EP of HID device, to ensure 1 ms interval. PC host controller defers the hardware interrupt of transfer completion just at the end of the frame (ie. the next SOF timing), in which the transfer completes. And then, single request can’t keep 1ms interval. In this reason, Windows apply two outstanding requests. There is nothing particular on your log. It’s a typical one for HID devices. After all, you are seeing just a ghost. > P.S I'm using library V2.2 so I haven't got any bad implementation in SysTick or Callback as you mention. What is ''library V2.2'' ? ST has released STM32_USB-Host-Device_Lib_V2.1.0, but no v2.2 This library has also wrong HID implementation using SysTick_Handler() I believe it is exactly your problem.

\STM32_USB-Host-Device_Lib_V2.1.0\Project\USB_Device_Examples\HID\src\system_stm32f2xx.c
void SysTick_Handler(void)
{
uint8_t *buf;
buf = USBD_HID_GetPos();
if((buf[1] != 0) ||(buf[2] != 0))
{
USBD_HID_SendReport (&USB_OTG_dev, // <--------------
buf,
4);
}
}

Tsuneo

licencje1 · ‎2014-08-14

Posted on August 14, 2014 at 13:33

I think that I haven't express myselfe correctly. I am not using demonstration project provided by ST, I write my own program (at the beginning realy simple). So that bad implementatiod do not occure in my code (there are clear USB+HID library provided by st (generated by stcubemx).

I'm enclosing my project (IAR) of course packed in *.rar.

________________

Attachments :

USB_IAR.rar : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0ap&d=%2Fa%2F0X0000000bas%2FfzUKDBW5e4hQcj0PmEn4kbCenW2S8MYRo7_7X5.BZLs&asPdf=false