USB EHCI problems

It does not get unstable.

Gerald

It does not get unstable.

Gerald

My observation is that it makes it more stable as I don't now have to
reboot, I can simply re-plug the devices into the hub and they come up
configured.
Regards
Sid.

If indeed the noise was increased due to the added value, then the opposite would be true in that it would fail almost immedaitely or even not come up at all.

Gerald

When you say "re-plug" do you mean you have to physically unplug the
device and reseat it, or can you do a <a href=http://marc.info/?
l=linux-usb-users&m=116827193506484&w=2>software reset</a> to fix it?
I've finally gotten to the point where mine can detect the failure,
reboot, and recover almost entirely automatically. Almost. I'd like
to at least try and fix it so it doesn't have to keep resetting, but
having to physically re-plug my WiFi if it goes down isn't any better
of a solution: in fact, it's worse, since I can't have it done
automatically. If you can fix it by just using the device reset code
I linked, that'd be perfect though.

The issue that the CAP is intended to solve is the lockup of the PHY. When I say lock up, it can’t be reset without a power cycle. We have not tied any other behavior than this to this issue. I don’t think added capacitance will help but it can’t hurt to try.

Gerald

You are probably better off by using a cap with a low ESR. Ceramic caps usually have a lower ESR than tantalums, but I have seen some ceramic caps with an ESR of 1 ohm and others with 0.1 ohm in the same value and packaging size.

We use ceramic caps which are non-polarized. The side closest to the SD
card is positive.
Gerald

The 0805 22uF ceramic cap is the one I have used. An improvement, but
not a solid cure, I wonder if another 22uF on top would likely cure the
problem of periodically losing contact with the Wifi and the LAN - the
hub now stays up so I don’t have to reboot, re-plugging the devices is
all that’s needed.
Another effect I have noticed since installing the cap, the speakers
emit a sound just like if you have a hard drive or DVD drive having
trouble reading media.
Regards
Sid.

Oh, I agree. That is in fact what we use. In fact, if you look at Beagle there are very few tantalums on the board.

But, those are not typically in a lot of folks parts bin. I do not recommend using a tantalum or an electrolytic, but if that is all you have, I see no issue in giving it a try.

Gerald

I unplug then device and reseat it. I shall try the usbreset to see if
that does it.
Regards
Sid.

The "usbreset" works, but the device seems to fail more often, in just a
few minutes at times.
root@beagleboard:~# usbreset /proc/bus/usb/001/001
The above always needed, though the device number changes each time,
016, 025, 030.
root@beagleboard:~# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 022: ID 04cc:1521 Philips Semiconductors USB 2.0 Hub
Bus 001 Device 023: ID 148f:2573 Ralink Technology, Corp. RT2501USB
Wireless Adapter
Bus 001 Device 024: ID 046d:c404 Logitech, Inc. TrackMan Wheel
Bus 001 Device 025: ID 07a6:8515 ADMtek, Inc. AN8515 Ethernet
Bus 001 Device 026: ID 1267:0103 Logic3 / SpectraVideo plc G-720 Keyboard
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

root@beagleboard:~# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 027: ID 04cc:1521 Philips Semiconductors USB 2.0 Hub
Bus 001 Device 028: ID 148f:2573 Ralink Technology, Corp. RT2501USB
Wireless Adapter
Bus 001 Device 029: ID 046d:c404 Logitech, Inc. TrackMan Wheel
Bus 001 Device 030: ID 07a6:8515 ADMtek, Inc. AN8515 Ethernet
Bus 001 Device 031: ID 1267:0103 Logic3 / SpectraVideo plc G-720 Keyboard
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Regards
Sid.

Any new updates to this issue?

The 0805 22uF ceramic cap is the one I have used. An improvement, but
not a solid cure...

So anybody has any idea?
Or is RMA the only way to go? And what would you do then?

// Carl

This issue is due to be fixed with on REV C4. It is not clear that it can be fixed on all Rev C3 boards. You are free to try an RMA, but their is no guaranty that it can be fixed. What will be done there is the soldering of the 20uf CAP across C97 and then they will run the board for a couple of days to see how well it works.

Gerald

This issue is due to be fixed with on REV C4. It is not clear that it
can be fixed on all Rev C3 boards. You are free to try an RMA, but their
is no guaranty that it can be fixed. What will be done there is the
soldering of the 20uf CAP across C97 and then they will run the board
for a couple of days to see how well it works.

Gerald

I had a false dawn, when I first installed the cap on my C3, there was
an immediate improvement. Since then it's behaving as it always was with
the ADMtek, Inc. AN8515 Ethernet USB adapter having to be replugged
frequently.
Regards
Sid.

If you can replug in a device and get it working, then it si NOT this EHCI issue. This issue results in a complete shutdown of the EHCI port that requires a power cycle to clear it. Sounds like you have another issue.

Gerald

Thanks for the reply,

Well good. Where do I send my board to get a refund?

The place you purchased it from.

Gerald

Addding a filter in series with the 1.8V rail and the PHY, increasing the capacitance on the 1.8V rail to the PHY, using the VAUX2 output from the TPS65950 for the 1.8V supply, and changing the boot code to activate the rail.

It is not possible to do this on the Rev C3 board by soldering. The pins on the TPS65950 are not brought out and the power rail is not accessible via an etch cut to interface to the power on the PHY.

Gerald

Addding a filter in series with the 1.8V rail and the PHY, increasing the
capacitance on the 1.8V rail to the PHY, using the VAUX2 output from the
TPS65950 for the 1.8V supply, and changing the boot code to activate the
rail.

It is not possible to do this on the Rev C3 board by soldering. The pins on
the TPS65950 are not brought out and the power rail is not accessible via an
etch cut to interface to the power on the PHY.

How about adding an extra external regulator for the USB PHY VDD1.8 on
my REv C3 board
Is there for some reason a big no in doing this?

I will try with the cap solution and if that doesnt work I will think
about the an external regulator.

// Carl

You can try it, but the difficulty is getting access to the power pin on the PHY and isolating it from the rest of the 1.8V rail. The PHY is a .4mm pitch BGA. It is not like you cna just lift a pin.

Gerald

If you can replug in a device and get it working, then it si NOT this
EHCI issue. This issue results in a complete shutdown of the EHCI port
that requires a power cycle to clear it. Sounds like you have another issue.

Gerald

Thanks for reminding me, I missed that part. The hub used to power down
at times, it stays up since I added the cap, so I don't have to reboot.
Even if the link drops during a transfer, I just have to re-plug it and
it carries on.
Regards
Sid.

Great! So now I would look to see what was casing the drop. I have heard this from others as well, depending on their SW version. The EHCI issue as such has the PHY totally lockup requiring a power cycle to clear.

Gerald