iMX6q - Problem with Low-speed device

[lukaszmajewski]

Dear All,

I'm using iMX6q for my application. It uses the touchscreen IC connected via USB port (Host port 1). The touchscreen operates with low-speed.

Board: Wandboard rev1b

SW: Mainline Linux 4.13

Problem:

I do observe that the USB transfers are truncated - for example

"Get Configuration Descriptor", which length is 34 only gets 16B from the device.

I do get the "Invalid PID sequence" error and despite the DATA1 Packet received by host - the EHCI controller is not sending ACK.

The problem is not observed when I plug the touchscreen device via USB 2.0 HUB.

Also, the problem is not present on different EHCI implementations - namely Intel or Synopsis.

Have anybody had similar problem?

Thanks in advance,

Łukasz

[lukaszmajewski]

Maybe a bit more information:

1. The issue is also observed on other iMX6q board

2. The design uses OC and USB PWR dedicated pins (pinmux'ed to this dedicated function) to monitor VBUS

3. The touchscreen is powered from VBUS (from USB). The power supply quality has been checked with the oscilloscope - no distortion

4. The packet truncation also happens when USB analyzer do not show "Invalid PID sequence" error

5. The truncated packet, when compared with the correct one has the same binary data.

6. The problem is not seen with "no name" USB low-speed mouse - but it sends far less data (up till 66B), and it is correct for it to receive 4/46B of 255B descriptor data.

Please find screenshot from USB analyzer:

The most _strange_ issue here is the lack of _any_ error indicated by the HOST driver. All transmissions end

with USBINT set. No error interrupt present. This corrupted data (with smaller size than expected) is then

passed to upper layers, causing subtle errors.

Please find below some data dump from EHCI's qTD (Queue Element Transfer Descriptor):

[ 1.987479] ci_hdrc ci_hdrc.0: submit_async 1 urb edfe6e80 ep0out len 178, qtd ef061180 [qh edfe6780]
[ 1.988781] ehci urb: IRQ status: 0x1 INTREN: 0x37 hrt: 0x80
[ 1.988795] scan_async: urb qh: 0xedfe6780 qtd_list: 0xef0610f8
[ 1.988802] qh_completions: urb token 0x80000e00 0 178
[ 1.988809] qh_completions: urb token 0x920d08 0 178     <- here we do have still active "status" 9x8
[ 1.988815] qh_completions: urb token 0x8c00 32 178       <- here the IOC bit is set (0x8)
[ 1.988828] ci_hdrc ci_hdrc.0: ehci_urb_done 1 urb edfe6e80 ep0in status 0 len 32/178

The above code is executed after receiving "USBINT" interrupt - according to EHCI controller everything went fine........ [1]

[ 1.992192] ci_hdrc ci_hdrc.0: submit_async 1 urb edfe6e80 ep0out len 178, qtd ef061060 [qh edfe6780]
[ 1.995785] ehci urb: IRQ status: 0x1 INTREN: 0x37 hrt: 0x80
[ 1.995804] scan_async: urb qh: 0xedfe6780 qtd_list: 0xef0611b8
[ 1.995811] qh_completions: urb token 0x80000e00 0 178 <- setup transaction
[ 1.995819] qh_completions: urb token 0xd00 0 178           <- here we do have 0x0 status
[ 1.995825] qh_completions: urb token 0x8c00 178 178     <- here we do ask for interrupt when done
[ 1.995840] ci_hdrc ci_hdrc.0: ehci_urb_done 1 urb edfe6e80 ep0in status 0 len 178/178

This above debug output is for correct transmission (178B received).

Can somebody explain me why on [1] we do have the USBINT interrupt despite of not ACK'ed transfer?

Why the EHCI Host controller sends ZLP packet to end transaction, which was NOT ACK'ed?

The analyzer shows "PID error" - but qTD's token's "Error Counter (CERR)" is not changed. 

Is there any workaround/fix for presented above problem?

Just a side question:

Are there any other debugging registers for ChipIdea's EHCI implementation? 

Appendix C. from https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/ehci-specifica... 

mentions about such registers. Are those available in iMX6q?

Thanks in advance for your help,

Lukasz

[CarlosCasillas]

Hi Lukasz,

If you refer to the Release Notes document of the official Linux BSPs for i.MX6Q, you could check which USB drivers are included for Host, Device and OTG operations.

As you are using a non-official Linux release (4.13), and a 3^rd party board, you should refer to Wandboard support, and/or checking their forum at the following link:

http://forums.wandboard.org/

If your touch screen uses HID class, the HID Host support is included with the official BSPs for i.MX6Q; however, if it requires a custom driver or a specific data transmission, it should be developed by separate. You could also consider the NXP Professional Services for this implementation:

https://www.nxp.com/support/support/nxp-professional-services:PROFESSIONAL-SERVICE

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!
-----------------------------------------------------------------------------------------------------------------------

[lukaszmajewski]

Hi Carlos,

CarlosCasillas wrote:

Hi Lukasz,

If you refer to the Release Notes document of the official Linux BSPs for i.MX6Q, you could check which USB drivers are included for Host, Device and OTG operations.

As you are using a non-official Linux release (4.13), and a 3^rd party board, you should refer to Wandboard support, and/or checking their forum at the following link:

http://forums.wandboard.org/

The issue with the malfunctioned transmission between those two devices is visible on at least two boards powered by iMX6Q.  And yes - I do prefer mainline HEAD linux.

If your touch screen uses HID class, the HID Host support is included with the official BSPs for i.MX6Q; however, if it requires a custom driver or a specific data transmission, it should be developed by separate. You could also consider the NXP Professional Services for this implementation:

https://www.nxp.com/support/support/nxp-professional-services:PROFESSIONAL-SERVICE

The problem is during enumeration phase - this shall be provided by internal host controller state machine and some generic SW. When the enumeration phase is OK, then the data is correctly received by the HID driver.

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!
-----------------------------------------------------------------------------------------------------------------------

Best regards,

Łukasz

[richard_stulens]

Hi Lucasz,

What you see in the trace is that the host controller starts an IN transaction to which the device replies with an 8-byte packet with DATA1 data toggle. The Host does not ACK the packet, which means that it saw an error (CRC or other). The host starts a new IN transaction (this is an automatic retry) to which the device responds with DATA1 toggle, but a zero length packet. This is an incorrect response from the device. It should have sent the previous packet again because it dd=id not receive an ACK. The device stared correctly by sending DATA1 toggle, indicating it was repeating the packet, but instead of repeating, it sends ZLP, which means that the transaction is completed. The host ACK's the ZLP and will not try to read more data.

When the host received the ZLP, the CERR counter was also restored to 3 since CERR must be restored when a packet is received correctly from the given endpoint (or by the endpoint in case of OUT transactions).

Regarding the urb and qTD, please note that the qHead overlay area is the workspace for the controller. The qTD will only be updated with the qHead data after the transaction is completed. So for that specific IN transaction I expect the XactErr bit to be set in the status of the qTD.

[ 1.988809] qh_completions: urb token 0x920d08 0 178     <- here we do have still active "status" 9x8

In the log entry above is an IN transaction, but it is not yet completed (active bit is set) and thus the status is not yet updated.

I hope this clarifies the issue.

Best regards,

Richard

[lukaszmajewski]

Hi Richard,

Thanks for in-depth answer.

I do agree that the touchscreen IC firmware is not complying with the USB standard (specs says that it is USB 1.1, but works as low-speed).

However, I cannot do much with it.

Other thing puzzles me - when I connect this touchscreen device to EHCI from other vendors (not iMX6Q) - like Intel in my PC or EHCI from Samsung (Odroid XU3) there is no need to re-try the transmission - the above error is not present.

Hence, I'm wondering if there are any ways to check why the ChipIdea Host controller receive those errors? Maybe some kind of "extra"/"reserved" debugging registers are available? I'm curious why those errors pop up in iMX6Q (low-speed) mode and not in EHCI from other vendors.

Initially, I thought that this error may be caused by routing of my board - but the same behavior is present on Wandboard Quad rev. 1b board.

What is even more strange - when I connect the touchscreen via USB 2.0 HUB (with NO external power provided) to iMX6Q it works without errors.

I'm also 100% sure that there are no distortions on the VBUS and the VBUS is enabled very early (to power up the PHY). Moreover, I do wait ~300ms between enabling the regulator and proceed with CI Host Controller initialization (this is the delay needed for touchscreen IC to be initialized).

With or without this delay - errors happen anyway.

Thanks in advance,

Łukasz