AN65231 USB On-The-Go (OTG) Basics.pdf

USB On-The-Go (OTG) Basics
Author: Narayana Murthy
Associated Project: No
Associated Part Family: CY7C67300/CY7C67200
Software Version: NA
Related Application Notes: None
To get the latest version of this application note, or the associated project file, please visit
This application note discusses several aspects of OTG functionality. The note introduces end-applications and different
types of cables and connectors involved with OTG. It also describes the OTG protocol state changes when both Mini-A
and Mini-B devices are connected .The host negotiation protocol (HNP) and session request protocol (SRP), which are
part of the OTG protocol, are also explained.
Introduction ....................................................................... 1
Cables ............................................................................... 2
Host Negotiation Protocol (HNP) ....................................... 3
Session Request Protocol (SRP) ...................................... 4
SRP-HNP “Shortcut” .................................................... 7
Summary ........................................................................... 8
Worldwide Sales and Design Support ............................. 10
The release of the On-The-Go (OTG) supplement to the
USB 2.0 specification changed the USB world. For the first
time, spec-compliant USB devices can talk to each other
without requiring the services of a host computer.
Cellphones and PDAs can exchange contact lists, phones
can attach to printers and print faxes, and MP3 players
can swap tunes.
To accomplish OTG functionality, a USB device must be
able to function as a host, a role previously served
exclusively by desktop or laptop personal computers.
However, adding host capability to a USB device is only
part of the requirements to operate as an OTG device.
The OTG specification introduces new cables, connectors,
and two new protocols - Session Request Protocol (SRP)
and Host Negotiation Protocol (HNP).
Additionally, the OTG specification defines a new type of
USB device with both host and peripheral capabilities
called a “dualrole device”. This application note covers the
electrical and protocol aspects of OTG, providing
information that should make it easier to read and
understand the formal OTG Specification.
Document No. 001-65231 Rev. *B
USB On-The-Go (OTG) Basics
Figure 4. Two New OTG Cables
Figure 1. Standard USB A-B Cable
Two new cables and two adapters are defined in the OTG
specification. Figure 1 shows the traditional A and B
connectors, and the standard A-to-B cable that connects
USB peripherals to PC hosts. Following the Figure 1
model, the OTG specification refers to hosts as “A”
devices and peripherals as “B” devices.
In October 2000, the mini-B receptacle and plug were
incorporated as standard USB components to allow
portable equipment such as digital cameras and MP3
players to use a smaller connector than the relatively large
“B” receptacle (see Figure 2).
Figure 2. Standard USB Mini-B Receptacle and Plug
OTG introduces a new receptacle, the mini-AB, which
accepts either the standard USB mini-B plug or a new
OTG plug, the mini-A (Figure 3). Fortunately, OTG was
anticipated when the mini-B receptacle and plug were
defined. Therefore, a mini-B plug mates with the new
mini-AB receptacle. As Figure 3 illustrates, a camera with
the new OTG mini-AB receptacle is a direct substitute for
the camera with the mini-B connector in Figure 2.
The top cable allows a new OTG device to talk as a host
to a traditional USB peripheral. The bottom cable allows
two OTG devices to talk to each other.
In the Figure 4 camera-to-camera connection, both
dual-role cameras provide mini-AB receptacles. Therefore,
each must function either as host or peripheral. This raises
the obvious question of which is the host and which is the
peripheral at connection. The OTG spec resolves this
question in a very simple manner: the cable decides.
OTG receptacles and plugs contain a fifth pin, added to
the standard four USB pins (VBUS, GND, D+, and D–).
This is a fifth pin in the connector, not a fifth wire in the
cable. The mini-A plug has the fifth pin tied to its ground
pin, and the mini-B plug leaves the fifth pin unconnected.
A dual-role device requires circuitry to read the state of
this fifth pin (with, for example, the aid of a pull-up resistor)
to determine which end of the cable is inserted.
The dual-role device receiving the mini-A plug is the
default host. To understand why the word “default” is
important, see the following figure.
Figure 5. Backwards Cable Connection
Figure 3. New OTG Mini-AB Receptacle
In Figure 5, two dual-role devices are connected with a
mini-A to mini-B cable. The camera contains a printer
driver. However, the mini-A end of the cable is connected
to the printer, making it the default host. This will be
backwards - the camera must be the host in order to print.
As its name implies, the mini-AB receptacle accepts either
the standard mini-B plug, or a new OTG plug, the mini-A.
Two new OTG cables are defined, the mini-A to B, and the
mini-A to mini-B (see Figure 4).
The OTG architects put a lot of though into the user
experience. Realizing that the Figure 5 connection is
possible, they invented the HNP to allow two connected
dual-role devices to exchange roles. Using HNP, the
camera in Figure 5 can assume the host role, even though
the initial cable connection established the printer as the
default host (A-Device). This saves (a) informing the user
of a nonworkable connection, and (b) making the user
remove the cable and plug it in “the other way”.
Document No. 001-65231 Rev. *B
USB On-The-Go (OTG) Basics
For an orderly startup, one of the devices must be the
“initial” (default) host, a role established by the cable. After
connection, the devices can use HNP to exchange roles.
Note Dual-role devices must operate at full speed
(high-speed optional) as a peripheral. Dual-role devices
must operate at full speed (low- and high-speed optional)
as a host.
At some point, the application running on the A-device no
longer needs to use the B-device. At this point, the
A-device must give the B-device an opportunity to be the
host. There are prerequisites to this benevolence:
When the A-device enumerated the B-device, the
B-device must returns an OTG descriptor indicating
that it is capable of supporting HNP. The B-device
includes this descriptor in its response to the
Get_Descriptor(Configuration) request.
The A-device enables the B-device for HNP by
sending an OTG-specific Set_Feature request (with
feature selector, “b_hnp_enable”).
Figure 6. HNP Simplified and Combined State Diagram
The application running on the A-device starts the HNP
ball rolling by negating an internal signal called
“a_bus_req”, indicating that it does not need to use the
bus. To give the B-device a window of opportunity to
become host, the A-device suspends the bus (a_suspend
state). The A-device suspends the bus according to
standard USB protocol, that is, by stopping all bus traffic
for at least 3 ms. Since the A-device still operates as the
host, its pull-down resistors remain on.
Host Negotiation Protocol (HNP)
The OTG specification provides an individual A-device and
B-device state diagrams to illustrate how dual-role devices
function. The state diagram shown in Figure 6 is derived
from these state diagrams. Figure 6 combines the
A- and B-device behaviors into one simplified diagram,
which contains the states relevant to HNP. The A-device is
on the left, and the B-device is on the right. As in the OTG
spec, state names with the “a_” prefix pertain to the
A-device, and state names with the “b_” prefix pertain to
the B-device. The Figure 6 state names and the italicized
signal names are taken directly from the OTG
specification. The added “PU” ovals indicate connection of
the D+/D– pull-up resistor, and the “PD” ovals represent
connection of the 15-kΩ pull-down resistors on D+ and D–.
Initial conditions are the A-device operating as host
(a_host state) and the B-device operating as a peripheral
(b_peripheral state). As a host, the A-device has its
pull-down resistors turned on, and as a peripheral the
B-device has its pull-up turned on. In this state, the
A-device performs all the normal host duties, including bus
reset, generating SOF packets, enumerating the B-device,
and suspend-resume.
The B-device, sensing that the bus is inactive, now tries to
become the host. If the B-device is HNP-capable and the
B-device has HNP-enabled, and the B-device detects that
the A-device has suspended the bus, and the application
running on the B-device wants to request the bus
(b_bus_req signal), then the B-device transitions to the
b_wait_acon state. This means “the B-device waits for the
A-device to connect”. In this state the B-device
“disconnects” by turning its pull-up resistor off and turning
its pull-down resistors on. Because neither side is driving
the bus, the put-downs cause D+ and D– to go LOW, a
condition known as a single-ended - zero (SE0).
After “disconnecting,” the B-device waits in the
b_wait_acon state for the A-device to “connect” as a
peripheral. The A-device, which is in the a_suspend state,
detects the SE0, and transitions to a peripheral state,
where it “connects” as a peripheral in the normal USB
way, by powering its D+ pull-up resistor. This connection
creates a J-state on the bus, which the B-device detects
as an A-device peripheral connect event. This causes the
B-device to transition to the b_host state, and the role
reversal is complete.
Going the opposite way, from A-peripheral/B-host back to
A-host/B-peripheral, is very similar. The B-device
suspends and the A-device disconnects.
The OTG specification imposes timing constraints on the
state transitions. For example, the A-device must make its
transition from a_suspend to a_peripheral within 3 ms of
detecting an SE0 on the bus. After it enters the
a_peripheral state, it must maintain its connected state for
at least 3 ms to give the B-device time to respond and
generate a bus reset. The B-device has 1 ms to detect
and respond to the A-device connect, so the 3-ms holding
time insures 2 ms of margin.
Document No. 001-65231 Rev. *B
USB On-The-Go (OTG) Basics
The simplified Figure 6 state diagram omits many details
for clarity. It shows the normal progression of events for a
successful HNP role switch. The OTG specification also
covers the “else” conditions such as a mid-HNP cable
The OTG state diagrams use “timer variables” to resolve
some signaling issues. For example, in the b_wait_acon
state, the B-device waits for a J-state on the bus,
signifying that the A-device has connected as a peripheral.
When the B-device is in its b_wait_acon state, the
A-device is in its a_suspend state. Therefore, neither side
drives the bus, resulting in a SE0 bus state. However, a
SE0 can also represent a USB bus reset, if it is held for 10
ms. Therefore the B-device must revert to the b_peripheral
state if, while in the b_wait_acon state, it does not detect a
J-state within 3.125 ms.
Session Request Protocol (SRP)
The OTG specification contributes a new mechanism that
allows an A-device to turn off VBUS as a power saving
measure. From this state, a B-device can wake up the
A-device by asking it to turn on VBUS and start a new
session. This mechanism is called session request
protocol (SRP).
The relationship between SRP and HNP can be
summarized as follows:
Dual-role devices are required to be able to initiate
and respond to SRP.
The A-device always provides VBUS. Even if two
dual-role devices use HNP to make the B-device a
host and the A-device a peripheral, the A-device still
supplies VBUS.
Non dual-role devices, which are inherently incapable
of HNP, may still initiate SRP. For example, a mouse
with an internal battery can request a session from a
dual-role device.
Figure 7. An OTG A-Device Powering VBUS
An OTG dual-role device must have a power decoupling
capacitor that is in the range of 1.0 to 6.5 μF (see
Figure 7). This is a departure from a classic host, which
has a minimum VBUS capacitance of about 95 μF (this
value takes capacitor tolerance into effect). This large
capacitance difference allows the SRP VBUS pulsing
method to be recognized by a dual-role device while
causing no damage if the B-device plugs into a standard
An A-device must be able supply at least 8 mA of VBUS
current at 4.4 V, the minimum voltage necessary to
guarantee proper B-device operation. A voltage
comparator with a 4.4 V (minimum) threshold in the
A-device provides a signal called a_vbus_valid. The spec
requires a_vbus_valid to be true within 100 ms after the
A-device turns on VBUS.
Note that if a_vbus_valid does not go TRUE within
100 ms, this implies that the B-device is drawing more
current that the A-device can supply. Therefore, the
A-device turns off VBUS and terminates the session.
An unpowered A-device must present an input impedance
less than 100 kΩ. If the device is designed to respond to
the VBUS pulsing method, the input impedance must be at
least 40 kΩ (Figure 8).
Figure 8. Load Presented by an Unpowered A-Device
A “session” is defined as the period of time during which
VBUS is on, or more particularly, VBUS is above a
device’s “session valid” threshold voltage.
B-devices use two methods to request a session: data line
pulsing followed by VBUS pulsing. A-devices are required
to respond to one of the two signaling methods, but a Bdevice must use both methods to insure that any A-device
recognizes it.
B-devices perform data line pulsing by powering their
D+/D– pull-up resistor for 5 to10 ms. Dual-role devices
must use the D+ pull-up. B-devices perform VBUS pulsing
by driving VBUS. Driving power on to a wire connected to
an “off” power source (in the A-device) obviously requires
some care. The following discussion illustrates the
important factors by working through a simplified example,
pointing out the important OTG spec issues.
Document No. 001-65231 Rev. *B
USB On-The-Go (OTG) Basics
Before starting SRP, the B-device must first ensure that
VBUS is low enough that a SRP-capable A-device is
below its session valid threshold (0.8V min.). One way to
do this is simply to wait for the pull-down resistors to
discharge the bypass capacitors. If two dual-role devices
are connected, then the weakest pull-down is the parallel
combination of two 100-K resistors, and the maximum
capacitance is 2*6.5 μF. Using these worst-case values
leads to the longest discharge time being approximately
1.1 seconds.
The B-device may speed this discharge by connecting a
resistor from VBUS to ground. Because the maximum
current the B-device may draw is 8 mA, the minimum
resistance to ground is 5.25 V / 8 mA = 656 Ω. The R-C
(656 Ω)(13 μF) = 8.5 ms. The VBUS capacitance can
discharge from 5.25 V to 0.8 V in 1.88 time constants, or
16 ms.
Note The 5.25-V starting voltage is conservative because
the B-device may not initiate SRP until VBUS has dropped
below its session threshold of 4.4 V (max).
As an alternative to timing the discharge, the B-device
may use a 0.8-V “session end” comparator to directly
measure VBUS (Figure 9).
Figure 9. B-Device Pulses VBUS to Wake Up A-Device
Two factors determine how long the B-device should pulse
VBUS. The pulse width must be:
Long enough to guarantee that the maximum
capacitance of two dual-role devices (13 μF) is
charged to at least 2.1 V.
Short enough to guarantee that the capacitance of a
legacy host (95 μF) is not driven above 2.0 V.
The designer of the B-device knows the current limit of its
VBUS charging circuit. Using the example circuit of
Figure 9 with the maximum capacitance values, and
ignoring the pull-down resistors, one R-C time constant is
approximately: RC = 281 * 13 μF = 3.6 ms
A discharged R-C network reaches 0.950 of its driving
voltage after three time constants. Using the minimum
VCC of 3.0 V, driving VBUS for three time constants
(10 ms) raises the voltage by 3 V*.95 or 2.85 V, which is
above the required 2.1 V spec value (so the first condition
is met).
Note Ten milliseconds is a conservative charging time. It
takes 1.2 time constants to charge from 0.0 V to 2.1 V with
a 3-V supply. Ignoring component tolerances, and using
the 3.6-ms time constant, charging from 0 V to 2.1 V takes
3.6*1.2 = 4.4 ms. Nevertheless, we use the more
conservative 10 ms value for the example calculation.
The next step is to check the effect of this pulse when the
B-device is plugged into a standard USB host.
Assume that the B-device has a session-end comparator,
as in Figure 9. In the OTG spec, the output of this
comparator is the signal b_session_end. The B-device
may either wait 1.1 seconds, or pull down VBUS through a
resistor (for example a 656-Ω resistor for 16 ms) to try to
pull VBUS below 0.8 V. If the attempt fails (b_session_end
is not TRUE), the B-device can deduce that it is either:
Having determined that VBUS is under 0.8 V, the B-device
may attempt to wake up the A-device by pulsing VBUS.
The example circuit in Figure 9 shows a 281 Ω currentlimiting resistor, whose value is calculated to guarantee
that the unconfigured B-device never draws more than the
OTG-specified 8 mA, as follows. The worst-case current
draw occurs when a the A-device turns on VBUS while the
B-device is still signaling SRP, and the B-device VCC is
the minimum 3.0 V, causing the largest voltage difference
between the devices. The minimum series resistance
required to limit the current flowing into the B-device is
derived as follows:
Not connected to a dual-role device (whose VBUS
discharges below 0.8 V due to its much smaller
It is plugged into an A-device that is driving VBUS.
The first case happens if the standard host had very
recently powered down, leaving a residual voltage on its
VBUS capacitor(s). In either case, the B-device should go
to the b_peripheral state, where it cannot initiate SRP until
its session_valid variable goes FALSE.
(5.25 V – 3.0 V) / 8 mA = 281 Ω
Document No. 001-65231 Rev. *B
USB On-The-Go (OTG) Basics
Pulsing a VBUS capacitance of 96 uF through a 281-Ω
resistor for the computed 10 ms raises the capacitor
voltage by:
Figure 11. SRP Simplified and Combined State Diagram
Vc = (3.6 V – 0.8 V) (1-e-t/RC) =
0.87 V
Since the assumption is a worst-case initial VBUS voltage
of 0.8 V, the resulting voltage across the VBUS
capacitance is
0.8 V + 0.87 V = 1.67
below the 2.0 V limit.
Note that if the B-device tested for end-of-session by
connecting a 656-Ω resistor to ground for 16 ms (as in this
example), the voltage on the capacitor initially decreased
by 1.82 V before the B-device applied the VBUS pulse.
Therefore, the pulse does not raise VBUS above its
starting value.
As long as the design ensures that more charge is
removed than added to the VBUS decoupling capacitance
by a VBUS pulse, a standard USB host is unaffected and
undamaged by the pulse.
This discharge-before-charge sequence allows a cost
sensitive B-device to replace the session-end comparator
with a simple gate, as shown in Figure 10. In this case the
B-device must time the discharge of the VBUS capacitor
as previously describe because it cannot precisely
measure 0.8 V. Before pulsing VBUS, the B-device must
insure that the b_session_valid variable is FALSE,
whatever the threshold voltage of the gate is. Since the
detection method involves a discharge mechanism for the
VBUS capacitance prior to pulsing VBUS, the designer
can insure that no net voltage increase occurs on VBUS
and, therefore, that the VBUS pulse does not inadvertently
trip the B-device’s session-valid threshold.
To help understand the A and B-device interactions while
performing SRP, the state diagram in Figure 11 simplifies
and combines the OTG specification A-device and
B-device state diagrams.
Figure 10. A Cost-Sensitive B-Device
After these conditions are met, the application running on
the B-device can indicate that it wants to use the bus (to
signal a wakeup) by asserting the b_bus_req signal,
causing the B-device to transition to the b_srp_init
metastate. (A “metastate” is a state containing other states
or behaviors; in this example, the b_srp_init state contains
the data-pulsing and VBUS pulsing methods described
Before starting a new session, the B-device must insure
that two initial conditions are valid:
No session is in progress (VBUS < 0.8 V)
While in the b_idle state (which disconnects the
B-Device’s pull-up resistor, creating an SE0 on the
bus), the bus must have been in the SE0 state for at
least 2 ms.
The A-device must be in its a_idle state to detect the
B-device attempting to initiate SRP, and when it sees the
a_srp_det variable go true, it turns on VBUS and
transitions to the a_wait_vrise state, where it waits for
VBUS to reach a valid level (4.4 V minimum). The
B-device, having finished its SRP signaling, transitions
back to its b_idle state, where it waits for the A-device to
indicate a valid session.
Document No. 001-65231 Rev. *B
USB On-The-Go (OTG) Basics
Meanwhile, back at the A-device, when VBUS reaches its
session threshold voltage (4.4 V), it transitions to its
a_wait_bcon state, where it waits for the B-device to
“connect” by turning on its pull-up resistor. The B-device,
sensing that VBUS has exceeded its session valid
threshold voltage (0.8 V–4.0 V), transitions to the
b_peripheral state. Here it turns on its data pull-up
resistor. The A-device senses this as the b_conn signal,
which, after adequate debounce time of the data line,
causes a transition to a_host. The A-device operates in its
a_host metastate, exhibiting all host behavior, and the Bdevice operates in its b_peripheral metastate, exhibiting all
peripheral behavior.
At some point, the A-device is done with the session. One
of the many possible definitions of “done” is that the
A-device batteries are dangerously low. In this particular
case, since the A-device cannot continue to power VBUS
and allow the B-device to become host, the A-device turns
off VBUS and transitions to a_wait_fall. The B-device, also
sensing the drop in VBUS as it drops below the B-device’s
session-valid threshold (0.8 V–4.0 V), transitions back to
its b_idle state.
The second requirement avoids a subtle race condition. If
the A-device made its transition to a_idle before the
B-device turned off its pull-up resistor (indicating that the
B-device knows its session is over), the A-device finds a
data line high and thinks the B-device (again) signals
SRP, and immediately transitions to the a_wait_vrise
SRP-HNP “Shortcut”
An interaction between SRP and HNP is worth noting. To
save time, the A-device can just come on and send a
SetFeature (b_hnp_enable) request. If the B-device does
not STALL, then the B-device is HNP-capable and the
A-device can immediately suspend and start HNP. This is
especially useful if the B-device did SRP because it gains
control quickly. If the B-device did SRP but STALLS the
SetFeature (b_hnp_enable) request, it is a peripheral-only
device and the A-device goes ahead and enumerates it.
The A-device waits in its a_wait_vfall state until two
requirements are met:
VBUS has dropped below the A-device’s session-valid
The B-device has indicated its session is over by
disconnecting its data pull-up resistor (the variable
b_conn is FALSE).
Document No. 001-65231 Rev. *B
USB On-The-Go (OTG) Basics
Although the example design presented in this note uses
simplified diagrams and values, the example calculations
and state diagrams should aid the understanding of what
constitutes a spec-compliant OTG device. The
background information presented in this note helps
readers navigate the parameters and state diagrams in the
OTG specification.
Document No. 001-65231 Rev. *B
USB On-The-Go (OTG) Basics
Document History
Document Title: USB On-The-Go (OTG) Basics - AN65231
Document Number: 001-65231
Orig. of
Description of Change
Created spec number and updated template for an old application note that was
there on the website.
No technical updates.
Completing Sunset Review.
Updated in new template.
Document No. 001-65231 Rev. *B
USB On-The-Go (OTG) Basics
Worldwide Sales and Design Support
Cypress maintains a worldwide network of offices, solution centers, manufacturer’s representatives, and distributors. To find
the office closest to you, visit us at Cypress Locations.
PSoC® Solutions
Clocks & Buffers
PSoC 1 | PSoC 3 | PSoC 4 | PSoC 5LP
Lighting & Power Control
Touch Sensing
USB Controllers
Cypress Developer Community
Community | Forums | Blogs | Video | Training
Technical Support
PSoC is a registered trademark of Cypress Semiconductor Corp. All other trademarks or registered trademarks referenced herein are the property of
their respective owners.
Cypress Semiconductor
198 Champion Court
San Jose, CA 95134-1709
: 408-943-2600
: 408-943-4730
© Cypress Semiconductor Corporation, 2010-2014. The information contained herein is subject to change without notice. Cypress Semiconductor
Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in a Cypress product. Nor does it convey or imply any
license under patent or other rights. Cypress products are not warranted nor intended to be used for medical, life support, life saving, critical control or
safety applications, unless pursuant to an express written agreement with Cypress. Furthermore, Cypress does not authorize its products for use as
critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The
inclusion of Cypress products in life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies
Cypress against all charges.
This Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress) and is protected by and subject to worldwide
patent protection (United States and foreign), United States copyright laws and international treaty provisions. Cypress hereby grants to licensee a
personal, non-exclusive, non-transferable license to copy, use, modify, create derivative works of, and compile the Cypress Source Code and derivative
works for the sole purpose of creating custom software and or firmware in support of licensee product to be used only in conjunction with a Cypress
integrated circuit as specified in the applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source
Code except as specified above is prohibited without the express written permission of Cypress.
right to make changes without further notice to the materials described herein. Cypress does not assume any liability arising out of the application or
use of any product or circuit described herein. Cypress does not authorize its products for use as critical components in life-support systems where a
malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress’ product in a life-support systems
application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges.
Use may be limited by and subject to the applicable Cypress software license agreement.
Document No. 001-65231 Rev. *B