Hi Alan, Thank you for you reply. > On Wed, 18 Oct 2017, Lukasz Majewski wrote: > > > 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. > > I don't know anything about the iMX6q specifically... But you do know a lot about EHCI/USB.... :) > > > Board: Wandboard rev1b / some custom board > > SW: Mainline Linux 4.13 > > > > Problem: > > > > I do observe that the USB transfers are truncated - for example > > "Get Configuration Descriptor", which length is 34B only gets 16B > > from the device. > > > > I do get the "Invalid PID sequence" error and despite the > > How do you know the error is "Invalid PID sequence" and not something > else, like CRC error or timeout? I'm using TotalPhase USB 480 Analyzer. It shows only "Invalid PID sequence" as the error. When I "unroll" the GetConfigurationDescriptor, then all data is the same as for correct transmission. > > > DATA1 Packet received by host - the EHCI controller is not sending > > ACK. > > The DATA1 packets are the ones containing bytes 9-16, 25-32, and so on > (low speed always uses maxpacket size = 8). Since you received 16 > bytes, this means the host controller accepted the DATA1 packet but > didn't send an ACK -- that certainly would be a hardware bug. I do receive 16B, but those are "comprised" of two separate IN transactions (8 B each). One such transaction is built with SETUP -> DATA1 -> ACK packets. [Please see the attached screen] > Anyway, > this should have caused the device to retransmit the DATA1 packet in > response to the next IN packet (if there was one). There is IN packet sent afterwards, but it is empty. The whole GetConfigurationDescriptor ends with OUT ZLP.... > > > The problem is not observed when I plug the touchscreen device via > > USB 2.0 HUB. (iMX6q -> USB 2.0 HUB -> touchscreen) > > > > Also, the problem is not present on different EHCI implementations - > > namely Intel or Synopsis (Exynos 5422). > > > > > > 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 > > This is the Setup transaction, which completed normally. > > > [ 1.988809] qh_completions: urb token 0x920d08 0 178 > > ^--- here we do have still > > active "status" 9x8 > > No, 0x08 in the low-order bits is XactErr. Active would be 0x80. Ach... right. > Notice, however, that the CErr field was not decremented. According > to the EHCI spec, that should not happen. Another hardware bug? Good point. > > Notice that the Halted bit was not set. This means the hardware > thinks the transaction completed successfully. Unfortunately, it does. It behaves like everything went correct and pases truncated data up to the stack. > > > [ 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.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 > > > > > > 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. > > The host controller driver doesn't report an error because the Halted > status bit isn't set. XactErr by itself isn't a fatal error; it means > that something went wrong but then the transaction was retried. No retry from the touchscreen IC. It seems like we do have HW bugs on both sides.... (EHCI ChipIdea Implementation and the touchscreen IC - ssd2533) > > > Have anybody had similar problem? > > > > Any hints on how to proceed? > > It does sound like a hardware bug. But you should get more > information from people who know more about iMX6q. I hope that the NXP community will respond promptly. I'm wondering if it is feasible to manually check the XactErr bit and then for example order the soft USB reset (from the root hub)? Or is there any other acceptable in upstream solution? > > > The problem has been described in detail (including screen shots > > from USB analyzer + some further investigations) here: > > https://community.nxp.com/thread/462409 > > I didn't see any screen shots or further investigations on that web > page. I've double check it. It is under "moderation". Hence, I've attached the screenshot to this reply. > > Alan Stern > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@xxxxxxx
Attachment:
imx6q_low_speed_problem.png
Description: PNG image
