Usb Problems?

[WizardStan]

Some BeagleBoards seem to suffer from problems with the USB host. Apparently it is an OMAP problem, or something. I don't fully understand it.
http://groups.google.com/group/beagleboard/browse_thread/thread/5b8385f0bb1f63da
It's not likely to be a problem in the Pandora (different USB chips, I think? Maybe?), but I wonder if testing has been done against this known issue. It's easy to trigger with multiple devices plugged in to a hub, including a hard drive of some kind, and just dd from that drive to /dev/null. 3 or 4 attempts, and the EHCI goes dead until reset. I'd feel a lot more comfortable if I knew I was worrying over nothing.
And I only ask because I only just discovered my BeagleBoard suffers from this problem. I thought it was something I was doing wrong this whole time.

 

[gruso]

I don't have time to find a source right now, but check MWeston's recent posts. He mentioned a USB issue that was identified and resolved in the course of Pandora board revisions.

 

[lulzfish]

Maybe 99% of every Beagleboard works?

I doubt it. It's a issue with noise on the 1.8V rails which power the USB. If a lot of data is transferred over the USB (such as to a hard disk or flash drive) it can cause the USB controller to fail or spontaneously reset.

I wonder how MWeston designed this part of the Pandora.

We haven't seen this problem on Pandora but that is likely due to the small sample of boards we have. We've had some bad soldering issues on rev2 though, but that would just mean good USB or a dead port. I have let gigs and gigs of data transfer from one USB drive to another USB drive on a rev3 board and it wouldn't fail. Regardless of how 'lucky' I feel we are with Pandora, I still implemented the fix that TI recommended to separate the 1.8V supply to the USB PHY from the TPS65950's 1.8V supply to prevent any future problems when we have thousands in the wild. It's yet another one of those fixes that couldn't have been done if we shipped so long ago.

I managed to beat the search engine into finding MWeston's post.
tl;dr: "We haven't had that problem, but I fixed the cause of it anyway, just in case."

 

[WizardStan]

That's the one. Awesome! Good show guys

edit: now if only I could get a fix for my BeagleBoard so I wouldn't have to reset the blasted thing every few days.

 

[Mr B]

That's the one. Awesome! Good show guys

edit: now if only I could get a fix for my BeagleBoard so I wouldn't have to reset the blasted thing every few days.

If it's "just" noise a capacitor in line with the 1.8v feed should fix it. good luck installing it. ;- )
B!

 

[WizardStan]

That's the one. Awesome! Good show guys

edit: now if only I could get a fix for my BeagleBoard so I wouldn't have to reset the blasted thing every few days.

If it's "just" noise a capacitor in line with the 1.8v feed should fix it. good luck installing it. ;- )
B!

There is one. They've also tried other combinations of caps. It doesn't work like that for some reason. The fix is to actually set something in the OMAP to reduce the power draw it uses ever so slightly which smooths out the noise, or something like that. The problem is that the fix is very easy in kernels that support it, but I'm having trouble getting a straight answer as to what patch I need to apply to my kernel in order to get this magic fix.