How Do You Implement USB OTG (On-The-Go) in an Embedded Product?

Detailed Explanation

USB OTG (On-The-Go) is a supplement to the base USB specification that lets a device operate as either a limited USB host or a USB peripheral, depending on what it's connected to — rather than being permanently fixed as one or the other. This matters for embedded products that need to both act as a peripheral (connecting to a PC for configuration or firmware updates) and act as a host (reading a USB flash drive, talking to a USB keyboard or barcode scanner, or driving another USB accessory) from the same port. For USB's general protocol fundamentals — descriptors, device classes, enumeration — see What Is USB?; this page covers the additional hardware and firmware work OTG specifically requires.

What OTG Actually Adds to USB

A standard USB device is permanently a peripheral; a standard USB host (a PC) is permanently a host. OTG defines a third category — a dual-role device — that can be either, and terminology to describe each side of a connection:

• A-device — the device that initially takes the host role and sources VBUS power.
• B-device — the device that initially takes the peripheral role and draws power from VBUS.

Which role a given physical device starts in is determined at connection time, not fixed permanently in the product — the same embedded product can be an A-device in one session (hosting a USB drive) and a B-device in another (connected to a PC as a peripheral).

ID Pin Detection (Micro-AB) vs USB-C Dual-Role Detection

The classic OTG mechanism, defined for Micro-AB connectors, uses a fifth pin — the ID pin — to determine the initial role: a Micro-A plug grounds the ID pin (signalling host role to the device it's plugged into), while a Micro-B plug leaves it floating (signalling peripheral role). The embedded product's OTG-capable USB peripheral senses this pin directly, often through a dedicated ID-sense input alongside VBUS sense.

USB-C connectors have no ID pin. Role determination instead happens over the CC (Configuration Channel) lines: a port can be fixed as a UFP (peripheral-only) or DFP (host-only), or configured as a Dual-Role Port (DRP), which alternates trying Source (host) and Sink (device) states until the other end of the cable responds and a role is settled. The underlying dual-role firmware requirement is the same either way — OTG as a named mechanism is specific to the Micro-AB ID pin, but a USB-C DRP design needs the same host-and-device-capable USB stack described below.

Host Negotiation Protocol (HNP) and Session Request Protocol (SRP)

Two OTG-defined protocols manage role changes without requiring a cable swap:

• HNP (Host Negotiation Protocol) lets the current host and peripheral swap roles mid-session — for example, an embedded product that started as a B-device (peripheral, connected to a PC) can request to become the A-device (host) once the PC disconnects, without the physical connector changing.
• SRP (Session Request Protocol) lets a B-device (peripheral) whose host has powered down VBUS to save energy request that the host turn VBUS back on and start a new session — useful for battery-powered OTG hosts that want to power down between uses rather than sourcing VBUS continuously.

Not every OTG-capable design needs both. Many embedded products implement a simpler subset — role fixed by physical connection (ID pin or USB-C DRP) at connect time, with no mid-session HNP role swapping — which is considerably simpler to implement and sufficient for products that don't need to change roles without a physical reconnection.

Implementing Dual-Role Firmware

A dual-role USB stack needs both a host-class driver set and a device-class driver set present in firmware, plus logic to select which is active based on the detected role:

• STM32 — the OTG_FS/OTG_HS peripheral (present on most STM32 families with USB) supports ID-pin sensing directly, paired with STM32Cube's USB Host middleware (MSC, HID host classes) and USB Device middleware (CDC, MSC, HID device classes). STM32CubeMX can generate a dual-role skeleton, but the application still needs to handle the mode-switch logic — tearing down the device stack and initialising the host stack (or vice versa) when the ID pin state changes.
• ESP32-S2/S3 — the built-in USB OTG peripheral is used by two separate driver stacks: usb_host for host mode and TinyUSB for device mode. Automatic ID-pin-driven role negotiation is less mature here than on STM32; many ESP-IDF-based designs fix the role in firmware for a given product variant rather than implementing full runtime OTG negotiation — check the current ESP-IDF documentation for your target version before assuming automatic dual-role switching is available out of the box.
• Generic MCUs without a native OTG peripheral can still implement fixed-role dual-role behaviour (host firmware in one build, device firmware in another, selected by a strapping resistor or configuration byte) without true OTG ID-pin negotiation — a pragmatic simplification for products where the two roles are genuinely used in different, non-overlapping product variants rather than the same unit needing both.

Host-Mode Power: Sourcing and Current-Limiting VBUS

The detail that most often surprises engineers implementing OTG for the first time is what changes when the embedded product takes the host role. As a peripheral, the product draws power from VBUS and never has to think about supplying it. As a host, the product must:

• Source 5 V on VBUS itself, from its own battery or system rail.
• Current-limit that supply, since a misbehaving or shorted downstream peripheral must not be able to pull down the product's internal rails.
• Detect and respond to overcurrent conditions without damaging the host circuitry.

This is normally implemented with a dedicated current-limited power switch IC between the system rail and the OTG connector's VBUS pin (for example, the TPS2051C family or an equivalent current-limited load switch), enabled by a GPIO under firmware control — the MCU's OTG peripheral or USB host stack asserts this GPIO only once it has determined the port is in host mode, and de-asserts it (cutting VBUS) if a fault or overcurrent condition is detected.

Practical Examples

An industrial handheld instrument uses USB OTG so the same port serves two purposes: connecting to a PC via CDC-ACM for firmware updates and data export during development and service, and hosting a USB flash drive in the field to log measurement data without needing a PC at all. The product's OTG peripheral senses the ID pin (or, on a USB-C variant, negotiates DRP) to determine which role is active, switches in the appropriate driver stack, and — only when acting as host — enables a current-limited power switch to source VBUS for the flash drive.

A barcode-scanner accessory module for a point-of-sale terminal implements only the host side of OTG deliberately — it always sources VBUS and never negotiates peripheral mode — because its product requirement is "host a USB scanner," not genuine dual-role operation. This is a common simplification: many products that use an OTG-capable USB peripheral only ever need one fixed role in practice, and skip full HNP/SRP negotiation entirely.

Design Considerations

• Confirm whether the product genuinely needs dynamic role switching, or just two fixed-role variants. Full OTG with ID-pin sensing and HNP/SRP adds real firmware complexity; many products are better served by a simpler fixed-role design selected per variant or at manufacturing time.
• Size the VBUS current-limited switch for the worst-case peripheral the product will host, not just a nominal USB flash drive — a USB peripheral drawing close to the 500 mA USB 2.0 configured limit needs headroom in the switch's current limit and thermal design.
• Don't assume USB-C removes the need for host-mode VBUS sourcing. A USB-C DRP port acting in the Source role has exactly the same obligation to supply and current-limit VBUS as a classic OTG A-device — the mechanism for detecting the role changed, but the power responsibility didn't.
• Plan the mode-switch teardown/init sequence explicitly in firmware. Tearing down an active device-mode USB stack and bringing up a host-mode stack (or vice versa) needs a clean state machine; naively reinitialising the peripheral without releasing the previous mode's resources is a common source of USB stack lockups after a role change. Zeus Design designs dual-role USB host/device hardware and firmware for embedded products that need both roles from a single port.

Common Mistakes

• Wiring VBUS directly to the system rail with no current limiting on an OTG host port, so a shorted or faulty peripheral can pull down the product's internal supply instead of tripping a controlled overcurrent fault.
• Implementing full HNP/SRP negotiation when the product only ever needs one fixed role per variant — adding negotiation complexity, and the firmware states it requires, without a real product requirement for mid-session role switching.
• Forgetting that a USB-C dual-role design still needs a host-mode power path. Engineers moving from Micro-AB OTG to USB-C sometimes assume the CC-line role negotiation replaces the need to source and current-limit VBUS in host mode — it only replaces how the role is detected, not the power responsibility that comes with the host role.
• Not testing role transitions with real peripherals under load. A dual-role stack that enumerates a bench USB drive correctly can still fail with a higher-current peripheral (a USB hub, a wireless dongle) if the current-limited switch's threshold or the host-mode power budget wasn't sized for it.