dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5282
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: USB - the Elephant in our Room

Fri Aug 24, 2012 11:00 pm

As the microframe_schedule option has been well received, it is now turned on my default.
You can still disable it with:
dwc_otg.microframe_schedule=0

You will get it from rpi-update.

pygmy_giant
Posts: 1562
Joined: Sun Mar 04, 2012 12:49 am

Re: USB - the Elephant in our Room

Fri Aug 24, 2012 11:41 pm

@ wallacebiy - try a powered hub?

rrw1000
Posts: 1
Joined: Sat Aug 25, 2012 12:32 am

Re: USB - the Elephant in our Room

Sat Aug 25, 2012 12:55 am

I'm just passing, but the BCM2835 short form data sheet that was released suggests that it uses the Synopsys USB IP; I don't know how much better the drivers have gotten, or if this is the same bug (it's kinda hard to tell) but I had some fun with USB transaction translation with the Synopsis IP on a ZMS-08 a year or two back - http://kynesim.blogspot.co.uk/2010/12/i ... -2312.html - which sounds suspiciously like the problems GPSFan has been having with his USB 1.1 devices, but the short form answer as far as I have been able to ascertain is:

- EHCI just about works (but don't look at the transaction scheduling code; it's horrific)
- musb (the Mentor IP) is beginning to work, thanks to TI having basically rebuilt its DMA engine from the ground up, twice. It still doesn't actually work, in the sense that you can't hotplug or anything, but it at least passes transactions.
- The Synopsys drivers are (probably still) appalling. Do not use for serious work.
- Good luck with those isochronous transaction schedules. We mean it.
- LAN951X don't do transaction translation correctly, but no-one seems to care other than the Synopsys IP. I don't know why.

Of course, none of this helps any of you, but I thought I'd have a rant in case someone saw something they recognised anyway :-).

The USB power issue should be relatively easily fixed, provided you have a meaty enough PSU at one end and your PCB tracks are real and not teeny thin - GPSFan's TPS2052 solution is the one I like best. I would be _very_ suspicious of any design that doesn't aggressively decouple VUSB from its regulators - I think everyone in the business has now had the experience of "USB device decides to suck 1A globs because its designers apparently didn't think capacitors were a thing. +5V droops. At same time (probably because it is taking USB disconnect) processor decides to gulp, regulator o/p capacitance isn't quite enough at whatever switch speed it has, Vcore droops, processor resets" and, frankly, I for one don't want to have it again (the original Beagleboard folk had this in spades for a while - google 'beagleboard C97 hack').

And seriously chaps, are polyfuses really a better plan than a high-side switch?

Anyway, I shall try have a go with some USB devices I know "work" (in the sense that I know what they do wrong) and our USB analyser and report back if I can.

(disclaimer: Whilst I do do this sort of stuff for a living, I'm still usually wrong - take with several spoonfuls of salt.)

rafi
Posts: 1
Joined: Sat Aug 25, 2012 5:57 am

Re: USB - the Elephant in our Room

Sat Aug 25, 2012 6:10 am

I'll chime in. I've had USB, stability and network issues, and not bothered to post previously. It didn't seem necessary.

It would be nice to have some feedback when the power supply dips. Might be more important, or at least more convenient than trying to make something that will play nice with whatever power supplies people throw at it. If it's powered by USB, how often will a group of students decide to see how many they can daisy chain?

Perhaps a low power led, or changing the color/state of the main power LED (perhaps it already does, and I haven't noticed), a kernel message, and a notification if a gui desktop environment is active.

naplam
Posts: 43
Joined: Tue Aug 14, 2012 11:04 pm

Re: USB - the Elephant in our Room

Sat Aug 25, 2012 11:17 am

rrw1000 wrote: - Good luck with those isochronous transaction schedules. We mean it.
I have to say I'm having dropped frames on my webcam and erratic frame rates (and it's a regular UVC webcam). I guess it's related to this usb issue... how bad is it with isochronous transfers?

User avatar
NerdUno
Posts: 63
Joined: Wed Aug 15, 2012 1:35 pm

Re: USB - the Elephant in our Room

Sat Aug 25, 2012 11:28 am

We've ported our Incredible PBX to the Raspberry Pi platform. Many folks wanted to run their PBX wirelessly which required a USB WiFi adapter. The first one we got working was the TP-Link, a power hungry device indeed. What we saw with typical 5V/1A power bricks was lockups about every 5 minutes. Once we switched to a (properly rated) 1.2A adapter, all of the issues permanently vanished. Then we tried a couple of the dual USB, 2.1A power bricks which advertise up to 2.1A on a single USB port if needed. The instant lockups returned almost immediately. Keep in mind that many of these power adapters are not U/L rated, and the manufacturers appear more than willing to overhype their specs.

Speaking strictly as an observer and not an electrical engineer, I would lay the blame for many of the so-called RasPi USB power issues at the door of lousy power adapters being used in combination with power-hungry USB devices. Replace either or both of these, and all the problems magically disappear. We've now switched to the ultra-tiny AirLink 101 WiFi adapters, and systems with those adapters are rock-solid reliable with a (properly rated) 5V/1A power source. Just my $.02.

naplam
Posts: 43
Joined: Tue Aug 14, 2012 11:04 pm

Re: USB - the Elephant in our Room

Sat Aug 25, 2012 11:32 am

rafi wrote:Perhaps a low power led, or changing the color/state of the main power LED (perhaps it already does, and I haven't noticed), a kernel message, and a notification if a gui desktop environment is active.
Idea 1: Power the pi from three aa batteries (4.5V) in parallel with your regular power supply, using diodes to prevent current flow from the batteries to the supply and vice-versa. Use a LED to detect when the current is flowing from the batteries, this will mean the power supply has dropped below 4.5V.

Idea 2: voltage divider to a LED so that it receives barely enough voltage (just a bit more than its forward voltage drop) to light up when the supply is at 5V. Make it so it doesn't light up when powered by, say, 4.5V.

User avatar
pluggy
Posts: 3635
Joined: Thu May 31, 2012 3:52 pm
Location: Barnoldswick, Lancashire,UK
Contact: Website

Re: USB - the Elephant in our Room

Sat Aug 25, 2012 11:57 am

naplam wrote: Idea 2: voltage divider to a LED so that it receives barely enough voltage (just a bit more than its forward voltage drop) to light up when the supply is at 5V. Make it so it doesn't light up when powered by, say, 4.5V.
You cannot put any load on a voltage divider without pulling the voltage. Unless you have very low values resistors with a very large current flowing through them there won't be enough to run an LED. Voltage dividers are only really suitable for the input of a micro-controller or similar where there is a negligible load (microamps or less).
Don't judge Linux by the Pi.......
I must not tread on too many sacred cows......

obcd
Posts: 917
Joined: Sun Jul 29, 2012 9:06 pm

Re: USB - the Elephant in our Room

Sat Aug 25, 2012 1:14 pm

This thread is about the usb issues. While it's obvious and proven that a stable supply voltage of at least 4.75V is needed to run reliable, it's not the cause of all usb problems people are seeing.
rrw1000 pointed out issues in the synopsys driver and hardware implementation of the usb host port.
The people from the foundation examining the issue (Gordon gsh) came to the same conclusion.
So please, stop telling people here that their usb issues are only caused by crappy power supplies, when it's not the case. The cause of the disease is known, all we can do now is wait for proper medication, or make proper medication ourself.

User avatar
NerdUno
Posts: 63
Joined: Wed Aug 15, 2012 1:35 pm

Re: USB - the Elephant in our Room

Sat Aug 25, 2012 2:03 pm

@obcd: Perhaps you missed rrw1000's final comment:
(disclaimer: Whilst I do do this sort of stuff for a living, I'm still usually wrong - take with several spoonfuls of salt.)

obcd
Posts: 917
Joined: Sun Jul 29, 2012 9:06 pm

Re: USB - the Elephant in our Room

Sat Aug 25, 2012 2:38 pm

I didn't miss it. I even found a small amount of irony in it.
We still have Gordon from the foundation who also reported missing packets.
I do expect at least him to use a decent power supply. :D He didn't report back it fixed the issues.
If I can quote Dom in one of his latest answers:
The issue with running out of periodic channels has been improved.
He isn't saying it has been solved either.
I want to thank him never the less for his effort, the situation indeed has improved.

User avatar
pluggy
Posts: 3635
Joined: Thu May 31, 2012 3:52 pm
Location: Barnoldswick, Lancashire,UK
Contact: Website

Re: USB - the Elephant in our Room

Sat Aug 25, 2012 2:40 pm

I've fudged a work around for my lifecam not working at 640 x 480 with the pi. Take the pictures at 352*288 and then use imagemagick 'convert' to resize them. I said it was a fudge......

Image

Presently got this running from crontab once a minute, saves a 640 x 480 image to a folder.

Includes delays and taking extra pictures to let the the camera 'warm up' .

Code: Select all

#!/bin/bash
streamer -c /dev/video0 -b 16 -w 4 -t 5 -r 2 -s 352x288 -o /root/cam00.jpeg
convert /root/cam04.jpeg -resize 640x480\! /root/cam2.jpeg
fn=`date +%H-%M`
filename=$fn'.jpeg'
cd /var/log/camera
cp /root/cam2.jpeg $filename
cd ~
Don't judge Linux by the Pi.......
I must not tread on too many sacred cows......

bfromcolo
Posts: 26
Joined: Sat Aug 11, 2012 11:20 pm

Re: USB - the Elephant in our Room

Sat Aug 25, 2012 5:51 pm

dom wrote:
These go in cmdline.txt (with no newline)
dwc_otg.microframe_schedule=0 dwc_otg.speed=1

These go in config.txt (with a newline between each option)
disable_overscan=1

(overscandisable_overscan is not a valid option).

I added dwc_otg.microframe_schedule=0 dwc_otg.speed=1 to cmdline.txt so the contents of that file read:
dwc_otg.lpm_enable=0 dwc_otg.microframe_schedule=0 dwc_otg.speed=1 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
The only active line in config.txt was:

disable_overscan=1

Booting with the keyboard and mouse attached directly to the Pi, I ended up with no working keyboard and mouse. I restored the cmdline.txt, rebooted and am online typing this from the Pi.

My kernel version is:

Linux raspberrypi 3.2.27+ #24 PREEMPT Sun Aug 19 21:28:36 BST 2012 armv6l GNU/Linux

I confess this thread gets a little hard to follow. Am I trying the right combination of stuff?

bfromcolo
Posts: 26
Joined: Sat Aug 11, 2012 11:20 pm

Re: USB - the Elephant in our Room

Sat Aug 25, 2012 8:47 pm

I updated to Linux raspberrypi 3.2.27+ #66 PREEMPT Fri Aug 24 23:52:42 BST 2012 armv6l GNU/Linux and am now able to have keyboard, mouse and WIFI adapter connected to the hub. I can even talk to adapter and scan available networks. Getting some errors trying to connect but I will post that separately since I don't think its related to the USB issues any longer.

Thanks, looks like some progress!

naplam
Posts: 43
Joined: Tue Aug 14, 2012 11:04 pm

Re: USB - the Elephant in our Room

Sun Aug 26, 2012 12:38 pm

pluggy wrote:You cannot put any load on a voltage divider without pulling the voltage. (...) Voltage dividers are only really suitable for the input of a micro-controller or similar where there is a negligible load (microamps or less).
What was that? a voltage divider is suitable for whatever it's suitable (micro amps? I can run 10A through one if I want) Simple example: http://pastebin.com/ZGFPVnQG (pastebin because this is a bit off-topic so I want to be brief here)

rspitz
Posts: 58
Joined: Tue Jul 31, 2012 7:25 pm

Re: USB - the Elephant in our Room

Sun Aug 26, 2012 12:40 pm

I used rpi-update last night to update to the newest firmware and kernel. uname -a now returns "Linux raspi 3.2.27+ #66 PREEMPT Fri Aug 24 23:52:42 BST 2012 armv6l GNU/Linux", and the standard cmdline.txt is "dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait"

Running the Pi headless and only having one prolific PL2303 serial-to-USB converter as the only USB device connected, reading data at 9600 baud, I still get the dreaded eth0 error messages frequently:

Code: Select all

[44952.726079] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
[45169.349666] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118
[46452.209545] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118
[46665.017129] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114
I am getting pretty confused by the many "dwc_otg" parameters suggested for cmdline.txt. Is there a parameter that I should set that addresses the eth0 error messages?

naplam
Posts: 43
Joined: Tue Aug 14, 2012 11:04 pm

Re: USB - the Elephant in our Room

Sun Aug 26, 2012 12:58 pm

rspitz wrote:I am getting pretty confused by the many "dwc_otg" parameters suggested for cmdline.txt. Is there a parameter that I should set that addresses the eth0 error messages?
If the guy who said that he suspects Broadcom chose buggy IP for the processor's USB is right, there will probably be no solution. I've now noticed my wireless nic is dropping more than half the packets :/ I got one or two of these eth0 error messages when I was using eth0 but I didn't notice any problems (although I wasn't transferring data heavily). As far as networking is concerned, the issue isn't that bad, after all, communications protocols will make sure the data gets transferred. The real problem is with other devices (webcams, external hard disks...), which have no practical way of mitigating the issue.

User avatar
mahjongg
Forum Moderator
Forum Moderator
Posts: 11998
Joined: Sun Mar 11, 2012 12:19 am
Location: South Holland, The Netherlands

Re: USB - the Elephant in our Room

Sun Aug 26, 2012 1:10 pm

naplam wrote:
pluggy wrote:You cannot put any load on a voltage divider without pulling the voltage. (...) Voltage dividers are only really suitable for the input of a micro-controller or similar where there is a negligible load (microamps or less).
What was that? a voltage divider is suitable for whatever it's suitable (micro amps? I can run 10A through one if I want) Simple example: http://pastebin.com/ZGFPVnQG (pastebin because this is a bit off-topic so I want to be brief here)
Yes, but then the divider would consume so much power that it probably would overload the very PSU you would be testing, and if you hade a very powerful PSU that would be able to take the extra load why would it "dip". Dipping occurs when the system (Pi) suddenly uses a lot more power that the PSU can supply.
Also, its very unlikely you would see the very short variation in the brightness of the LED, you would need a more complex solution that "remembers" the dip. Using a "thyristor" (or just two transistors connected in the right way) would be a starting point, as these (once triggered) keep conducting current, until the current dips below a threshold. Problem is, its only a small dip we are expecting, not a short complete power fail.

If you have an oscilloscope you could set it to "single trigger", and put the trigger point just below 5V to catch the dip.

User avatar
pluggy
Posts: 3635
Joined: Thu May 31, 2012 3:52 pm
Location: Barnoldswick, Lancashire,UK
Contact: Website

Re: USB - the Elephant in our Room

Sun Aug 26, 2012 1:28 pm

Always look on the bright side of life ;)

When the foundation have got their camera module working and 'out' they should maybe turn their attention to a dedicated wifi adapter that by passes the USB. Its very clearly an issue, stick the driver in the kernel of the recommended distro and away you go. It also deals with those calling for built in Wifi for a model C. I see the polyfuses on the USB have been consigned to the history books which has to be a good move.

[off topic]You could run 10 amps through a voltage divider if you wanted a room heater, but established wisdom is that most of the current is wasted through the resistors between VCC and ground, so the useful take off isn't affected too much. I'd keep it to micro amps so it isn't wasting very much.[/off topic]
Don't judge Linux by the Pi.......
I must not tread on too many sacred cows......

naplam
Posts: 43
Joined: Tue Aug 14, 2012 11:04 pm

Re: USB - the Elephant in our Room

Sun Aug 26, 2012 2:19 pm

[offtopic] just look at the pastebin. You'd waste 10-15mA with the circuit I posted, with 0-1.5mA going through the LED. Perfectly usable to keep an eye on voltage (not voltage spikes of course).[/offtopic]

User avatar
pluggy
Posts: 3635
Joined: Thu May 31, 2012 3:52 pm
Location: Barnoldswick, Lancashire,UK
Contact: Website

Re: USB - the Elephant in our Room

Sun Aug 26, 2012 3:05 pm

naplam wrote:[offtopic] just look at the pastebin. You'd waste 10-15mA with the circuit I posted, with 0-1.5mA going through the LED. Perfectly usable to keep an eye on voltage (not voltage spikes of course).[/offtopic]
[offtopic]
OK, just to keep the peace I'll call it 1500 microamps
[/offtopic]
Don't judge Linux by the Pi.......
I must not tread on too many sacred cows......

User avatar
Burngate
Posts: 5930
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK Tralfamadore
Contact: Website

Re: USB - the Elephant in our Room

Sun Aug 26, 2012 3:12 pm

[off topic] https://sites.google.com/site/burngateh ... erLEDs.SVGbit more complicated, no component values, but a short dip in volts should give a longer blip on the 2nd LED

wallacebiy
Posts: 59
Joined: Wed May 16, 2012 2:00 pm

Re: USB - the Elephant in our Room

Mon Aug 27, 2012 2:27 pm

pygmy_giant wrote:@ wallacebiy - try a powered hub?

Dunno what post of mine you're referring to .
I am using an iomega minimax HD with powered hub built in though mostly .


I think perhaps I was discussing using the wifi dongle direct in the Pi ? which is what I would do in a media centre type setup ?

Haven't played with this since last firmware update though ,

thradtke
Posts: 492
Joined: Wed May 16, 2012 5:16 am
Location: Germany / EL

Re: USB - the Elephant in our Room

Mon Aug 27, 2012 5:26 pm

FWIW, my keyboard problems (missed keystrokes, Arduino Leonardo+A500 keyboard) under LXDE (not console) went away after using a different USB hub (Belkin 7-Port). Haven't measured voltage on the USB lines, but the PSU of the old hub gives a constant 5.2 V even under full load.

What to do now? The Belkin is out of discussion because it's used on a different machine and oversized. What to buy? I need a reliable 4-port hub that fits inside the A500 case the Pi is built into. Shouldn't cost a fortune, like the Belkin :?
Rocket Scientist.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5282
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: USB - the Elephant in our Room

Tue Aug 28, 2012 5:37 pm

There is now an sdcard latency fix improvement that should be safer than the "missing_status" one. (Thanks to ddv2005). Can you try adding:
sdhci-bcm2708.enable_llm=1 sdhci-bcm2708.sync_after_dma=0

to cmdline.txt and check if it works okay. It should improve USB/audio latency.

Return to “Troubleshooting”