Details of using USB without VBUS sensing

[Matthijs Kooijman]

I'm wondering how things work *without* VBUS sensing on, in particular, the STM32F401. From the documentation, I understand that:

• VBUS sensing can be disabled for bus-powered devices, since these are only powered up when VBUS is present, so VBUS can be assumed to be always present.
• VBUS sensing is mandatory for self-powered devices, since they might be powered without USB power present (or USB cable attached).

However, it seems that running self-powered without VBUS sensing is also possible:

• I've seen some people report success on this forum (e.g. here and here)
• The DFU bootloader on the STM32F401 only documents the need for DP/DM connected, not VBUS/PA9 (AN2606), so it must be able to work without VBUS sensing.
• The reference manual (RM0368) in section 22.5 says: "The VBUS pin can be freed by disabling the V BUS sensing option. This is done by setting the NOVBUSSENS bit in the OTG_FS_GCCFG register. In this case the V BUS is considered internally to be always at V BUS valid level (5 V)." (though it is not entirely clear if that applies to self-powered as well).

But I cannot quite find any documentation about the implications and limitations of disabling VBUS sensing.

In some places, I've found mentions that the "USB specs require VBUS sensing". Looking at the USB 2.0 specification, I've found these:

• Section 7.1.5.1: The voltage source on the pull-up resistor must be derived from or controlled by the power supplied on the USB cable such that when V BUS is removed, the pull-up resistor does not supply current on the data line to which it is attached.
• Section 7.2.1: They may not provide power to the pull-up resistor on D+/D- unless V BUS is present (see Section 7.1.5). When V BUS is removed, the device must remove power from the D+/D- pull-up resistor within 10 seconds.

So, how does this work without VBUS sensing? Here's my hypothesis:

• When you set NOVBUSSENS, VBUS is assumed to be always present. This means that whenever the USB module is enabled, the DP pullup is also enabled, even when no USB cable is attached or the USB host is powered down.
• When you attach the cable, or power up the USB host, it will see the (already present) pullup and immediately reset the device and start enumerating the device. This is how the STM32 can detect that a host is present.
• When you detach the cable or power down the host, this is not properly detected by the STM32. I suspect it will notice that lack of activity (no more SOF frames), but AFAIK this looks like a suspend, so I suspect the STM32 will throw a suspend event rather than an end session?
• When later a cable is re-attached (while the STM32 thinks it is still suspended), this will not be detected by the STM32 until the host resets the device and starts enumeration. Does the STM32 handle this gracefully?
• When the host is powered down (or otherwise removes VBUS), the DP pullup remains enabled, violating the USB specification and possibly allowing current to flow into the USB host through the pullup.
• This post  (about a NXP-chip) suggests you could get spurious USB interrupts due to floating D+/D- pins, but since D+ is pulled up this should never cause a reset condition, so I guess this does not really apply (maybe some extra power usage due to a toggling D-)?

Summarizing, the downside of not having VBUS sensing is that you can violate the spec and leave pullups enabled when not allowed, and you cannot properly detect when a cable is removed? Can someone confirm that this is a correct understanding?

Then, I wonder how the bootloader works without VBUS sensing. I assume like above, but the flowchart in AN2606 (for the STM32F40xx in section 26.1.2) has a "USB cable Detected" check. If that cannot use VBUS sensing, then what does it detect exactly? Does it check whether the host has sent a reset/enumeration request? This happens before the clock is configured (according to the flowchart), so (I assume) no actual communication can happen to detect the cable (but it seems that a reset condition by the host is just 10ms of driving DP and DM low, which is probably more than enough time to be detected and initialize the clock?).

[waclawek.jan]

> Summarizing, the downside of not having VBUS sensing is that you can violate the spec and leave pullups enabled when not allowed, and you cannot properly detect when a cable is removed?

> Can someone confirm that this is a correct understanding?

Yes.

The history of USB is a history of standard violation from all sides (and a not very well thought out standard to start with).

While the Synopsys machine (the OTG IP in the 'F4) attempts to offload some of the protocol to hardware, most of it is handled in software anyway. So it's up to you how do you handle reset/suspend etc. events (unless you deem the example implementation provided by Cube/CubeMX as an unpenetreable and perfect black box).

JW

[Matthijs Kooijman]

Thanks. In that case I guess I'm going to connect VBUS after all, so I can detect cable presence while in my application. When running the ROM bootloader, this might cause a USB spec violation, but that should be rare and not really problematic, so that seems acceptable.