USB3320 not able to detect the devicec connected

Hi
We have a custom board with RFSoC and USB3320.
The schematic almost similar to the evaluation board, ULPI IO voltage are 3.3V and ULPI Reset signal driven from MIO.
We observe any device connected to it, is not getting detected.
we observe this uboot:

  • ZynqMP> uINTERRUPT> ZynqMP> usb reset resetting USB… Bus dwc3@fe200000: Register 2000440 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus dwc3@fe200000 for devices… 1 USB Device(s) found scanning usb for storage devices… 0 Storage Device(s) found ZynqMP> usb tree.

We observe 60MHz CLKOUT from USB3320.
Any suggestions would be appreciated.

First there are nothing to do with PYNQ, second this is a learning topic.
I had more experiences on this chip as during our custom board build about ULPI we used the same chip.

This chip is real pain to the ass, the bottom pad if not solder well it will return -110.
If the reset state is not do in a good stage it will return -110
Make sure the power on pin is turning the DC-DC on or LDO on or Power-Gate whatever your design.
Meantime if any hub is attached to the 3320 make sure disconnect first and observe the ULPI chip is normal as this can cause additional problem to debug the 3320.

Those are my sharing, Enjoy ~

Hi briansune
I agree that this forum is only for PYNQ Produts. Thanks for your input.

If the reset state is not do in a good stage it will return -110 I didn’t understand what will return -110.
The CPEN of USB3320 is enable the Power switch and we see 5V at USB Connector.
But the device is not been able to detect.

If you have worked with USB3320, Could you be able to share if any waveform captured/reset timing for the 3320

Hi KLN
Are you operating the USB3320 as a root Host ? If so on the USB DP do you see the pull-up to 3.3V asserted?

The DP pull-up is what tells the host USB that a Full speed or High speed devices is connecting. This is the first step of the ‘USB Reset Sequence’

Chipmonk

When your board is loading the kernel there are series of dmesg about the USB.
Error -110 is the most common you can see from google that I am referring to.
If you need to debug to the hardware level aka waveform probing then it is really not smart.
The debug should go from top to bottom as top level is the easiest aka dmesg return log.
There are limited log info in here.

Hi Chipmonk
Yes It’s in Host mode
I’ll check the DP Lines

Hi briansune
I’ll keep you updated on log