Parallella Community

Well after I have tried a lot, I have now made a workaround for my USB problems.
With an injection needle a resistance and a lot of patience I began to troubleshoot on my Parallella.
After a study of the diagram, and download of a couple dokuments, I have narrowed it to down to U33 on page 17.
I think there are a race condition on the reset network.
Now I have a jumper between USER LED CR10 pin1 and U33 PIN4.
It now boots up every time, both with and without, USB cable.

Hi Frida,

Would you mind describing what you think the problem is and what your jumper does? I'm guessing pulling something to ground?

thx!

I was just about to ask the same thing. Can you describe the symptoms this fixes? I understand your (very clever!) fix delays the release of the USB reset signal until after the FPGA has started to configure, but it's not immediately obvious how that helps. The USB reset will still be released well before the FPGA has completed configuration and a long time before Linux starts to boot.

You've got me thinking that the FPGA pins, being pulled weakly high before configuration, must be doing something evil to the PHY in that time. Perhaps the PHY is interpreting the high level on its CLKOUT pin as a request to have the clock driven by the link instead of by the PHY, that could certainly cause problems!! I'll have to look at this closely.

Thanks for taking the time to investigate, we needed a fresh perspective. The intermittent nature of this failure makes it very tough to diagnose, especially since I hardly ever see this failure any more.

1: First I power up my board and waited until the login screen was on, then I hit the reset button shortly and waited until the login screen was on again. Now I could login.

2: I tried to hold the reset button for 10 sec. until I was sure that power on the card had stabilized. It did not help.

3: Then I found out, when I hit the reset button when the USER LED came on, then I could login.

4: I looked on the datasheet of U33, and saw that the output on pin 4 is high Z, when there is no power. It meant that the BOARD_RESET is not in reset at the moment we power up. I then took my needle and resistance and place it on pin 4 and ground and then power up. As soon the USER LED came on, I removed my needle and I could login.

5: That made my think of a rc delay on PIN 4, but before I did it, I measured the voltages on the USER LED and measured 3.16 volts on pin 2 and 1.22 volts on PIN 1. I saw that the resistance R30 was 230 ohm., so that in serie with R295 1k ohm., could held the reset ontil the USER LED came on. The 1.22 volt is high enough to get it out af reset and still under 1.8 volts that is max. So I could not resist placing a jumper from U33 PIN 4 to CR 10 PIN 1.
6: And yes, it works fine for me. Now I can held down the reset button as long as I wish, and it will still start up, when I release it.
And yes, that is what a reset button should do.

I thought with my powersupply it will take several usec. to power up all the circuits,
and which circuit has enough voltage to operate first, maybe the reset circuit come in with a reset pulse after some circuits has begun to work.


@FHuettig, Are You always using a bench powersupply, maybe it is strong enough to rapidly power on the circuit, so that you dont se our problems:)

What does TURBO_MODE?, it is high when powered from J12, and low when I change the jumper to power it from USB_VBUS.

Please ask again if there is something not to understand.

I am going to give this a go on my board in the next few hours and let you know if it worked for me.

Update:

My theory, that the PHY was getting into a mode where the ULPI interface was clocked by the external input (pin 26) instead of driving a clock out on pin 1, is busted. Even when the phy is "missing" there is still a nice clean 60MHz clock.

Also, I am able to "resurrect" a board after it has failed (because of a reset, in my case) by employing Frida's trick of holding the USB reset a bit longer than the FPGA reset. So maybe there is only one failure mode, it's just that diffrerent boards/chips exhibit the problem in different ways (at power-on or only after reset).

I'll keep digging.