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

[vinaybondade]

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.

[CarlosCasillas]

Hi Vinay,

There is an errata (ENGcm09460) where i.MX25 auto-resumes in host mode, so, it could be related. You could check additional details and the workarounds at the following document:

http://www.nxp.com/docs/pcn_attachments/16337_IMX25CE_Rev7.1.pdf

Besides, you could find other useful information regarding USB OTG module of the i.MX25 on the document and thread available at links below:

https://community.freescale.com/thread/316251

http://cache.freescale.com/files/dsp/doc/app_note/AN3683.pdf

Hope this will be useful for you.
Best regards!
/Carlos

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[vinaybondade]

Hi Carlos,

Thank you very much for your response.

errata (ENGcm09460) :

This errata gives information about enumeration failure, but since it says that this applicable in device mode only. I too felt this may apply to my problem and hence have tried the work around (both options) and it didn't help.

About enabling the OTG support:

This is our current settings for the OTG support -

[*] USB Support --->

     <*> EHCI HCD (USB 2.0) Support

            [*] Support for Freescale controller

            [*]       Support for Host2 port on freescale Controller

            [*]       Support for DR host port on Freescale Controller

            Select transceiver for DR port (Internal UTMI)   ---->

---    USB Gadget Support

        USB Peripheral Controller --->                

          ()    Freescale highspeed USB DR Peripheral controller

          ()    Renesas M66592 USB Peripheral Controller

          (X)  Freescale USB Device controller

          ()    Dummy HCD (Develpment)

     -*- OTG Support

From  the thread about enabling OTG support (how to enable OTG(as device function) in i.MX25 ) I am not sure if it has to be Freescale highspeed USB DR Peripheral controller or Freescale USB Device controller. Any information on this will be helpful to know that our current settings are right.

Errata BID2108:

I am not sure if this applies to my problem. The interrupt transfer delay appear to happen only after going to low power mode, before that the comms are fine.

The observation is that the problem happens only on interrupt transfers. The USB printer device also has a bulk endpoint, the USB bulk transfers after standby are working fine without any delays. Its another thought that if errata BID2108 was applicable it should apply to all USB transfers irrespective of interrupt transfer or bulk transfer otherwise the errata would highlight the periodic transfer type.

I'l be very grateful if you can provide any advice if it is possible to perform bulk transfers to an interrupt endpoint, it appears that the interrupt endpoint in my case is responding to bulk transfers and I'm not seeing any delays in bulk transfers.

Thanks,

Vinay

[CarlosCasillas]

Hi Vinay,

We tried to reproduce this issue in mx25 PDK board with USB mouse or USB DISK, but it didn't happened. However, we found a patch that you could try. You can find it as attachment.

Hope this will be useful for you

Best regards!

/Carlos

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

[CarlosCasillas]

Hi Vinay,

We are internally reviewing your case based on your last update, so, hoping to get a response soon. In the meantime, if you get additional test results or changes, please let us know.

Best regards!

/Carlos