The device has a battery, but it would be nice to be bus-powered when available. A computer will typically supply 500 mA, for instance, while a smartphone in OTG mode is only required to supply 8 mA.

Is it possible to do something like this?

  1. request 500 mA
  2. if accepted: power from computer and charge battery from computer
  3. else: request 200 mA
  4. if accepted: power from computer
  5. else: claim self-powered, power from battery

This seems to be what configurations are for:

Therefore it is possible to have two configurations, one for when the device is bus powered and another when it is mains powered. ... Once all the configurations have been examined by the host, the host will send a SetConfiguration command with a non zero value which matches the bConfigurationValue of one of the configurations. This is used to select the desired configuration.

Is it enough to specify multiple configurations in the descriptors, one for each current requirement? Does the OS automatically try them in order and move on to the next if one fails?

Multi-config USB devices and Windows seems to say that's how it works:

During enumeration, USBCCGP will first attempt to select the configuration whose descriptor is found at the specified “original” index. If the attempt fails, normally due to the configuration requiring more than 100mA while the device’s upstream hub has only bus power, then USBCCGP attempts to select the configuration found at the specified “alternate” index instead.

However this doesn't work in practice?:

“Microsoft drivers invariably work with just the first configuration of a device. The Microsoft support for composite devices won’t engage if the device has multiple configurations. Consequently, multiconfiguration devices seem to be rare in practice, and Microsoft discourages people from designing new ones.”


Microsoft drivers will only ask for the first configuration - and if that asks for too much current, so be it.


it is not common to have more than one configuration. Windows standard drivers will always select the first configuration so there is not a lot of point.

If multiple configurations don't work in practice, can the device detect that it's been rejected, simulate a disconnect and reconnect with a different set of descriptors?

(This is a question about the USB enumeration/communication part, not the hardware implementation of how to connect the battery, etc.)


That defines a normal enumeration process. If it doesn't work for you that way, and you are programming the USB peripheral side, then you could do this without issue.

Enumerate, failed at 500 mA request. The Host should signal this enumeration failure according to the Specs.

Device disconnects the usb data pins, changes its usb descriptor, and signals for enumeration again.

If failed. Repeat, changing it's descriptor to read self powered again. You must have a method to switch the power pin. A usb power switch for example. A diode OR bridge if the voltage drop is acceptable. You cannot back feed the VUSB with your battery unless you want to break something. Then signal again.

The descriptor is nothing but a few bytes that you could change via variables. As long as you can change that, you are fine.

  • 2
    \$\begingroup\$ How exactly does the host signal the enumeration failure? \$\endgroup\$ – CL. May 21 '16 at 8:25
  • \$\begingroup\$ @CL., this is not the enumeration "failure", it is a rejection of a device if its power requirement doesn't fit current power budget of the host. Enumeration of a USB device is completed when host sets "configuration" after setting device address reading a bunch of descriptors. If this last part of enumeration protocol is not completed, the device may know this and perform the switch described by Passerby. \$\endgroup\$ – Ale..chenski Feb 17 '18 at 14:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.