USB3320 Device not able to detect with Zynq RFSoC - Page 1
Forum section: electronics / general

author: LakshmiN
author_rank: Contributor
timestamp: April 06, 2023, 08:26:52 pm
content: Hi,We are using USB3320 with Zynq RFSoC.We are facing an issue where USB devices not been able to detect.Attaching log:https://discuss.pynq.io/t/usb3320-not-able-to-detect-the-devicec-connected/4696https://support.xilinx.com/s/question/0D52E00007Bu0OQSAZ/i-am-not-able-to-detect-usb-storage-device-in-zynq-rfsoc-board?language=en_USVDDIO - 3.3VNote:Though USB3320 datasheet suggests VDDIO-1.8V/3.3V, In most of the design, I've seen reference boards using 1.8V as VDDIOIn our case, VDDIO-3.3VFrom Hardware point of view,Reset is happening, REFCLKOUT of 60MHz is observed. External CLKIN-26MHz OSCWhen we try to usb start operation, we do see, No USB Devices detected.I would appreciate valuable inputs.While USB reset/stop command, We do observe DM going low to high. No other transaction

author: LakshmiN
author_rank: Contributor
timestamp: April 07, 2023, 11:19:58 am
content: HiAwaiting for any feedback.

author: mon2
author_rank: Frequent Contributor
timestamp: April 07, 2023, 12:23:36 pm
content: Have you gone through the attached document?

author: LakshmiN
author_rank: Contributor
timestamp: April 07, 2023, 07:41:56 pm
content: Yes, I've gone through those documents already

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 07, 2023, 08:56:45 pm
content: It's really hard to say anything much as is. I suppose you have already checked the USB data lines with a scope, possibly an eye diagram, just to check signal integrity?I don't think VDDIO would matter one bitas long as it matches the logic level of the Zynq bank it's connected to. Are you sure it's indeed 3.3V?

author: LakshmiN
author_rank: Contributor
timestamp: April 08, 2023, 05:50:57 am
content: It is a USB 2.0Yes VDDIO is 3.3V and VDD is 1.8VReset is controlled from FPGA, and Reset sequence is as follows1. USB3320 IC is in initially reset(through pull down -reset)2. After FPGA is up, Reset will be driven high(1us)-low(5us)-high3. We observe IC out of reset, through CLKOUT of 60MHz as usb start command is given

author: tom66
author_rank: Super Contributor
timestamp: April 08, 2023, 11:26:28 am
content: With Zynq ULPI, be aware there is an issue with FSBL code where MIO is pulling up STP pin but USB3320 is pulling down. Result is STP pin is in unknown state and occasionally (1-20% of the time according to one Xilinx user) fails to init correctly. Maybe you are unlucky and it always fails.Solution: hold reset line low until kernel boots. That way, MIO state does not matter on boot.Or alternatively, modify FSBL code to set pull downs instead of pull ups on ULPI interface.Make sure reset is low until the oscillator input to the chip is stable (not sure if this matters with xtal).

author: LakshmiN
author_rank: Contributor
timestamp: April 09, 2023, 02:36:23 am
content: Hi1. We have tried making MIO states low in vivado2. Reset is low by default and only at psu initialization psu_init, reset is pulsed and kept highSolution: hold reset line low until kernel boots. That way, MIO state does not matter on boot. --this we will try and let you know

author: tom66
author_rank: Super Contributor
timestamp: April 09, 2023, 12:52:22 pm
content: Just remember you need to release reset at the moment that kernel tries to init USB controller. Otherwise ULPI self test will fail. (I believe if it's the same chipidea controller, it writes 0x55 and 0xaa to the scratch register and reads back the value each time. If either fails, controller is assumed bad and no USB init.)We just did it by timing how long u-boot took which is very consistent, but you might want to configure u-boot to strobe a GPIO when it hands over to kernel for instance. Our system has a small PIC which handles booting the FPGA and other things which has allowed us to handle all sorts of Zynq glitches and bugs with just software changes.There's a kernel flag you can turn on in your build as well for extra USB debug which might reveal the cause of issues.

author: LakshmiN
author_rank: Contributor
timestamp: April 10, 2023, 03:58:20 am
content: Hi @tom66If it's taken care in Zynq MIO i.e., MIO(ULPI all signals) pins are default pull down, Do we need special take care of this releasing the reset of when kernel tried to init USB Controller?Or only for MIO's are pulled up case?We also have another designed board, where ULPI Signals 1.8V level i.e., VDD and VDDIO of USB3320 is 1.8V, It works seamlessly, without reset control from Zynq IO. Even in there MIO's are default pulled up. We don't have any issues.Where as in our case, VDD-1.8V and VDDIO is 3.3V. We have issues here.

author: tom66
author_rank: Super Contributor
timestamp: April 10, 2023, 11:53:53 am
content: I couldn't say for sure if VDDIO is causing your issue, but if there is a pull up/down conflict then it might behave differently. We have had 3.3V VDDIO ULPI cause issues on Zynq boards.You should have the reset released when oscillator is stable and MIOs are in a defined state, which should be the case after u-boot has completed. If you are using the internal xtal oscillator, then you don't have a choice on when you release reset for the oscillator, but you can still make sure you release it when the MIOs are in a well defined state.

author: LakshmiN
author_rank: Contributor
timestamp: April 11, 2023, 03:27:09 am
content: so after u-boot, can we drive the gpio through this?https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842147/U-Boot+GPIO+Driver

author: tom66
author_rank: Super Contributor
timestamp: April 11, 2023, 07:59:45 am
content: I couldn't tell you for sure as I'm not intimately familiar with u-boot.Does the Zynq have access to the reset pin of the USB chip?

author: LakshmiN
author_rank: Contributor
timestamp: April 11, 2023, 08:43:56 am
content: Hi tom66Does the Zynq have access to the reset pin of the USB chip? : Yes, One of MIO64 is connected to the USB Chip resetWe have tried two cases with the default MIO pull from VIVADOCase1: Kernal loads normally but usb devices are detected after 2-3 mins Note: No reset of usb IC during kernel loading.For this case I've attached logsAs you can see, For usb detetction, It takes few durationCase2: Before Kernel, in U-boot usb reset command is initiated and kernel boots, In this case, USB devices are not detected at allFor Both the case, In ps_init (At PS initialization) USB chip reset is pulsed and usb chip is out of resetWe are yet to try the MIO pins default low from Vivado. We will let you know.

author: tom66
author_rank: Super Contributor
timestamp: April 11, 2023, 10:49:25 am
content: You of course need to release the reset before the kernel tries to initialise USB.However it sounds like your USB3320 is working (as in, the ULPI communications are okay) but there is some other issue with USB, like a signal integrity issue.If you have access to a 500MHz+ oscilloscope you can attempt to probe the ULPI signals and see if those are OK. If you have a 1GHz+ scope then you can look at the raw USB signalling layer. You could also try with an old USB hub that only supports USB 1.1, I still keep one around, it forces the USB interface into low/full speed configuration which removes a lot of the USB layer signal integrity issues.You can also try writing a baremetal program to read and write the ULPI scratch register or if you deregister the ULPI interface from the devicetree you can do this from userspace as root. Here is a quick example, you will need to modify it to work:Code:#define ULPI_BASE0xe0002000#define ULPI_VIEWPORT_OFFS0x170#define ULPI_VIEWPORT_ADDR(ULPI_BASE + ULPI_VIEWPORT_OFFS)#define ULPI_SS(1 << 27)#define ULPI_RWCTRL(1 << 29)#define ULPI_RWRUN(1 << 30)#define ULPI_WU(1 << 31)/** Wake the ULPI PHY up for communication** returns 0 on success.*/int ulpi_wakeup(){int err;if (readl(ULPI_VIEWPORT_OFFS) & ULPI_SS)return 0; /* already awake */writel(ULPI_WU, ULPI_VIEWPORT_OFFS);err = ulpi_wait(ULPI_WU);if (err)printf("ULPI wakeup timed out\r\n");return err;}/** Issue a ULPI read/write request** @value - the ULPI request*/int ulpi_request(uint32_t value){int err;writel(value, ULPI_VIEWPORT_OFFS);err = ulpi_wait(ULPI_RWRUN);if (err)printf("ULPI request timed out\r\n");return err;}int ulpi_write(uint8_t reg, uint32_t value){uint32_t addr = (uintptr_t)reg & 0xFF;uint32_t val = ULPI_RWRUN | ULPI_RWCTRL | addr << 16 | (value & 0xff);return ulpi_request(val);}uint32_t ulpi_read(uint8_t reg){int err;uint32_t val = ULPI_RWRUN | ((uintptr_t)reg & 0xFF) << 16;err = ulpi_request(val);if (err)return err;return (readl(ULPI_VIEWPORT_OFFS) >> 8) & 0xff;}`writel` and `readl` are found in kernel source, but essentially just raw read and write at memory address by mmap of /dev/mem. This is based on the kernel driver for the chipidea controller, but ported over for userspace as kernel can write addresses directly but sudo userspace needs to use /dev/mem to write private memory as it is still protected. Obviously I do not recommend this for production use, but it is okay for testing.The scratch register is at 0x16 you should be able to write a value to this and read it back and on the scope you will see ULPI activity on each of these operations.Note.... I do not know if you are using chipidea ULPI or not. If you have an AXI USB controller, you would need to change addresses etc. Same if you have a different ULPI driver or USB3.0 etc.

author: LakshmiN
author_rank: Contributor
timestamp: April 17, 2023, 05:17:43 pm
content: HiWe tried with MIO pins pulled down aswell,Even in both Kernel and U-boot, USB Devices were not getting detectedOnly in case of MIO pulled up, in kernel it was getting connected with JTAG connected. when jtag was removed, we observed that USB devices were not detectingIt was flashed and booting from QSPI

author: LakshmiN
author_rank: Contributor
timestamp: April 17, 2023, 05:19:36 pm
content: " There's a kernel flag you can turn on in your build as well for extra USB debug which might reveal the cause of issues. "Could you also guide me to an example how to implement of kernel flags to see cause of issue?

author: tom66
author_rank: Super Contributor
timestamp: April 17, 2023, 10:18:26 pm
content: Unfortunately I don't build kernels myself so I don't know for sure, but it relates to the extra debug you get in the kernel log. At a guess something related to this...https://www.kernel.org/doc/html/v4.15/admin-guide/dynamic-debug-howto.htmlOur kernel engineer (we use a contractor for this work) just turned it on by request.If the USB doesn't work until JTAG is connected, that is very strange. Suggesting some serious hardware issue or signal integrity problem.Is this a custom board or bought in dev kit etc? If custom, have you checked ULPI length matched lines, and do you have a series ULPI_clock resistor? Is the USB D+/D- routed 90 ohms differentially and not crossing ground planes?

author: LakshmiN
author_rank: Contributor
timestamp: April 18, 2023, 04:52:53 pm
content: Hi,Yes, It's a custom board.We have series clock termination resistor at ULPI_CLKULPI signals are length matched, I'll confirm the lengths within which are matched.Yes D+/D- are differentially routed.You said-" not crossing ground planes?" This means no split ground planes right. if that is the question, Then yes, there is no split ground planes where the usb signals are routed

author: tom66
author_rank: Super Contributor
timestamp: April 18, 2023, 04:56:21 pm
content: Quote from: LakshmiN on April 18, 2023, 04:52:53 pmYes, the USB track should be ideally only on one continuous ground plane. A common error I see is routing it across an analog ground plane or similar, which creates an impedance discontinuity at that moment. If your board only has one plane then you can't make this error.What value did you use for the ULPI clock resistor? Have you any way to measure the performance of the signals at the USB3320 end - you would need 500+ MHz scope.

author: asmi
author_rank: Super Contributor
timestamp: April 18, 2023, 05:05:02 pm
content: Quote from: tom66 on April 18, 2023, 04:56:21 pmULPI runs at 60 MHz, which is not that fast, so you've got to seriously screw things up for routing to become a problem.

author: tom66
author_rank: Super Contributor
timestamp: April 18, 2023, 07:20:37 pm
content: Quote from: asmi on April 18, 2023, 05:05:02 pmThat's true. I'm running out of ideas here to be honest - it's a strange issue.

author: asmi
author_rank: Super Contributor
timestamp: April 18, 2023, 07:43:14 pm
content: Quote from: tom66 on April 18, 2023, 07:20:37 pmSame here. Unless OP is willing to post at least partial schematics which shows all connections around USB PHY, I can't think of anything else at this point. Searching Xilinx forums for USB3320 does yield some weirdness, but I'm not really sure what to make of it, as my experience with Zynq is very limited (and none whatsoever with Zynq MPSoC as they are too damn expensive!).

author: LakshmiN
author_rank: Contributor
timestamp: April 19, 2023, 10:19:08 am
content: HiPlease find the attached Schematic of USB3320 with FPGA (RFSoC)and ULPI Trace length attached detailed

author: tom66
author_rank: Super Contributor
timestamp: April 19, 2023, 01:27:31 pm
content: I see you are using mixed USB3.0 / USB2.0 interface solution. Is USB2.0 always failing to initialise, or is this solution only an issue with USB3.0 devices?Have you ensured section 5.5.3 in USB3320 datasheet is obeyed - VDD1V8 *must* be available before or at same time as VDDIO.

author: LakshmiN
author_rank: Contributor
timestamp: April 19, 2023, 05:53:31 pm
content: Hi Tom66Yes we are using USB 3.0 also,But as of now, USB 3.0/Super speed signals not initialized in device tree. Only concentrating with USB 2.0Yes, In design we have made sure that VDD 1V8 will come first and then VDDIO 3.3VI had also attached the PCB trace lengths in mils, Please look into them once.

author: tom66
author_rank: Super Contributor
timestamp: April 19, 2023, 09:32:40 pm
content: Trace lengths ~4.7" total, and DATA7 seems oddly shorter than the rest. Overall, the bus is longer that I would want. I have heard a general rule of 2" / 5cm max for ULPI unless you really know what you are doing.The biggest headache with ULPI and longer trace lengths would be the lane turnaround scenario where the FPGA transmits against the clock supplied by ULPI transceiver. So total latency would be ~10" PCB track, or approx 1ns, clock period of 60MHz is ~16ns, so I suppose it is possible it could slightly marginalise your setup or hold time. However this is just a guess, I am not intimately familiar with the ULPI standard at the physical layer. You would be able to test this using an oscilloscope, but as mentioned it needs to be fast enough so that the bandwidth of the scope does not limit your measurement. Also, it is possible at such long trace lengths that the impedance matching of the interface becomes more of a problem. The general rule for impedance matching is that your line should be matched if the maximum wavelength exceeds 1/10th the length of track. You are right up against that limit, especially if you consider referencing to a clock from the ULPI receiver.Edit: clarification

author: asmi
author_rank: Super Contributor
timestamp: April 20, 2023, 12:35:47 am
content: I didn't see anything obvious on a schematics, the only thing I can't check is if SoC pinout is correct, please double-check your MIO config to make sure it matches what you have on a board.

author: LakshmiN
author_rank: Contributor
timestamp: April 20, 2023, 07:10:12 pm
content: "I have heard a general rule of 2" / 5cm max for ULPI unless you really know what you are doing." --- I've seen in ZCU216 evaluation board trace length upto 6" inches.SoC Pinouts are correct

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 20, 2023, 07:34:51 pm
content: To get setup or hold time issues at 60MHz you would need to seriously screw up the routing. If you couldn't get this right, I wouldn't want to see what you've done with your DDR RAM.

author: AndreZheng
author_rank: Contributor
timestamp: April 21, 2023, 12:30:10 am
content: Is the 5V VBUS on J7 header available or not?

author: LakshmiN
author_rank: Contributor
timestamp: April 21, 2023, 03:27:14 am
content: Yes, At J7 USB connector 5V is available

author: Anand Ram
author_rank: Newbie
timestamp: June 17, 2025, 12:17:35 pm
content: Hi LakshmiN,Could you please let us know if you were able to resolve the USB issue?We are currently facing a similar problem on our custom MPSoC board, where we are unable to bring up the USB 2.0 and 3.0 interfaces.As you mentioned in your earlier communication, we have also connected a 3.3V I/O for the ULPI interface.We would greatly appreciate your assistance in helping us resolve this issue.

author: CMPXCHG8B
author_rank: Newbie
timestamp: June 18, 2025, 09:07:42 am
content: A few more things to check:The USB332x ULPI PHY datasheet states the USB332x REFCLK is tolerant to jitter on the reference clock, with a peak jitter of less than 1 nS over a 10 uS time interval. If your 60 MHz clock comes from a PLL this should be checked first, and phase noise of that clock should be checked on spectrum analyser and reduced as much as possible by configuring it, its loop filter, and selecting an appropriate source clock.The USB bus reset sequence initiated by the USB host/software-controlled downstream hub port might be of influence. The upstream port of the USB hub also has to be gone through such USB bus reset sequence.Using an old-but-compliant USB 1.1 hub or very legacy PC USB, should not perform the chirp-K bus speed negotiation cycle, ignoring the high-speed chirp, and thus might lead to a more straighforward initialisation.The exact levels and length of the USB bus reset initiation can be checked, with dual probes and a simple trigger circuit.Unfortunately hardware USB bus protocol analyzers like these from Ellisys will not show you these timings (relative to their 60 MHz PHY clock), but a scope can do this. The ellisys protocol analysers do have a programmable trigger output GPIO that allow you to grab the sequence. There are even some counters in case the host re-tries the bus reset sequence, with different timings or signal levels.