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.)

  • \$\begingroup\$ I think that indeed it could work, and defining multiple configurations as you've described would be the way to do it, but as others have pointed out, there's no way to guarantee how the device will be treated by a (generic) Windows driver. Of course, if you write your own driver, you can have the host treat the device the way you want it treated, but writing Windows drivers is not for the faint of heart. \$\endgroup\$
    – Eamon
    Oct 29, 2020 at 4:15

1 Answer 1


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, 2016 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\$ Feb 17, 2018 at 14:53
  • \$\begingroup\$ "Device disconnects the usb data pins" Can it just lower the pull-up on D+ to disconnect? \$\endgroup\$
    – endolith
    Oct 23, 2020 at 19:02
  • \$\begingroup\$ "When first plugged into USB, CX3 enumerates automatically with the Cypress Vendor ID (0x04B4) and downloads the firmware and USB descriptors over the USB interface. The downloaded firmware executes an electrical disconnect and connect. CX3 enumerates again, this time as a device defined by the downloaded information. This patented two-step process, called ReNumeration, happens instantly when the device is plugged in." They can't have patented the re-enumeration itself? Just the whole bootloader process? \$\endgroup\$
    – endolith
    Oct 23, 2020 at 19:57
  • \$\begingroup\$ Is this answer influenced by whether USB-C is in use or not? \$\endgroup\$
    – Reinderien
    Oct 27, 2020 at 16:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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