Legacy Forum: Preserving Nearly 20 Years of Community History - A Time Capsule of Discussions, Memories, and Shared Experiences.

IGEP Module: OTG host mode while powered from USB Hub

Custom built or hacked Electronic boards and sensors
3 postsPage 1 of 1
3 postsPage 1 of 1

IGEP Module: OTG host mode while powered from USB Hub

Post by limor » Sat Nov 20, 2010 4:15 pm

Post by limor
Sat Nov 20, 2010 4:15 pm

I would like the IGEP to act as USB Host while being powered by a USB hub. This will allow other devices to be attached to the USB hub and be powered by it so everyone gets powered by the USB hub happily and the hub gets powered by a LiPo battery and the whole thing is tucked neatly into a robot.

However, USB OTG works either in Host (Master) mode and tries to power the attached USB device, or works in Client (Slave or Device) mode which allows it to be powered from the attached Host.

If USB Pin4 (of the mini-AB connector) is grounded then the OMAP cpu knows it is supposed to be a USB host and doesn't allow power to come in from the USB hub. So the module doesnt power up.

If USB Pin4 is not connected (as in the case of a mini-B connector), then OMAP allows the hub or other computer to power the IGEP.

Kind of catch 22 situation. So we googled around and found that some people have tricked the Nokia N800 and Beagle Board to boot up as USB Slave but then got the operating system to act on the USB OTG link as a Host by entering the following line:

echo host > /sys/devices/platform/musb_hdrc/mode


So this is the plan.

But before attempting it we had a few hurdles.
A) WiFi ssh access -- the IGEP module has only the OTG usb connector on board that is accessible without a daughter board. We got to talk to the module from Windows7 and configured its wifi to connect to the local network and then the plan is to disconnect it from the Windows7, power it from the USB hub and ssh to it via WiFi since it will be connected to the hub as a host, not a client, there will be no way to create a virtual network over USB.. so the only way to talk to the module once disconnected from Windows7 is via Wifi. (this was documented in a separate thread)

B) Regulated power supply -- powering the hub (that powers the IGEP module) from a cheap 5V 1.5A DC power supply did not provide enough current to allow the IGEP to work continuously with wifi. The symptoms were that the module was booting and we had configured it to work with the local wifi network and it was responding to ping most of the time. But any attempt to ssh to the module via wifi resulted in the module rebooting. So we used a DC-DC converter regulator and fed it with a 12V 5A power source (Bioloid power supply). This stopped the strange reboots.

Here is the setup:

Image

Here is a closeup of the DC-DC level shifter converter regulator. The 2 resistors there in series form together resistance close enough to the datasheet's 1.34k ohm needed to output 5V



Image

The power comes to the IGEP module from one of the Client ports while Pins 2 and 3 are attached to the Host data port pins. The connector attached to the module is a mini-B in order not to have Pin4 grounded which would prevent the module from even powering up.

Image
Image

As of Friday afternoon, we didn't get this to work the first time and needed to leave the office. We'll continue Monday morning and hopefully get the module to be a USB host while being powered from the USB hub..
I would like the IGEP to act as USB Host while being powered by a USB hub. This will allow other devices to be attached to the USB hub and be powered by it so everyone gets powered by the USB hub happily and the hub gets powered by a LiPo battery and the whole thing is tucked neatly into a robot.

However, USB OTG works either in Host (Master) mode and tries to power the attached USB device, or works in Client (Slave or Device) mode which allows it to be powered from the attached Host.

If USB Pin4 (of the mini-AB connector) is grounded then the OMAP cpu knows it is supposed to be a USB host and doesn't allow power to come in from the USB hub. So the module doesnt power up.

If USB Pin4 is not connected (as in the case of a mini-B connector), then OMAP allows the hub or other computer to power the IGEP.

Kind of catch 22 situation. So we googled around and found that some people have tricked the Nokia N800 and Beagle Board to boot up as USB Slave but then got the operating system to act on the USB OTG link as a Host by entering the following line:

echo host > /sys/devices/platform/musb_hdrc/mode


So this is the plan.

But before attempting it we had a few hurdles.
A) WiFi ssh access -- the IGEP module has only the OTG usb connector on board that is accessible without a daughter board. We got to talk to the module from Windows7 and configured its wifi to connect to the local network and then the plan is to disconnect it from the Windows7, power it from the USB hub and ssh to it via WiFi since it will be connected to the hub as a host, not a client, there will be no way to create a virtual network over USB.. so the only way to talk to the module once disconnected from Windows7 is via Wifi. (this was documented in a separate thread)

B) Regulated power supply -- powering the hub (that powers the IGEP module) from a cheap 5V 1.5A DC power supply did not provide enough current to allow the IGEP to work continuously with wifi. The symptoms were that the module was booting and we had configured it to work with the local wifi network and it was responding to ping most of the time. But any attempt to ssh to the module via wifi resulted in the module rebooting. So we used a DC-DC converter regulator and fed it with a 12V 5A power source (Bioloid power supply). This stopped the strange reboots.

Here is the setup:

Image

Here is a closeup of the DC-DC level shifter converter regulator. The 2 resistors there in series form together resistance close enough to the datasheet's 1.34k ohm needed to output 5V



Image

The power comes to the IGEP module from one of the Client ports while Pins 2 and 3 are attached to the Host data port pins. The connector attached to the module is a mini-B in order not to have Pin4 grounded which would prevent the module from even powering up.

Image
Image

As of Friday afternoon, we didn't get this to work the first time and needed to leave the office. We'll continue Monday morning and hopefully get the module to be a USB host while being powered from the USB hub..
limor
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1845
Joined: Mon Oct 11, 2004 1:00 am
Location: London, UK

Post by tinmarok » Sun Nov 21, 2010 5:57 pm

Post by tinmarok
Sun Nov 21, 2010 5:57 pm

Hello limor,

I can't decide for the board i'll embed into the khr3hv. I was decided for the IGEPv2 for the price/all-in-one aspect. The IGEP module was my first choice but the power supply was an issue for me. What a surprise when i found your post today, if u succeed in your solution i think the igep module will be my solution too:)))
Hello limor,

I can't decide for the board i'll embed into the khr3hv. I was decided for the IGEPv2 for the price/all-in-one aspect. The IGEP module was my first choice but the power supply was an issue for me. What a surprise when i found your post today, if u succeed in your solution i think the igep module will be my solution too:)))
tinmarok
Robot Builder
Robot Builder
Posts: 8
Joined: Wed Sep 22, 2010 7:14 pm

Post by limor » Wed Nov 24, 2010 2:42 am

Post by limor
Wed Nov 24, 2010 2:42 am

spent the last few nights trying to force the module's OTG port to behave as a USB host but getting nowhere. currently going through the kernel module source code but no solution in sight.

Here is some progress that we've managed to do.

1) Module can boot from micro-sd card.
The easiest way to do this is to get access to a Linux machine either through VirtualBox.org or pendrivelinux.com and then follow instructions on IGEP wiki.

2) Modularizing all relevant drivers.
The default kernel is configured as USB Gadget with RNDIS ethernet over USB. Since there is no debug serial port, the USB is the only way to see what is going on. So all experiments with new kernels have to be done while the g_ether module is intact. Once a new kernel is running and there is access to the module via wifi, it can be disconnected from the PC and connected to the hub as described above. By default the USB OTG modules are compiled into the kernel but since we would like to control them and turn then on and off, they need to be loadable modules.
- Follow procedure to create a micro-sd card with minimal Linux
- Install Poky toolchain
- download kernel source code
- edit the config file (make menuconfig) and change "*" to "M" where relevant
- install new uImage and modules on sd card
- add module names to /etc/modutils/ and run update-modules which will write to /etc/modules ; necessary modules for wifi and usb/ethernet include: libertas libertas_sdio g_ether musb_hdrc rfcomm
- remove /lib/modules/2.6.35.2.3/modules.dep (when the board boots it /etc/init.d/modutils.sh will run depmod and recreate it properly). [ the make install_modules after kernel recompilation attempts to create the file but doesnt do a good job.]

So we have everything in modules and can uninstall the USB/Ethernet and reset the musb_hdrc driver that supposedly drives the OTG port. but so far it seems to always stick with being type B (client) and will not become hsot :(
spent the last few nights trying to force the module's OTG port to behave as a USB host but getting nowhere. currently going through the kernel module source code but no solution in sight.

Here is some progress that we've managed to do.

1) Module can boot from micro-sd card.
The easiest way to do this is to get access to a Linux machine either through VirtualBox.org or pendrivelinux.com and then follow instructions on IGEP wiki.

2) Modularizing all relevant drivers.
The default kernel is configured as USB Gadget with RNDIS ethernet over USB. Since there is no debug serial port, the USB is the only way to see what is going on. So all experiments with new kernels have to be done while the g_ether module is intact. Once a new kernel is running and there is access to the module via wifi, it can be disconnected from the PC and connected to the hub as described above. By default the USB OTG modules are compiled into the kernel but since we would like to control them and turn then on and off, they need to be loadable modules.
- Follow procedure to create a micro-sd card with minimal Linux
- Install Poky toolchain
- download kernel source code
- edit the config file (make menuconfig) and change "*" to "M" where relevant
- install new uImage and modules on sd card
- add module names to /etc/modutils/ and run update-modules which will write to /etc/modules ; necessary modules for wifi and usb/ethernet include: libertas libertas_sdio g_ether musb_hdrc rfcomm
- remove /lib/modules/2.6.35.2.3/modules.dep (when the board boots it /etc/init.d/modutils.sh will run depmod and recreate it properly). [ the make install_modules after kernel recompilation attempts to create the file but doesnt do a good job.]

So we have everything in modules and can uninstall the USB/Ethernet and reset the musb_hdrc driver that supposedly drives the OTG port. but so far it seems to always stick with being type B (client) and will not become hsot :(
limor
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1845
Joined: Mon Oct 11, 2004 1:00 am
Location: London, UK


3 postsPage 1 of 1
3 postsPage 1 of 1