Hi Alan, > On Thu, 19 Oct 2017, Lukasz Majewski wrote: > > > > > 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] > > According to the screen dump, the device sent a DATA1 packet which > the host controller did not ACK. That's a bug in the host > controller. In the next transaction, the device sent an empty DATA1 > packet instead of resending the previous data. That's a bug in the > device. > Ok. So then we do have HW issues in both sides :-). Nice... > > > 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.... > > That part is normal. Ok. > > > 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? > > Not in general. For this one particular case (a short transfer for a > Get-Configuration-Descriptor request), it would be easy enough to > retry the transfer. Just put a short retry loop around the second > usb_get_descriptor() call in usb_get_configuration() in > drivers/usb/core/config.c. But similar failures at other times would > be harder to recover from. This only one case. Those errors happens also at other parts of the enumeration phase -> very often also the "Get Report Descriptor" (178 bytes in size) is truncated. This is more severe, since those errors are propagated up the USB stack and exceed the "rule of thumb" of 4 retries set by Linus back at 2005 .... I'm now trying to force the code from ./usb/host/ehci-q.c qh_completions() to re-execute retry_xacterr. Unfortunately, it would be hard since CI Host Controller do not set "Halt" token status (bit 6) and some extra hacks are needed. @ Fabio, Peter, is there anybody from NXP, who can I contact to get some info regarding the way this IP block works (some IP block designer/ RTL implementor)? Maybe, I could get some hints on how to look for "reserved" registers? Or alleviating the HW problem on the CI HCI side? > > Alan Stern > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" > in the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html Anyway, many thanks for clarification. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
