AnsweredAssumed Answered

Problem with periodic slot for USB Interrupt transfer to a interrupt endpoint - i.MX25

Question asked by Vinay Bondade on Feb 4, 2016
Latest reply on Mar 4, 2016 by CarlosCasillas
Branched to a new discussion

Hi,

 

I have been trying to communicate to MCP2200 which has HID and USB Serial (CDC-ACM) interface. lsusb output can be found at - MCP2200 lsusb enumeration · GitHub

 

There is a strange problem that if i.MX25 goes to standby (low power mode) not as a host (No USB device attached) and wakes up that way, and is then connected to the MCP2200. i.Mx25 becomes host, the interrupt transfers now to the OUT interrupt endpoint of HID interface take around 600 milliseconds which used to take 20 milliseconds before standby. If the standby happens in host mode that is with MCP2200 attached, there is no problem with interrupt mode transfers. It has to be noted that I keep the gadget file storage driver loaded when the device goes to standby with no USB device attached. If I do not load the file storage driver the problem doesn't seem to happen, the problem happens if serial gadget driver is loaded in place of file storage as well.

 

I am using Kernel 2.6.31 and HIDAPI over libusb to communicate to the HID interface of MCP2200.

 

Debugging the kernel USB stack has revealed that there could be a problem with scheduling the interrupt transfer slots.

[  162.608555] fsl-ehci fsl-ehci.1: reused qh fde05100 schedule

[  162.616086] usb 2-1: link qh1-3008/fde05100 start 0 [2/1 us]

[  163.246457] usb 2-1: unlink qh1-3008/fde05100 start 0 [2/1 us]

[  163.252503] usb 2-1: unlink qh1-0601/fde05080 start 0 [1/2 us]

[  163.260382] fsl-ehci fsl-ehci.1: reused qh fde05080 schedule

[  163.266094] usb 2-1: link qh1-0601/fde05080 start 0 [1/2 us]

 

When problem doesn't happen -

46[  163.429562] fsl-ehci fsl-ehci.1: reused qh fde05100 schedule

[  163.437102] usb 2-1: link qh1-3008/fde05100 start 0 [2/1 us]

[  163.444489] usb 2-1: unlink qh1-0601/fde05080 start 0 [1/2 us]

[  163.451301] usb 2-1: unlink qh1-3008/fde05100 start 0 [2/1 us]

[  163.459990] fsl-ehci fsl-ehci.1: reused qh fde05080 schedule

[  163.465702] usb 2-1: link qh1-0601/fde05080 start 0 [1/2 us]

 

The problem doesn't seem to happen while going to standby in host mode (with MCP2200 attached).

 

There is an observation that if we try bulk transfer instead of interrupt type transfer to the HID endpoint of MCP2200, it appears that MCP2200 is responding for the request with correct data. The endpoint is OUT interrupt endpoint of the HID interface. I am not sure if it is allowed to have this work around? The response is received in 18 milliseconds in bulk transfer mode.

 

It would really help if any information can be provided for the problem or if anybody has faced this issue? Any advice for performing bulk transfer to the interrupt endpoint of HID interface will also help.

 

Thanks,

Vinay.

Outcomes