How to repeat USB enumeration with a maxpower of 100mA if a previous 500mA request was rejected by the hub

[UMau.1]

Hi,

I want to design a combined USB<->RS485 converter cable based on the CDC profile with integrated charger detection. The MCU of my choice is the STM32F401CB.

The release of battery charge is done by switching an overcurrent protection chip TCKE805NL. This chip only should be released if a charger or a charging downstream port is detected or if a standard downstream port was successfully set to a MaxPower of 500mA instead of 100mA.

To detect all kinds of charger devices I use an additional BQ24392 charger detection chip.

My problem now is, that the communication also should work on a standard downstream port with only 100mA granted current. In this case with deactivated battery charging.

The Maxpower parameter in the configuration data is set to 0xFA (500mA). Im now afraid that if I try to connect to a port only able to deliver 100mA the enumeration and so the connection will be rejected by the host and I don't know a possibility to repeat the enumeration with a Maxpower request of 0x32 (100mA). So it seems that it not will be possible to realize a simple communication without charging on a standard upstream port which is limited to 100mA.

Does anyone has an idea how to solve this issue?

[TDK]

You can reset the USB peripheral, wait a second, and reinitialize it. The PC will detect this and try to re-enumerate.

[waclawek.jan]

While complete rest of the peripheral will certainly accomplish disconnect to, there is a dedicated control for this, quoting the RM:

Soft disconnect

The Powered state can be exited by software by using the soft disconnect feature. The DP 

pull-up resistor is removed by setting the Soft disconnect bit in the device control register 

(SDIS bit in OTG_FS_DCTL), thus generating a device disconnect detection interrupt on 

the host side even though the USB cable was not really unplugged from the host port.

The software stack must change its state accordingly, of course, but that apply to the reset method, too.

JW

[UMau.1]

Hi,

thanks for your useful hints.

I meanwhile found the function to initiate the soft reset with USBD_DeInit(pdev)

and the access to the MaxPower entry within the configuration: *(USBD_CDC.GetFSConfigDescriptor(&length) + 8)

for the following reinitialisation.

Are there any examples for the procedure of the wished function?

So it may occur, that the device is connected to a powered off PC which is switched on than. The USB-device gets power nearly immediately but will be enumerated not until the operating system of the PC is gone up which will need a long time. In the worst case the USB port is then a standard upstream port with only 100mA power wich will need a re-enumeration with MaxPower parameter of 100mA instead of 500mA.

To tell the truth I have no plan, which of the innumerable low level init and state functions I will have to call in which order to grant a communication on a 100mA port and to prevent a too long delay time between power on and activating the charger switch.

For regarding hints I would be very, very grateful.

[UMau.1]

OK, it seems, that the handling of multiple configurations with low level functions has not to be done by myself: https://www.beyondlogic.org/usbnutshell/usb5.shtml

Like described, the client itself asks automatically for different configurations if the current configuration provided by the device does not fit.

The STM32-USB-Stack supports multiple configurations. But may be that I'm blind or dumb but I nowhere found an example how to implement and configure multiple configurations. In principle I only need two identical CDC-configurations. The first with 500mA bus power request and the second with 100mA.

Can someone, please, give me a hint how to use the feature of multiple configurations in the STM-Stack?

[waclawek.jan]

I've never met a host supporting multiple configurations in its stock class drivers. I also never met a host which would reject a 500mA descriptor. I don't say none such exist, I just don't know how do they behave.

The USB spec is not a guide to implementation, rather, a relatively loose framework, within which hosts and devices try to come to an agreement, sometimes interpreting the not clear issues in their own way, sometimes ignoring or plainly violating some of the more obscure rules. Often the anticipation is, that device vendors supply matching drivers to hosts. Classes are defined to avoid this need, but their definitions tend to leave even more leeway than the base USB documents, so class device implementors simply have to accommodate to whatever quirks the class host drivers have, often finding them experimentally, as usually documentation is scarce.

Welcome to the wonderful world of the (not that much) Universal Series Bus.

JW

[UMau.1]

Yes, in this trap I fell meanwhile too, trying to find a host rejecting my 500mA-request. Even simple bus powered USB-hubs, enumerated with 100mA MaxPower in the PC granted me the requested power of 500mA.

So I've no chance at the moment to test the solution of a possible rejected enumeration (if there may exist such a solution at all).

At the moment the only way is to violate the USB rules and hazard a possible overcurrent shutdown of the host when activating the devices charger function.