I have a unpowered 2-port USB hub that I have connected to the BeagleBone Black (Rev C). I have two (serial over ) USB devices connected to the two port of the USB hub. They are are not powered to begin with. When i power up the Beagle Bone, i see the USB hub listed in the output for ‘lsusb’. Now i power up the two USB device hanging off the USB hub. But i do not see the USB devices listed in the output of ‘lsusb’. Also, there is no /dev/ttyUSB* file. For my project, it wold be ideal for the beagle bone to be powered up before these USB devices. Any idea on what i have messed up or missed?
I have verified that if i connect the USB device directly into the USB port on the beagle bone black, then I can power the USB device after the beagle bone is powered up and it shows up in the output of ‘lsusb’ and i can control the device.
Here are some more specifics about my setup.
I am using the beagle bone black Rev C board.
I am running Debian linux (jessie v 8.3) on the beagle bone black . The version of the linux kernel is v3.8.15 -bone 71.
I am powering the beagle bone with the power supply ( instead of over the USB connector for etherent over USB).
USB is not magic, it needs a specific amount of power on startup to
correctly enumerate a device. By using an un-powered hub, with
multiple downstream devices, as soon as the "first" requests the full
"500mA" vs it's initial "100mA", the other device's chances of being
detected is toast...
I agree with the posts on the power consumption. Depending on the USB devices you are using you might be overloading the power. I’ve experienced this when using SPI devices and USB devices in conjunction. HP makes a very cheap 4 port USB hub with a 2A power supply that you can by through MicroCenter.com for about $5. This fixed my problem. You can probably pull datasheets on all your devices and add up the MAX mA draw. I think the max output on the USB ports for BeagleBoard Black are around 600mA. Some USB devices like a WiFi and Bluetooth adapters in conjunction will consume most of this. I noticed an issue when I actually tried to access my SPI device (another 2.4ghz radio) it would cause USB failure. One last little thing of note. Make sure you’re brick that your USB is powering the BeagleBoard with is rated for at least 1A(2A is better for many devices). Hope this helps.
Note to the moderator - Sorry I tried to post this and sent it blank
I got my hands on a powered USB hub (7 - port DLINK DUB H7). It’s power supply is rated for 5V and 3A. I powered it on. connected my UNPOWERED USB device into the first port of the HUB. Then I turned the bealge bone on. Now i power up my USB device. I still don’t see it in when i do “lsusb”.
I also made sure that if the USB device and the hub are turned on before the beagle bone, then the USB device shows up reliably.
Also, from searching the internet for this kind of issue, someone on some forum suggested keeping a cheap USB stick connected to the USB hub before the beagle bone is turned on. Then if ( another) USB device is connnected to it, it shows up just fine. I tried it and it does work but this solution makes me nervous because i don’t understand why it works.
Another person suggested recompiling the kernel (3.8) without Device Drivers > USB Support > USB runtime power management (autosuspend) and wakeup. I’m working on that…of course finding instruction on how to make a new bootable image (SD card) with my newly built kernel has not been easy. any suggestion on this here?
Thanks everyone for you help! I have solved the issue two different ways
I recompiled the 3.8.13-bone71 linux kernel without without ‘Device Drivers > USB Support > USB runtime power management (autosuspend) and wakeup’. When my beagle bone is running this modified kernel i can power -up my USB devices that are connected using a un-powered Hub AFTER the beagle bone has booted up and I can see them in the OS.
I also just upgraded to the linux kernel version 4.5.0-bone3. In this version, ‘menuconfig’ does not have the
‘Device Drivers > USB Support > USB runtime power management (autosuspend) and wakeup’ configuration setting. But compiling this version of the kernel with the default setting also fixes the issue just like in (1)