USB host port sometimes unpowered after boot

[aolofsson]

When booting, the enable signal for the USB switch sometimes fails to go high after resert, so there is no power fed out of the Parallella USB port. (thus no way to connect unpowered peripherals).

Since we are only using the Parallella in host mode, is there a way to force the USB phy to always assert this signal high after reset? Or perhaps some other workaround?

[aolofsson]

Raising priority to high. We are seeing 4-5 people with issues right now.
Andreas

[kgugala]

We did some investigation and the results are:

When the system is starting linux kernel tries to detect USB phy and if this detection fails it will never retry it after boot is finished.

We noticed that if during booting process we had long cable (about 80 cm) connected to USB port the phy was always detected w/o problems. It may be only USB extension cord without any device at the end to get the phy working. Without it or with short (10 cm) micro USB to type A adapter we often had problems with proper detection of the USB phy. We have theory that long cable somehow dampens the jitters on the USB lines, thus it can start without problems.
Notice that on the Zedboard there are additional shotky diodes connected to USB lines to do the jitter filtering.

Please try running your boards with longer cable attached to USB and give us feedback if you notice similar behavior.

[aolofsson]

Karol, Thanks!! This is very interesting, we'll check.
Questions:
-Why would this noise cause the "EN" signal to stay low and not power the VBUS. There is an output signal from the USB phy that enables the USB power switch. Is there a way for us to force this to always stay on? Wondering if there is a timing race between this signal going high and the driver looking for devices on the USB port.
-Is there a way to disable OTG and just have it in host mode as a trial.
-Does this happen with a powered hub as well?

[kgugala]

IMO, the "noise" prevent the phy from being properly detected and initialized by software, thus the "EN" signal is not driven. I don't think if there is possibility to force this to always stay on, since the phy is not even detected. I will look at it.

Right now we are forcing host mode.

I was using it with powered hub with long connecting cable and everything was working fine. If I find some hub with short cables I will test it and give you feedback.

[kgugala]

I've tested USB with powered hub and short cable i sometimes it remains unpowered after boot. Only cable length influences USB phy detection.

[aolofsson]

karol, can you help me understand the situation?
I understand that the theory is that there is some noise on the USB line and that this could be causing issues with the driver. Some questions:
-How does the noise cause the driver to not initialize
-Do you have a debug dump that gives more information from the USB driver
-What happens if nothing is plugged into the USB port at boot?
-Where is the host mode only set? FSBL/U-boot/Linux
-Can we try to remove the U13 switch and shorting VBUS to SYS_5P0V?

[kgugala]

Yes, IMO there is some noise on the USB lines that in some way prevents USB phy (ULPI) from being properly detected during powerup, thus init procedure do not even start because Linux do not finds ULPI.

I don't know exactly how the noise influences ULPI chip, but somehow it prevents it from being detected. Maybe the device hangs due to some jitters.

If the ULPI is not detected in the Linux log we have only:

ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
xusbps-dr e0002000.usb: Unable to init USB phy, missing?

otherwise

ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ULPI transceiver vendor/product ID 0x0424/0x0007
Found SMSC USB3320 ULPI transceiver.
ULPI integrity check: passed.

If there is nothing plugged into the USB port at boot it tends to fail. Only plugging long cable improves the situation.

The host mode is set by the Linux - it is forced in devicetree. The U-boot do not even touch USB. FSBL only configures internals Zynq's clock generators and enables ehci-hcd.

Forcing 5V to USB power line do not change anything if the ULPI is not detected. Lack of voltage on the USB line is the effect of failure, not the cause.

We have theory that adding shotky diodes to the USB lines it may improve the stability of the device. We will design and assembly small PCB that could be attached to USB port - it will act as adapter and will provide additions stabilization on those lines. Of course it will take some time to produce and test it but it may help.

[Fred3]

I'm able to confirm this behavior on one board I have but another works all the time.

Not sure if this helps, see last two messages in this thread:
http://forums.xilinx.com/t5/Embedded-Linux/14-4-USB-not-working-any-more/td-p/287579

[aolofsson]

We have not seen any stability issues during normal operations, only this initialization issue. I noticed the general file does not use the GPIO. Not sure if this has any effect since we are not using the GPIO? Interfering with other things? Can you try recompiling the kernel with the updated driver from Xilinx to see if it improves things? Also, please see the following issue:

https://github.com/Xilinx/linux-xlnx/issues/19

parallella-linux-adi/drivers/usb/host/xusbps-dr-of.c

https://github.com/Xilinx/linux-xlnx/blob/master/drivers/usb/host/xusbps-dr-of.c

[kgugala]

I've checked the board with reset pin attached to the ULPI chip and resetting code in the driver and still USB phy tends to hang during bootup. Only attaching long cable or adding additional ESD protection stabilizes the device.

[aolofsson]

Can you help us understand the relationship between the fsbl, uboot, and linux when it comes to the USB (otg vs host mode). Are we sure that there are not some things in the fsbl that could affect behavior. For example, should we try with 14.7 to see what happens in case there is some inter relationship between the uboot and linux.
Can we try updating uboot to check improvements?
It seems that there is a reset issued during fsbl (see link).
I am wondering if this isn't too early?
http://www.digilentinc.com/Data/Products/EMBEDDED-LINUX/Digilent_Embedded_Linux_Guide.pdf

[kgugala]

FSBL configures clock and basic features of the CPU. Now in 14.7 if USB is configured to reset the ULPI via GPIO the FSBL does it by setting '0' and then '1' on this output. The old version (the one implemented in official parallella binaries) does not reset the USB.

U-boot do not use USB and do nothing with it. However U-boot that we are using resets the ULPI during startup using GPIO but nothing else.

Linux kernel configures and enables USB and ULPI. It reads configuration from the device tree and configures USB subsystem to be host or device according to it.

Note that the reset pin has to be physically connected to the ULPI chip to enable resetting the chip by the software (FSBL, U-boot and Linux). On the parallella board this pin is not connected to the Zynq GPIO, thus software cannot reset the ULPI (the code has no affect). However on one of the boards I have I connected the reset pin to the proper GPIO pin, enabling ULPI resetting, but it does not change the behavior of the USB - as I wrote before.

We can update the U-boot to the newest version provided by Xilinx, but it IMO won't fix the USB, because there is no code doing anything with USB in it. Note that updating the bootloader may cause some problems with other peripherals. Actually I noticed strange behaviour of the UART in newest U-Boot on the Zedboard.

[aolofsson]

Thanks for the explanation..makes sense. This is what one of the engineers came back with from Xilinx. He said he tested it and it worked? Can you verify?

In your kernel device tree you would have:

usb@e0002000 {
compatible = "xlnx,ps7-usb-1.00.a";
reg = <0xe0002000 0x1000>;

interrupts = <0x0 0x15 0x4>;
interrupt-parent = <0x1>;
clocks = <0x2 0x1c>;
dr_mode = "host";

phy_type = "ulpi";
xlnx,phy-reset-gpio = <0x4 0x55 0x0>;
};

This changes to (note the phy_type field):

usb@e0002000 {
compatible = "xlnx,ps7-usb-1.00.a";

reg = <0xe0002000 0x1000>;
interrupts = <0x0 0x15 0x4>;

interrupt-parent = <0x1>;
clocks = <0x2 0x1c>;

dr_mode = "host";
phy_type = "";

xlnx,phy-reset-gpio = <0x4 0x55 0x0>;
};

Rebuild the devicetree/kernel and give it a boot. You will no longer see a phy id/etc message in the boot log, instead it should just look like:

ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
xusbps-ehci xusbps-ehci.0: Xilinx PS USB EHCI Host Controller
xusbps-ehci xusbps-ehci.0: new USB bus registered, assigned bus number 1
xusbps-ehci xusbps-ehci.0: irq 53, io mem 0x00000000
xusbps-ehci xusbps-ehci.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage

[kgugala]

I checked this suggestion and it turns out that it works sometimes. Sometimes the USB won't work even with long cable (which is worse than with "normal" devicetree). The log always looks good - even if USB is not working after boot. This may be problematic because if you end up with not working USB you don't have any info what went wrong.

[aolofsson]

Thanks!
Is this done on a board wit the U13 removed?
What is the success with pushing the reset button using this driver setup?

[kgugala]

Pushing the reset do not change the behavior - sometimes it works after reset sometimes not.

I was testing it with U13, as I do not have the board with it desoldered. The lack of voltage on the lines is caused by improper work of the ULPI, if we hardwire VBUS to SYS_5P0V it won't change anything because the PHY will still be hanging and will be unable to talk with the usb devices - even if they will be powered all the time.

Note that ULPI tends to hang with or without USB device connected to the port - so forcing power on the lines IMO will not impact this issue.

[tony-gh0]

Hi.
Four years later. I hope this is still being monitored. I have a similar if not exact same problem.
Please provide the exact solution that worked for you. i.e. part number of ESD devices? Was the Xilinx suggested change part of the fix?
Thanks

[kirbyjason]

@tony-gh0, feeling the pain. Digikey has delivered and I got mine assembled and put in an aluminum box within the last two days and the first thing I noticed was more often than not, the micro usb does not work. Too bad this issue wasn't solved before Adapteva closed doors.