Does USB Host always supply power on VBUS?

I know a fair bit about USB, but for some reasons I am not able to answer this question myself.

Does the USB Host port (let's say USB 2.0) always supply 5V on the VBUS pin? If not, how does it detect device connection?

For device (bus-powered case) it is easy to detect host by sensing the VBUS pin, but for this to work USB Host should always provide 5V on the VBUS pin, which results in me asking this question.

One thing I can think of is it can provide 5V, 100mA by default, and more only after successful enumeration. But as far as I have observed, the USB ports on laptop have 5V VBUS enabled by default and not limited to 100mA, so I just want to understand from USB standard point of view.

Any reply will be much appreciated.

A standard classic USB host must always provide VBUS (+5V +- 10%) to a downstream port, so a device can initiate the connect sequence (pull D+ or D- high). The port must provide at least 500 mA (2.0 version) or 900 mA (3.0 version), regardless of whether there is any communication or attachment or else. These are "at least" requirements for classic USB 2.0 and USB 3.0 "high-power ports" and powered hubs, so they can supply more if they wish. The requirements are listed in Section 7.2 of USB 2.0 Specifications. Small battery-powered might have an exception.

NOTE1: VBUS must be supplied by host even in "sleep" (suspend state) mode.

--

NOTE2: if a host doesn't drive VBUS high, no attachment would/should occur, even if the device has own power. Connect requests (D+ or D- pull-ups) must occur only if VBUS is present, by USB 2.0 specifications Sec.7.2.1. So it is a spec violation just to "have" the pull-ups, the pull-up must be conditional with VBUS.

--

NOTE3: So, no VBUS => no communication. Becuse of this rule, no "partial" or "host-signaling" mode is possible without VBUS.

The 500 mA is a requirement for USB HOST. This supply number is frequently confused with a requirement for a USB DEVICE as consumer. A USB device SHOULD NOT draw more than 100 mA upon initial connect stage, and can draw full power only when it gets enumerated and receives "set_configuration ()" command. USB devices report their power requirements in device descriptor, during this inital "100mA" session. If the host has exhausted its power budget, it can stop the enumeration, effectively rejecting the device.

NOTE4: as one can see, there is no "negotiation", it is either "my [host] way", or "freeway".

--

NOTE5: USB hosts have no specified means to police actual power consumption from its ports. USB host controllers don't have any registers that can measure/report ports consumption. Therefore a host cannot enforce the 100mA limit to police out bad devices that might violate the 100 mA specification, unless a drastic event of port overcurrent occurs. The compliance to 100 mA limit was thought at the level of USB-IF certification process.

In short, the 500 mA and 100 mA are requirements for different USB entities, one for hosts and hubs, and another for devices, again as described in Section 7.2.1. This is how it works from USB standard point of view.

Now things are a bit different with introduction of Type-C connector. Type-C devices (both hosts and peripherals) are prohibited to output VBUS, initially. So, instead of boldly having VBUS power on a Type-C port, the host must turn on VBUS source only if the port logic detects the presence of cable/device. It does this by sensing voltage level on "CC" (Communication Channel) pin. A Type-C host has a pull-up on both CC pins. A device (or legacy cable assembly) must have 5.1k pull-down. When device/cable is plugged in, the host detects that 5.k drags its pull-up down, and at this point the host has rights to engage VBUS power, and USB communication begins.

• Thank you so much for the detailed and well referenced answer. I really appreciate your help. I am badly stuck in a project, so not able to spend time on giving more thought here. I will comment here if I have any further questions on the same. Jul 10, 2017 at 9:06
• "USB host may have a power management system that is independent of the USB" from usb_20.pdf 4.3.2 power management chapter. So "A standard classic USB host must always provide VBUS" is not correct. For power management reasons, the system can power down VBUS. Oct 30, 2020 at 9:06
• @iouzzr, an "independent of USB power management" does not make the USB host as "standard" and "classic". It is true however, that the market of portable devices has invented the concept of "cold standby" with VBUS turned off, mainly because many USB devices failed to follow SUSPEND power limits, and to prevent long-term drain of small batteries. But this kind of devices usually have a moniker "portable devices", which is hardly "classic USB", so my statement still stands true. But thank you anyway for mentioning this nuance. Oct 31, 2020 at 0:47
• Does a USB-C wall charger always provide VBUS?
– Bram
Feb 14 at 23:24
• @Bram, no, a Type-C-compliant charger should not supply VBUS until the port/cable sees proper pull-downs on CC pins (unless it is plugged) Feb 15 at 5:52

Unless it is in some sort of sleep or overcurrent fault mode, yes, an ordinary (Classic 1.0/1.1/2.0) USB host would always supply power to VBUS.

USB devices are detected by the host because they have a pull-up resistor on one of the data lines - D- for a low-speed device, and D+ for a full speed device (or a high speed device; the high speed is discovered in the signalling).

While the USB spec prohibits peripherals from drawing more than 100 mA without negotiation, in practice many (most) hosts do not enforce this. Typically they have some kind of PTC or active overcurrent protection which kicks in somewhere above 500 mA (a few, like original Raspberry pi's had lower limits, and could not source full USB spec current).

A few early smarthphones had non-compliant partial USB host capability, they were able to operate in the host signalling role, but not source VBUS to a peripheral. Most today either have a charge pump to supply VBUS or do not permit host mode operation at all.

• Thank you so much for your detailed answer. I really appreciate it. Jul 10, 2017 at 9:07