USB On The Go

The USB device can switch the host/peripheral role according to the connector type inserted in or by HNP.

USB On-The-Go, often abbreviated USB OTG or just OTG, is a specification that allows USB devices such as digital audio players or mobile phones to act as a host, allowing other USB devices like a USB flash drive, digital camera, mouse, or keyboard to be attached to them. Unlike conventional USB systems, USB OTG systems can drop the hosting role and act as normal USB devices when attached to another host. This can be used to allow a mobile phone to act as host for a flash drive and read its contents, downloading music for instance, but then act as a flash drive when plugged into a host computer and allow the host to read data from the device.

USB On-The-Go and Embedded Host

Virtually every portable device now uses USB for PC connectivity. As these products increase in popularity, there is a growing need for them to communicate both with USB peripherals and directly with each other when a PC is not available. There is also an increase in the number of other, non-PC hosts (Embedded Hosts) which support USB in order to connect to USB peripherals.
The USB On-The-Go and Embedded Host Supplements addresses these scenarios by allowing portable devices and non-PC hosts to have the following enhancements:

• Targeted host capability to communicate with selected other USB peripherals
• Support for direct connections between OTG devices
• Power saving features to preserve battery life

USB On-the-Go Basics

Abstract: USB On-the-Go (OTG) allows two USB devices to talk to each other without requiring the services of a personal computer. Although OTG appears to add "peer to peer" connections to USB, it does not. Instead, USB OTG retains the standard USB host/peripheral model, where a single host talks to USB peripherals. OTG introduces the dual-role device (DRD), capable of functioning as either host or peripheral. Part of the magic of OTG is that a host and peripheral can exchange roles if necessary.

Before OTG, the concept of an embedded host was already established in the USB world. Instead of duplicating the full UHCI/OHCI USB controllers and drivers built into personal computers, most embedded host chips provide limited hosting capabilities. This makes them better suited to the embedded environment than to the PC with its huge resources and infinite capacity for drivers and application software. 

Introduction

USB On-the-Go (OTG) allows two USB devices to talk to each other without requiring the services of a personal computer (PC). Although OTG appears to add peer-to-peer connections to the USB world, it does not. Instead, USB OTG retains the standard USB host/peripheral model, in which a single host talks to USB peripherals. OTG does introduce, however, the dual-role device, or simply stated, a device capable of functioning as either host or peripheral. Part of the magic of OTG is that a host and peripheral can exchange roles if necessary.

Before OTG, the concept of an embedded host was already established in the USB world. Instead of duplicating the full UHCI/OHCI USB controllers and drivers built into PCs, most embedded host chips provide limited hosting capabilities. This makes them better suited to the embedded environment than a PC with its huge resources and infinite capacity for drivers and application software.

An OTG device may, or may not be capable of functioning as a host. It is likely, nonetheless, that most OTG devices will be dual-role.

USB Peripherals

Figure 1 illustrates the basic USB peripheral circuitry on which OTG builds. These example peripherals operate at low or full speed, and are commonly known as USB 1.1 devices. This nomenclature is used even though the USB 2.0 Specification includes the current USB 1.1 specification and introduces a third, higher speed.

Figure 1. A USB peripheral controller and its associated circuitry.

The controller in Figure 1 might be a microprocessor plus USB SIE (Serial Interface Engine), an integrated microprocessor/USB chip, or an ASIC connected to a USB transceiver. A bus-powered peripheral requires a 3.3V regulator, both to power the logic and to supply the proper voltage to a 1500Ω resistor connected to either the D+ or D- USB pins. This pullup resistor signals the host that a device is connected, and indicates the device's operating speed. A pullup to D+ indicates full speed; a pullup to D- indicates low speed. The other end of the connection—host or hub—contains 15kΩ pulldown resistors on D+ and D- so the pullup resistor can be detected. Finally, an ESD protection circuit is advisable on D+, D-, and VBUS pins because USB is designed to be hot-plugged.

How to Be a Host

The Figure 1 circuit functions only as a USB peripheral device. To add OTG dual-role capability, the transceiver must be augmented to allow the OTG device to function as either host or peripheral. Adding the following to Figure 1 lets the system also function as a host:

• 15kΩ pulldown resistors on D+ and D-
• A means to supply, rather than draw, power on VBUS

The ASIC or controller must also contain logic to function as a USB host. Some of the host duties absent in a peripheral device are:

• Send SOF (Start of Frame) packets.
• Send SETUP, IN, and OUT packets.
• Schedule transfers within USB 1ms frames.
• Signal USB reset.
• Provide USB power management.

In addition to requiring a dual-role peripheral/host USB controller, OTG requires additional circuitry to support two new protocols, called HNP and SRP.

Host Negotiation Protocol

An OTG dual-role device can operate either as a host or peripheral. In OTG nomenclature, the initial host is called the A-Device, and the initial peripheral is called the B-Device. The word initial is important. Once connected, OTG dual-role devices can exchange roles—host and peripheral—by using the new Host Negotiation Protocol (HNP). HNP raises two obvious questions: (a) how are the initial roles determined; and (b) why is the role reversal necessary?

Figure 2. Fifth ID pin determines default host.

The cable orientation determines the initial roles (Figure 2). Dual-role devices use a new receptacle called the mini-AB. The mini-A plug, the mini-B plug and the mini-AB receptacle add a fifth pin (ID) to give different electrical identities to the cable ends. This fifth ID pin is connected to ground inside the mini-A plug and left floating in the mini-B plug. The OTG device receiving the grounded ID pin is the default A-Device (host); the device with the floating ID pin is the default B-Device (peripheral).

Figure 3. OTG cable is inserted backwards.

To understand the need for the HNP and host/peripheral role reversal, the example in Figure 3 shows two dual-role devices, a PDA and a printer. The PDA has a printer driver inside. The two devices are connected with the new OTG cable as shown, making the printer the default host (A-Device) and the PDA the default peripheral (B-Device). But this setup is backwards. The PDA, which has the printer driver, needs to act as USB host to the printer, which contains no driver. Rather than bothering the user to reverse the cable, HNP allows the devices' roles to reverse automatically and silently.

Session Request Protocol

The OTG Specification adds a second new protocol to USB, called Session Request Protocol (SRP). SRP allows a B-Device to request an A-Device to turn on VBUS power and start a session.

An OTG session is defined as the time that the A-Device is furnishing VBUS power. (Note: the A-Device always supplies VBUS power, even if it is functioning as a peripheral due to HNP.) The A-Device can end a session by turning off VBUS to conserver power, a very important requirement in a battery-powered device such as a cell phone.

Figure 4. OTG Session Request Protocol (SRP).

Figure 4 shows a common OTG application: two cell phones connected together to exchange information. The right phone received the mini-A end of the cable, making it the A-Device and thus defaulting into the host role. The left phone is the B-Device, defaulting to peripheral. If there is no need to communicate over USB, the A-Device can power down the VBUS wire, which the B-Device can detect so that it too can enter a low-power state.

Now suppose that the user of the left phone presses a button to synchronize address books, or any other action that requires a USB session. The ‘SRP Pulse' block in the left phone pulses first the D+ wire, and then the VBUS wire to wake up the A-Device. (The A-Device can respond either to D+ or VBUS pulsing.) The A-Device then detects the pulse, causing it to switch on VBUS and start a session.

The SRP protocol is more complex than this simple illustration. The B-Device, for example, must first measure VBUS to ensure that a session is not in progress. It must also be able to differentiate between a classic PC or an OTG device at the other end of the cable. It does this by delivering measured amounts of current to the VBUS wire and noting the resulting voltage.

Once a session is underway, the devices may or may not use HNP.

OTG Transceiver

We are now ready to examine the requirements for an OTG transceiver, illustrated in Figure 5.

Figure 5. An OTG transceiver.

The Figure 5 system builds on the Figure 1example circuit. The ASIC block could also be a microprocessor or DSP with USB capability. Three additions make the transceiver OTG compatible:

1. Switchable pull-up and pull-down resistors on D+/D- to allow peripheral or host functionality.
2. Circuitry to monitor and supply 5V power on VBUS as an A-Device, and to monitor and pulse VBUS as a B-Device initiating SRP.
3. An ID input pin, which is made available as an output to the ASIC.

For this system to operate as a dual-role OTG device, the ASIC, DSP, or whatever is connected to the transceiver must be capable both of functioning as a peripheral or host, and of switching roles on-the-fly as a result of HNP.

Most of the added transceiver circuitry manages the VBUS pin, which now must also supply 5V power at 8mA as a host, and perform VBUS pulsing as a peripheral. Analog switches configure the transceiver for the various roles that it must play.

USB On-The-Go connectors

A USB On-The-Go device is required to have one, and only one USB connector: a Micro-AB receptacle. This receptacle is capable of accepting both Micro-A and Micro-B plugs, attached to any of the legal cables and adapters as defined in Micro-USB1.01.

The OTG device with the A-plug inserted is called the A-device and is responsible for powering the USB interface when required and by default assumes the role of host. The OTG device with the B-plug inserted is called the B-device and by default assumes the role of peripheral. An OTG device with no plug inserted defaults to acting as a B-device. If an application on the B-device requires the role of host, then the Host Negotiation Protocol (HNP) is used to temporarily transfer the host role to the B-device.

OTG devices attached either to a peripheral-only B-device or a standard/embedded host have their role fixed by the cable, since in these scenarios it is only possible to attach the cable one way.

Host and Device interface receptacles

The following receptacles accept the following plugs (note that all pin numbers as shown are as per plug; for receptacles numbers as shown are looking from the back out the front; a more typical manufacturer's "top" view into the receptacle would show the pin numbers as mirrored):

Receptacle (images not to scale)	Plug (images not to scale)
	Yes	No	No	No	No
	No	Yes	No	No	No
	No	No	Yes	No	No
	No	No	No	Yes	Yes
	No	No	No	No	Yes

Linux On-The-GO (OTG)

USB OTG support on Linux 2.6 was initially developed by Texas Instruments for OMAP 16xx and 17xx series processors. Other OTG systems should work in similar ways, but the hardware level details could be very different.
Systems need specialized hardware support to implement OTG, notably including a special Mini-AB jack and associated transciever to support Dual-Role operation: they can act either as a host, using the standard Linux-USB host side driver stack, or as a peripheral, using this "gadget" framework. To do that, the system software relies on small additions to those programming interfaces, and on a new internal component (here called an "OTG Controller") affecting which driver stack connects to the OTG port. In each role, the system can re-use the existing pool of hardware-neutral drivers, layered on top of the controller driver interfaces (usb_bus or usb_gadget). Such drivers need at most minor changes, and most of the calls added to support OTG can also benefit non-OTG products.

·         Gadget drivers test the is_otg flag, and use it to determine whether or not to include an OTG descriptor in each of their configurations.

·         Gadget drivers may need changes to support the two new OTG protocols, exposed in new gadget attributes such as b_hnp_enable flag. HNP support should be reported through a user interface (two LEDs could suffice), and is triggered in some cases when the host suspends the peripheral. SRP support can be user-initiated just like remote wakeup, probably by pressing the same button.

·         On the host side, USB device drivers need to be taught to trigger HNP at appropriate moments, using usb_suspend_device(). That also conserves battery power, which is useful even for non-OTG configurations.

·         Also on the host side, a driver must support the OTG "Targeted Peripheral List". That's just a whitelist, used to reject peripherals not supported with a given Linux OTG host. This whitelist is product-specific; each product must modify otg_whitelist.h to match its interoperability specification.

Non-OTG Linux hosts, like PCs and workstations, normally have some solution for adding drivers, so that peripherals that aren't recognized can eventually be supported. That approach is unreasonable for consumer products that may never have their firmware upgraded, and where it's usually unrealistic to expect traditional PC/workstation/server kinds of support model to work. For example, it's often impractical to change device firmware once the product has been distributed, so driver bugs can't normally be fixed if they're found after shipment.

Additional changes are needed below those hardware-neutral usb_bus and usb_gadget driver interfaces; those aren't discussed here in any detail. Those affect the hardware-specific code for each USB Host or Peripheral controller, and how the HCD initializes (since OTG can be active only on a single port). They also involve what may be called an OTG Controller Driver, managing the OTG transceiver and the OTG state machine logic as well as much of the root hub behavior for the OTG port. The OTG controller driver needs to activate and deactivate USB controllers depending on the relevant device role. Some related changes were needed inside usbcore, so that it can identify OTG-capable devices and respond appropriately to HNP or SRP protocols.