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.

OMAP-L138: USB Device/Host Role Swap While Running

Part Number: OMAP-L138

Hi,

We're evaluating using the OMAP-L138 in a design that requires both host and device capabilities by the OMAP-L138.

The OMAP seems to be USB OTG capable hardware wise, but after research it seems TI does not have any software supporting this.

With that in mind we thought we could alternately give the user the ability to swap between a USB device using bulk transfers, to a USB host that can read USB flash drives.

Is it possible software wise to swap the role of the OMAP-L138 between these two roles on the fly with TI's USB software libraries?

Meaning the OMAP was currently a bulk USB device, the user then put it into host mode to read a USB Flash drive, and then the user put the OMAP back into USB device mode.

Another less appealing option is that at boot up the device would go into the role the user chose and that couldn't change until next boot up.

Thanks,

Ben

  • Hi Ben,

    Could you help me understand the need to do this in software? It was my understanding that swapping between Host/Device was done automatically through the hardware with the USB ID pin? (Referencing the snippet below from the TRM)

    The USB2.0 controller role adaptation of a host or peripheral (device) is dependent upon the state of the USB0_ID pin on its mini-AB receptacle. If the USB0_ID pin state is not driven by the connector or is left floating, the USB2.0 controller would assume the role of a peripheral; if the USB0_ID pin state is driven low or is grounded, the USB2.0 controller would assume the role of a host. The state of the USB ID pin is controlled by the type of USB plug attached to the mini-AB connector. A mini/micro-B plug (peripheral) would leave the USB0_ID pin floating and a mini/micro-A plug (host) grounds the USB0_ID pin low. The procedure for the USB2.0 controller determining its operating modes (role of a host or a peripheral) starts when the USB 2.0 controller is in session. The USB 2.0 controller is in session when either it senses a voltage on the USB0_VBUS pin or when the firmware sets the DEVCTL[SESSION] bit.

    Usually, the firmware sets the SESSION bit, when it assumes that it will be operating as a host. When the SESSION bit is set, the controller will start sensing the state of the USB0_ID pin. If the USB0_ID pin has been grounded low, then the USB2.0 controller will assume the role of a host; however, if the USB0_ID pin is left floating, then the USB2.0 controller will assume the role of a device. Upon determining its role as a host, it will drive the USB0_DRVVBUS pin high to enable the external power logic so that it start sourcing the required 5V power (must be ≥ 4.75V). The USB2.0 controller will then wait to for the voltage of the USB0_VBUS goes high. If it does not see the power on the USB0_VBUS pin greater than Vbus Valid (4.4V), it will generate an interrupt to the user indicating the existence of a problem. Assuming that the voltage level of the USB0_VBUS is found to be above Vbus Valid, then the USB 2.0 controller will wait for a device to connect, that is, for it to see one of its data lines USB0_DP/DM to be pulled high.


    Regards,
    Sahin

  • Hi Sahin,

    On this project we will be using a USB-C connector, and the OMAP-L138 would act as a host or device depending on what the user has configured it to be.

    My current assumption was that once the USB stack was initialized say as a USB host using the TI USB supported libraries, it would stay in that mode even if plugged into a host computer.  In this scenario nothing useful for our application is going to happen as 2 hosts are plugged into each other.

    In the above scenario the user would have to configure our machine to initialize and use the USB device stack instead of the host stack for anything meaningful to happen.

    We thought of this logic because USB-OTG is not currently supported by TI on the OMAP-L138 software wise.

    Perhaps we will have to review the role of the USB_ID pin and make sure that this logic is doable for our application.

    Thanks,

    Ben