• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 893 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 CDC_ETH Connectivity between OMAP3 and OMAP4 platforms

Kanageswaran R
Intellectual 330 points
Other Parts Discussed in Thread: TPS65950, TPS65930

Hello All,

I am working with a custom OMAP37xx based platform and a custom OMAP4460 based platform.

I need a USB interface (CDC_ETHERNET) between the two - OMAP3 is the device (HSUSB0 port, transceiver on TPS65950) and OMAP4 is the host (USB OTG port configured for host functionality) .

When the OMAP3 device is connected to the OMAP4 platform, kernel prints show that it is detected but it fails to enumerate as a CDC_ETHERNET device.  Please see below for a log of messages.

Other observations:

  • When the USB host port of OMAP4 platform is connected to USB device port an OMAP37xx EVM, it detects, enumerates and I have CDC_ETHERNET functionality between the OMAP4 platform and the OMAP3 EVM
  • When the USB device port of custom OMAP3 platform is connected to a host PC running Linux, they detect, enumerate and I have CDC_ETHERNET functionality between the PC and OMAP3 custom platform.

Any suggestions on what the problem could be or where I need to look at would be extremely helpful.

Thank you very much for your time.

Regards,

Kanagesh

Log Messages when custom OMAP3 platform is connected to the custom OMAP4 platform

musb_stage2_irq 843: SUSPEND (b_idle) devctl 99 power e0
musb_interrupt 1611: ** IRQ peripheral usb0004 tx0000 rx0000
musb_stage0_irq 427: <== Power=f0, DevCtl=99, int_usb=0x4
musb_stage0_irq 686: BUS RESET as b_idle
musb_g_reset 2018: <== B-Device addr=0 driver 'g_ether'
musb_interrupt 1611: ** IRQ peripheral usb0008 tx0001 rx0000
musb_g_ep0_irq 643: csr 0001, count 8, myaddr 0, ep0stage setup
musb_read_fifo 230: RX ep0 fifo fa0ab020 count 8 buf c052bed6
musb_read_setup 577: SETUP req80.06 v0100 i0000 l64
musb_g_ep0_irq 822: handled 0, csr 0001, ep0stage in
musb_g_ep0_queue 928: queue to ep0 (OUT/RX), length=18
musb_write_fifo 171: TX ep0 fifo fa0ab020 count 18 buf dfa47400
musb_g_giveback 142: ep0 done request dfa69d00, 18/18
musb_interrupt 1611: ** IRQ peripheral usb000c tx0000 rx0000
musb_stage0_irq 427: <== Power=f0, DevCtl=99, int_usb=0xc
musb_stage0_irq 686: BUS RESET as b_peripheral
musb_g_reset 2018: <== B-Device addr=0 driver 'g_ether'
musb_g_disconnect 1964: devctl 99
musb_interrupt 1611: ** IRQ peripheral usb0008 tx0001 rx0000
musb_g_ep0_irq 643: csr 0011, count 8, myaddr 0, ep0stage setup
musb_g_ep0_irq 668: SetupEnd came in a wrong ep0stage setup
musb_interrupt 1611: ** IRQ peripheral usb000c tx0000 rx0000
musb_stage0_irq 427: <== Power=f0, DevCtl=99, int_usb=0xc
musb_stage0_irq 686: BUS RESET as b_peripheral
musb_g_reset 2018: <== B-Device addr=0 driver 'g_ether'
musb_g_disconnect 1964: devctl 99
musb_interrupt 1611: ** IRQ peripheral usb000c tx0000 rx0000
musb_stage0_irq 427: <== Power=f0, DevCtl=99, int_usb=0xc
musb_stage0_irq 686: BUS RESET as b_peripheral
musb_g_reset 2018: <== B-Device addr=0 driver 'g_ether'
musb_g_disconnect 1964: devctl 99
musb_interrupt 1611: ** IRQ peripheral usb0008 tx0001 rx0000

  • 0
    TI__Expert 8055 points

    Kanagesh,

    Is my understanding correct that the custom OMAP3 board + custom OMAP4 board  does not work (CDC_Ethernet device not enumerated), but the OMAP3 EVM + custom OMAP4 board, with the same setup, does work?  If that is the case, what are the relevant differences between your custom OMAP3 board and the OMAP3 EVM?  Are there any differences in the setup?  I realize you said that your custom OMAP3 board does work with the PC, so we will need to look at how the differences between your custom OMAP3 board and the OMAP3 EVM affect the connection with OMAP4.

    Thank you,
    Gina 

  • 0 in reply to Gina Glaser
    Intellectual 330 points

    Hello Gina,

    Thank you for your response.

    Yes, you are correct in your understanding.  With the same setup, OMAP3EVM + custom OMAP4 platform works but not the custom OMAP3 platform with the custom OMAP4 platform.  

    I have compared the schematics of the OMAP3 EVM and the custom OMAP3 Platform.  The USB Transceivers used with the OTG (HSUSB0) port of OMAP3 in each is different.  The OMAP3 EVM uses a Philips ISP1507 phy while the custom OMAP3 platform uses the USB transceiver available in the TPS65930 PMIC.  

    I don't see any other difference in the setup between the two.

    Thank you for your time.

    Regards,

    Kanagesh

  • 0 in reply to Kanageswaran R
    TI__Prodigy 460 points

    [TI]  Some offline activity;

    [Kanagesh]

    To summarize, the results from tests we have run are as follows:

    • OMAP4 Custom Platform (USB Host) and OMAP3 EVM (USB Device) - Works with CDC_ETH
    • OMAP4 Custom Platform (USB Host) and OMAP3 custom platform (USB Device) - Does not enumerate as CDC_ETH
    • Host Linux PC (USB Host) and OMAP3 Custom Platform (USB Device) - Works with CDC_ETH
    • OMAP4 Pandaboard (USB Host) and OMAP3 custom platform (USB Device) - Works with CDC_ETH

    [TI]    Some differences;

    The OMAP3 EVM is using a USB hub, sourced from USBB2-ULPI;  OTG from the TPS65950 is not used and not brought out to a connector.

    The Custom OMAP3 board is using OTG from the TPS65930, sourced by USBBA0-ULPI.

    The PandaBoard is also using a Hub for ETH, and two USB ports going to the Expansion connector.  OTG is used from the OMAP and brought out to a Micro-AB connector.  I assume this is the port you are using for testing.

    [Kanagesh]   I am afraid this is not what we tested.  We have tested the connectivity between OMAP4 Panda and custom OMAP3 platform by using the USB Ports on the hub of the Panda.  I realize now that I can configure the OTG port of Panda in Host mode and run the same test (I presume this is the test you expected us to have run).  This would ensure a similar hardware configuration on the Panda as compared to the custom OMAP4 platform.  Let me test this.

     [TI]   The Custom OMAP4 board is using OTG from OMAP, to either a hub or the OTG connector, selected by HUB_ENABLE on U128 switch.  Which mode/port are you using?  If you are using different ports for each test scenario, and not changing HUB_ENABLE, this could be the problem.

    [Kanagesh]    We keep HUB_ENABLE disabled always.  This ensures that the OTG port of OMAP4 is interfaced to the USB hub (always).  The OTG connector is not used.

     [TI]   If this is not the problem, try removing R121 (PMIC VBUS pin pullup to 5v0, not USB VBUS) on the custom OMAP3 board, and connect PMIC VBUS pin directly to VBUS on the USB connector.

    [Kanagesh]     Thank you for this input.  Let me test this too and will update you on the outcome.

    [TI]  If this does not help, then the Custom OMAP4 board and/or the Custom OMAP3 board is missing some software that handshakes with the mate via DP/DM.  (the Linux PC, PandaBoard, OMAP3 EVM work)

    [Kanagesh]

    We have been able to get the custom OMAP3 platform to be detected and enumerated by the custom OMAP4 platform with the change to R121 on the OMAP3 platform as you had suggested.  Thank you very much for your valuable inputs. 

    Forgive me for my ignorance, but I still don't seem to understand why the custom OMAP3 platform worked with the host PC in the first place (with R121 populated).  I ask this because as per my understanding, to the OMAP3 platform, it doesn't matter whether the USB Host is a custom OMAP4 platform or a Host PC.  Further, the VBUS signal on the OMAP3 platform (on which R121 is on) is not brought out to the USB termination that connects to the USB host side.  How has removal of R121 on the OMAP3 platform made the significant difference?

    [TI]

    One of the means for detection and enumeration is by the PMIC sensing a change in capacitance/voltage on VBUS when a cable is connected to the OTG USB connector.  On the custom OMAP3 platform, PMIC_VBUS was connected to 5v0 thru R121 so the PMIC VBUS input would never sense a change and so never generating an interrupt. 

    Another way of detection is the two devices hand shaking thru the DP/DM lines.  This is probably why things worked when connected to the PC, Panda, or EVM, as these devices more than likely have this feature functional, and the custom OMAP4 and custom OMAP3 do not yet have this functional.  I think there may be some patches for that.

    Let me know if this has answered your question and resolved your issue.

    kind regards,

  • 0 in reply to Michael Oehrlein
    Intellectual 330 points

    Hello Mike,

    Thank you for the timely inputs that helped resolve our issues.  

    Regards,

    Kanagesh