• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 1217 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

USB-OTG client mode with DM3730 board and 2.6.37 (from Devkit 2.1 gingerbread)

Jaya Kumar
Expert 1190 points
Other Parts Discussed in Thread: DM3730, DA8XX

Hi friends,

I have a DM3730 based board, similar to Beagle-XM. I'm running 2.6.37 from Devkit 2.1 gingerbread on it. I've started exploring the USB-OTG functionality of the board.

a) USB-OTG host mode (ie: my board is the host, and plugging in things like thumb drives)

- I believe in this mode, the 5th pin, USB ID is grounded by the adapter which is a 5-pin male to 4-pin female adapter. Came with DM355 kit from TI.

- It seems to work fine.

root@localhost:/# cat /sys/devices/platform/musb-omap2430.0/musb-hdrc.0/mode
b_idle

- then plug in the adapter and a usb stick

[ 1016.683441] usb 2-1: new high speed USB device using musb-hdrc and address 2
[ 1016.833068] usb 2-1: device v0204 p6025 is not supported
[ 1016.838623] usb 2-1: New USB device found, idVendor=0204, idProduct=6025
[ 1016.845642] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1016.853088] usb 2-1: Product: Flash Disk
[ 1016.857177] usb 2-1: SerialNumber: 260853000A8C3205
[ 1016.865661] usb 2-1: selecting invalid altsetting 1
[ 1016.871276] scsi0 : usb-storage 2-1:1.0
[ 1017.879577] scsi 0:0:0:0: Direct-Access Flash Disk 5.00 PQ: 0 ANSI: 2
[ 1017.893493] sd 0:0:0:0: [sda] 2009088 512-byte logical blocks: (1.02 GB/981 MiB)
[ 1017.901641] sd 0:0:0:0: [sda] Write Protect is off
[ 1017.906707] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 1017.916717] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 1017.923919] sda: sda1
[ 1017.931091] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 1017.937500] sd 0:0:0:0: [sda] Attached SCSI removable disk

root@localhost:/# cat /sys/devices/platform/musb-omap2430.0/musb-hdrc.0/mode
a_host

So host mode looks good.

b) client mode

- our board is powered from mains so doesn't depended on VBUS from USB-OTG

I'm using a 5-pin male to 4-pin male cable (which I tested works fine with a Beagleboard).

root@localhost:/# cat /sys/devices/platform/musb-omap2430.0/musb-hdrc.0/mode
b_idle

- plug in the cable connected to same PC that was tested to work with beagleboard

- no change seen

root@localhost:/# cat /sys/devices/platform/musb-omap2430.0/musb-hdrc.0/mode
b_idle

- try to force it to be client, no effect

root@localhost:/# echo client > /sys/devices/platform/musb-omap2430.0/musb-hdrc.
0/mode
sh: write error: Invalid argument
root@localhost:/# echo a_client > /sys/devices/platform/musb-omap2430.0/musb-hdr
c.0/mode
sh: write error: Invalid argument

root@localhost:/# cat /sys/devices/platform/musb-omap2430.0/musb-hdrc.0/mode
b_idle

root@localhost:/# cat /sys/devices/platform/musb-omap2430.0/musb-hdrc.0/vbus
Vbus off, timeout 1100

Seems like there is a problem with my board (or possibly with my software) that is causing USB client mode not to work. Since client mode works, my guess is that the problem would have to do with the ID pin. But is there a way I can tell software to force into client mode? I would welcome any debug advice or suggestions.

Thanks,

jayakumar

ps: I checked my config settings and board setup, seem right:

rowboat-android$ egrep -i musb kernel/.config
CONFIG_USB_MUSB_HDRC=y
# CONFIG_USB_MUSB_TUSB6010_GLUE is not set
CONFIG_USB_MUSB_OMAP2PLUS_GLUE=y
# CONFIG_USB_MUSB_AM35X_GLUE is not set
# CONFIG_USB_MUSB_DAVINCI is not set
# CONFIG_USB_MUSB_DA8XX is not set
# CONFIG_USB_MUSB_TUSB6010 is not set
CONFIG_USB_MUSB_OMAP2PLUS=y
# CONFIG_USB_MUSB_AM35X is not set
# CONFIG_USB_MUSB_TI81XX is not set
# CONFIG_USB_MUSB_BLACKFIN is not set
# CONFIG_USB_MUSB_UX500 is not set
# CONFIG_USB_MUSB_HOST is not set
# CONFIG_USB_MUSB_PERIPHERAL is not set
CONFIG_USB_MUSB_OTG=y
CONFIG_USB_GADGET_MUSB_HDRC=y
CONFIG_USB_MUSB_HDRC_HCD=y
# CONFIG_MUSB_PIO_ONLY is not set
CONFIG_MUSB_USE_SYSTEM_DMA_WORKAROUND=y
CONFIG_USB_MUSB_DEBUG=y

rowboat-android$ egrep -i android kernel/.config
CONFIG_ANDROID_PARANOID_NETWORK=y
CONFIG_ANDROID_PMEM=y
CONFIG_USB_ANDROID=y
# CONFIG_USB_ANDROID_ACM is not set
CONFIG_USB_ANDROID_ADB=y
CONFIG_USB_ANDROID_MASS_STORAGE=y
CONFIG_USB_ANDROID_MTP=y
# CONFIG_USB_ANDROID_RNDIS is not set
# Android
CONFIG_ANDROID=y
CONFIG_ANDROID_BINDER_IPC=y
CONFIG_ANDROID_LOGGER=y
CONFIG_ANDROID_RAM_CONSOLE=y
CONFIG_ANDROID_RAM_CONSOLE_ENABLE_VERBOSE=y
CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION=y
CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION_DATA_SIZE=128
CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION_ECC_SIZE=16
CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION_SYMBOL_SIZE=8
CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION_POLYNOMIAL=0x11d
# CONFIG_ANDROID_RAM_CONSOLE_EARLY_INIT is not set
CONFIG_ANDROID_TIMED_OUTPUT=y
CONFIG_ANDROID_TIMED_GPIO=y
CONFIG_ANDROID_LOW_MEMORY_KILLER=y

static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_ULPI,
.mode = MUSB_OTG,
.power = 100,
};

  • 0
    Expert 1190 points

    I noticed that even with beagleboard-XM and ICS from Devkit 3.0 (ICS 4.03), adb via usb-otg only works if the system was booted up with adb enabled. I haven't tried beagleboard-XM with gingerbread and adb yet. I noticed the following kernel output from my dm3730 target that might be relevant:

    [ 6.156707] android init
    [ 6.159454] android_probe pdata: c07578e0
    [ 6.163909] android_bind
    [ 6.166564] android_usb gadget: adding config #1 'android'/c077c3a8
    [ 6.166564] android_bind_config
    [ 6.166595] android_usb gadget: cfg 1/c077c3a8 speeds:
    [ 6.167480] android_usb gadget: android_usb ready
    [ 6.227874] f_adb init
    [ 6.230377] android_register_function adb
    [ 6.234588] adb_bind_config
    [ 6.238250] android_usb gadget: adding 'adb'/cf1270c0 to config 'android'/c077c3a8
    [ 6.238586] android_usb gadget: adb_function_bind dev: cf1270c0
    [ 6.238616] android_usb gadget: create_bulk_endpoints dev: cf1270c0
    [ 6.238647] android_usb gadget: usb_ep_autoconfig for ep_in got ep1in
    [ 6.238647] android_usb gadget: usb_ep_autoconfig for adb ep_out got ep1out
    [ 6.238677] android_usb gadget: dual speed adb: IN/ep1in, OUT/ep1out
    [ 6.242309] android_register_function usb_mass_storage
    [ 6.250213] android_register_function mtp
    [ 8.216888] enabling adb
    [ 8.278717] adb_open
    [ 8.284698] android_usb gadget: adb_read(24)
    [ 8.284729] android_usb gadget: adb_read: waiting for online state

    on the host side, the usb device is not detected, so adb devices is empty.

  • 0 in reply to Jaya Kumar
    Expert 1190 points

    I think I've found the root cause.

    On BBXM, with OTG cable in place at bootup, I see:
    [ 0.059051] twl4030_usb twl4030_usb: HW_CONDITIONS 0xc0/192; link 1

    Same setup with my board, I see:
    [ 0.054473] twl4030_usb twl4030_usb: HW_CONDITIONS 0xc4/196; link 2

    The key parameter, link status is different (0xC0 in working, 0xC4 in failing). So the difference is in bit 2. Looking at the code:

    /*
    * For ID/VBUS sensing, see manual section 15.4.8 ...
    * except when using only battery backup power, two
    * comparators produce VBUS_PRES and ID_PRES signals,
    * which don't match docs elsewhere. But ... BIT(7)
    * and BIT(2) of STS_HW_CONDITIONS, respectively, do
    * seem to match up. If either is true the USB_PRES
    * signal is active, the OTG module is activated, and
    * its interrupt may be raised (may wake the system).
    */
    status = twl4030_readb(twl, TWL4030_MODULE_PM_MASTER,
    STS_HW_CONDITIONS);
    if (status < 0)
    dev_err(twl->dev, "USB link status err %d\n", status);
    else if (status & (BIT(7) | BIT(2))) {
    if (status & BIT(2))
    linkstat = USB_EVENT_ID;
    else
    linkstat = USB_EVENT_VBUS;
    } else
    linkstat = USB_EVENT_NONE;

    dev_dbg(twl->dev, "HW_CONDITIONS 0x%02x/%d; link %d\n",
    status, status, linkstat);

    So it looks like my board is not detecting ID correctly. Looking at page 296, swcu050g.pdf, STS_VBUS and STS_USB seem like they ought to be the same. In my case looks like there is some hardware reason that they are not. I'd welcome any suggestions on a way I could force software to believe that ID is not grounded.