AM5716: USB gadget link issue

Hi Ivan,

Does the issue always happen when connecting to H97 based hosts?

Can you please check whether the issue can be replicated with AM57x EVM?

Can you please share the USB portion of the schematics?

> Does the issue always happen when connecting to H97 based hosts?

Yes

> Can you please check whether the issue can be replicated with AM57x EVM?

It is complicated, since AM5728 EVM has USB3 only in host mode.

> Can you please share the USB portion of the schematics?

Yes, it is pretty simple:

OK, sorry, I simply forgot super-speed gadget port is not available on AM57x evm.

Is X8 pin 1 (VBUS) directly connected to 5V power rail? This USB1 port is in device mode, VBUS power comes from the USB host. So this VBUS pin should be fed into AM571x instead. You can refer to the design on AM571x IDK evm, in which VBUS pin from the USB receptacle goes into PMIC, then PMIC outputs it to a GPIO on AM57x. Kernel device tree has to be adjusted accordingly for the picked GPIO pin.

I am not sure if this hw mistake causes this compliance mode problem, but I am sure the host won't enumerate the gadget in super-speed every the other time even if you didn't have this compliance mode problem. And feeding 5V on VBUS from the gadget could potentially damage the USB host.

X8 pin powers the device, so VBUS feeds 5V. AFAIK it is common practice for bus powered devices.

On kernel side VBUS detection is managed via "linux,extcon-usb-gpio" node and dr_mode is set to peripheral.

I think that investigation made by Felipe Balbi should be elaborated to resolve this issue.

Okay, understood. The '5V' label for the X8 pin 1 is confusing, as I read it as a 5V power source.

Can you please check how USB_OTG kernel kconfig option is set?

# zcat /proc/config.gz | grep -w CONFIG_USB_OTG

If the output is "CONFIG_USB_OTG=y", can you please try to disable it in kernel config and rebuild the kernel to test again?

OTG is disabled:

# zcat /proc/config.gz | grep -w CONFIG_USB_OTG
# CONFIG_USB_OTG is not set

Hi Ivan,

Please capture a trace with your USB analyzer.

In the linux-usb mailing list email thread you mentioned, Felipe mentioned a few snps dwc3 driver quirks, have you tried them?

> Please capture a trace with your USB analyzer.

I will try to provide the trace a little bit later.

> In the linux-usb mailing list email thread you mentioned, Felipe mentioned a few snps dwc3 driver quirks, have you tried them?

Yes, I tried, but these quirks made no effect.

Hi, I haven’t heard back from you, I’m assuming you were able to resolve your issue. If not, just post a reply below (or create a new thread if the thread has locked due to time-out).  thanks.

No, the issue is still unresolved.

You can find the trace attached to this post. Regarding other questions - see my reply above.

compliance.csv

Unfortunately original file is pretty large (many large unknown packets, probably test packets from both sides). 750 MB in zip file. What is the best way to pass the file to you?

I accidentally marked your post as solution, could you please unmark it? I don't have any button to mark thread as unresolved.

Hi Ivan,

You only need to capture for a couple seconds for the enumeration phase, the data file is that huge? Sounds like something is wrong there. Please try to find a USB host which doesn't have a built-in USB hub. Typically the bus analyzer will capture the packets for all the hub ports. Or you can configure the analyzer to capture the usb traffic for the one hub port which AM57x is connected to, I don't know how to configure Beagle analyzer though, never used one.

Anyway, can you find a TI local FAE who can contact me for sending the file?

I don't have a way to mark the thread unresolved either. But don't worry, the thread status doesn't mean much, we will continue work on this issue until we have a closure.