USB workaround

Hardware related problems and workarounds

Re: USB workaround

Postby FHuettig » Sat Jul 26, 2014 7:13 am

leon_heller wrote:Launchpads are a family of boards made by TI for their MSP430 and ARM Cortex devices. I don't see how they are relevant to this discussion.


Sounds like Frida used a launchpad board to implement a delay between the release of the Zynq's reset and the release of the reset signal that goes to the USB PHY (and the ethernet PHY as well, but that shouldn't matter).

30ms might be doable with just a cap on the BOARD_RESET_L net, though the slow risetime could cause other problems. Anyone want to try a 47uF cap between BOARD_RESET_L and ground, e.g. pins 3 and 4 of U33? This is an experiment I've been meaning to try, but I didn't know how long the delay might have to be. Frida's sample is a great data point. I won't be able to try until Monday.
-- Fred -- Hardware Guy --
FHuettig
 
Posts: 142
Joined: Wed Jan 29, 2014 8:30 pm
Location: Lexington, MA, USA

Re: USB workaround

Postby Frida » Sun Jul 27, 2014 8:18 pm

I have now tried with a 47uF tantalum cap between pin 3 and 4.
Out of 10 starts with a 30 sec. pause, there was 10 success.
User avatar
Frida
 
Posts: 22
Joined: Wed Sep 04, 2013 2:37 pm
Location: Middelfart, Denmark

Re: USB workaround

Postby ajtravis » Sun Jul 27, 2014 9:08 pm

Frida wrote:I have now tried with a 47uF tantalum cap between pin 3 and 4.
Out of 10 starts with a 30 sec. pause, there was 10 success.

Hi, Frida.

In desperation, I went out and bought an expensive Belkin F4U018-BLK 7-port powered USB hub over the counter today and it does work better than the selection of different no-brand USB hubs I was trying before. My four Parallella cards still don't initialise USB 100% of the time, but it's a lot better than it was and I've got a demo to do on Wed, so I can't spend any more time on this just now.

One thing I wondered about is USB OTG because I read in the Parallella documentation that it has 1 USB and 1 USB OTG port and the Zync can provide USB OTG on both ports. I'm not clear if the 'rear' USB connector (i.e next to the RJ45 connector) is disabled and there to supply power only, which is how I'm using it. If the 'front' USB connector is capable of OTG there might be an issue about how the port detects what is connected. AFAIK, OTG uses the capacitance of cables and devices to decide what role to adopt (master/slave A/B).

I still think there is a potentially serious underlying design problem with the parallella USB port that needs to be resolved because it makes a nonsense of using the 'Desktop' computer HDMI configuration if you can't attach a USB keyboard and mouse. It also restricts what you can do with the 'Desktop' if you only have the SD card for storage. I would like to put together a small self-contained Parallella Beowulf cluster with one HDMI 'head' node and three headless 'worker' nodes. I do, of course, realise that the Parallella is really an evaluation board for the Epiphany processor but I think it has great potential as a 'Desktop' computer with a working USB port :-)

I've re-done everything to install from scratch and used "setenv bootdelay 5" on the Zync, and using my shiny new Belkin USB hub I get this on my 4-node Parallella micro-Beowulf (dsh is Dancer's distributed shell):
Code: Select all
node1:~> dsh -Ma -- lsusb
node1: Bus 001 Device 006: ID 0d49:5010 Maxtor 5000LE Drive
node1: Bus 001 Device 005: ID 046d:09a4 Logitech, Inc. QuickCam E 3500
node1: Bus 001 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver
node1: Bus 001 Device 003: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
node1: Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
node1: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
node2: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
node3: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
node4: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Just in time for my demo on Wed!

I'm puzzled that the USB ports on the worker nodes are now working with nothing connected to them. The only hardware change is replacing my dodgy Maplin 'Cerulian' 7-port powered hub with a Belkin one costing more than twice as much even though it appears to have the same chips in it. Maybe the cheap 5V PSU supplied with it was the problem - Who knows...

I've also upgraded all the nodes, which might be relevant:
Code: Select all
apt-get update
apt-get dist-upgrade
<reboot>


USB initialisation is still not 100%, and I still need to cycle the power, but it's a LOT better than before :-)

Bye,

Tony.
Minke Informatics Limited, Registered in Scotland - Company No. SC419028
User avatar
ajtravis
 
Posts: 162
Joined: Fri Jul 18, 2014 12:54 pm
Location: Scotland (UK)

Re: USB workaround

Postby greytery » Tue Jul 29, 2014 9:32 am

ajtravis wrote:One thing I wondered about is USB OTG because I read in the Parallella documentation that it has 1 USB and 1 USB OTG port and the Zync can provide USB OTG on both ports.

See the aside from Fred about the status of the OTG USB at the 'rear' of the board. The manual does mention "Two USB 2.0 OTG peripherals" at one point but, mostly, it distinguishes between the PC/power connector and peripheral USB connector.

ajtravis wrote:AFAIK, OTG uses the capacitance of cables and devices to decide what role to adopt (master/slave A/B).

From the schematic, it looks like the OTG USB PC connector (0.1uf) and USB peripheral connector (4.7uf) have on-board capacitance circuitry on the VBUS line to 'fix' their function.

ajtravis wrote:I would like to put together a small self-contained Parallella Beowulf cluster with one HDMI 'head' node and three headless 'worker' nodes.

Sounds like you might also enjoy the rocky journey to using nfs mount and tftp boot.

Cheers,
tery
User avatar
greytery
 
Posts: 205
Joined: Sat Dec 07, 2013 12:19 pm
Location: ^Wycombe, UK

Re: USB workaround

Postby teekai » Sun Aug 10, 2014 10:05 pm

FHuettig wrote:
Sean S wrote:Can anyone advise if this is the latest image for the FSBL in the QSPI flash:
https://github.com/parallella/parallell ... 1/firmware


I can, it is not.

Sean S wrote:Is it compatible with all boards?


No, the 7010 and 7020 use different bitstreams, which are part of the flash image.

I've updated the files here as well as the README file. PLEASE be careful, it would be easy to enter the wrong number of zeros in one of the commands and you'll be out of luck.

DISCLAIMER
As a general rule, any mistake or power disturbance while reprogramming the flash memory on the board may result in a non-functional board (a "brick") which will require re-flashing using the Xilinx toolchain and JTAG programmer. This is not covered by warrantee. Please be careful, and please follow the directions completely.


Is there step by step instruction on how to flash the firmware as described here for the 7010
Thnks,
-Teekai
teekai
 
Posts: 10
Joined: Sat Aug 09, 2014 7:29 am

Re: USB workaround

Postby FHuettig » Mon Aug 11, 2014 2:57 am

teekai wrote:Is there step by step instruction on how to flash the firmware as described here for the 7010


Hi Teekai,

if you have a 7010 board then you already have the latest. For both 7010 and 7020, if CR10 lights up at boot you're all set.

The instructions for re-writing the flash are in a README file in the directory I linked-to above, the procedure is the same for 7010&7020 just the files are different.. Start at step 9 when using the UART rather than the Xilinx JTAG interface.
-- Fred -- Hardware Guy --
FHuettig
 
Posts: 142
Joined: Wed Jan 29, 2014 8:30 pm
Location: Lexington, MA, USA

Re: USB workaround

Postby sintacks » Wed Aug 13, 2014 7:02 am

Frida, your wire mod worked for me. The USB on my 7020 board had never worked before this mod.

Since I have the big heatsink on my board, I connected from CR10 pin1 to the BOARD_RESET_L side of R295 (bottom of the board).

Before making the wire mod, I tried a 10nF ceramic cap between R295 and the ground side of R294, but that did not make a difference for me. I might scrounge up a larger tantalum cap later and see if I can get it working that way. Otherwise, I may try replacing R295 with a 10K or 100K resistor to increase the RC time delay for deasserting the reset. The wire mod is too fragile to be a permanent fix.
sintacks
 
Posts: 1
Joined: Wed Aug 13, 2014 6:40 am

Re: USB workaround

Postby FHuettig » Sun Aug 17, 2014 3:06 pm

sintacks wrote:Before making the wire mod, I tried a 10nF ceramic cap between R295 and the ground side of R294, but that did not make a difference for me. I might scrounge up a larger tantalum cap later and see if I can get it working that way. Otherwise, I may try replacing R295 with a 10K or 100K resistor to increase the RC time delay for deasserting the reset. The wire mod is too fragile to be a permanent fix.


10nF is too small. Frida's experiments showed a minimum delay of 30ms is required, on my system I need at least 42ms to avoid the Zynq write that triggers the failure. I had suggested 47uF as a minimum capacitance, 68uF may be more reliable.
-- Fred -- Hardware Guy --
FHuettig
 
Posts: 142
Joined: Wed Jan 29, 2014 8:30 pm
Location: Lexington, MA, USA

Re: USB workaround

Postby Frida » Fri Aug 22, 2014 6:52 pm

Well it has been a while since.
Is there anybody here, that have looked at the logik from the FPGA to the USB.??

Is the "STP" "p0_usb_stp" signal high, until the FPGA has sat up the data lines to the USB, and is ready to talk to the USB.??

I found out, I have a window from ca. 30 ms. to 10sec., where I can held down "BOARD_RESET_L", and still have my USB to work.

When login is reached, I can held "BOARD_RESET_L" low for a minute or so, and when I release it , it all works again.

I hope that somebody with insight in the FPGA will chime in.
User avatar
Frida
 
Posts: 22
Joined: Wed Sep 04, 2013 2:37 pm
Location: Middelfart, Denmark

Re: USB workaround

Postby FHuettig » Sat Aug 23, 2014 4:04 am

Frida wrote:Is there anybody here, that have looked at the logik from the FPGA to the USB.??

There is no logic that we can look at, it's all in a hard-IP block that's part of the Zynq peripherals. The signals are assigned to certain FPGA pins and then routed to the PHY. If it were something where I could read the source code, or simulate it, or even monitor with ChipScope it would be a lot easier to debug.

Frida wrote:Is the "STP" "p0_usb_stp" signal high, until the FPGA has sat up the data lines to the USB, and is ready to talk to the USB.??


Yes, but maybe there is a race condition on the ULPI. When it works it works fine as it should, when it does not work the ULPI goes crazy and I haven't yet figured out the cause. But I can see it fail on one of the boards I have and the symptoms seem to be the same as what everyone here is describing. I've been out of the office lately but will get this back on the logic analyzer next week.

Microchip has been trying to help us with this, they've made some suggestions about what might cause this failure mode but it doesn't match what I see.

Cheers.
-- Fred -- Hardware Guy --
FHuettig
 
Posts: 142
Joined: Wed Jan 29, 2014 8:30 pm
Location: Lexington, MA, USA

PreviousNext

Return to Troubleshooting

Who is online

Users browsing this forum: No registered users and 2 guests

cron