How to disable USB dev power from M480

[jeromeDms]

Hi There
In my app using a M482, I need to power down all connected devices to the USB host port of the M480.
There could be a hub, or a single device directly connected to the USB Host port.
How can I disable power supply of the USB connector, as well as the hub if connected ?

I guess I can check if a hub is connected and call clear_port_feature :

for (i = 1; i <= hub->bNbrPorts; i++)
{
ret = clear_port_feature(hub, FS_PORT_POWER, i);
}
}

But what about if no hub present ?
How to control SYS_GPB_MFPH_PB15MFP_HSUSB_VBUS_EN ?
Tahnks

[ychuang3]

Please first confirm whether your board's VBUS_EN pin is connected to the power switch IC. This pin is used by the Host Controller to control the power switch IC, toggling the power supply to VBUS.

Typically, this pin's pin function is set for USB Host control, meaning it is automatically managed by the USB Host Controller hardware.

If you want to forcibly turn off VBUS power, you can switch this pin's pin function to GPIO output mode and set it to output low, which will disable the power supply.

[jeromeDms]

Thanks. In the case of a powered hub is used, should I also disable power on the hub by calling clear port feature on the concerned ports ? My problem is that I need to re-enumate some devices, I found that calling the function usbh_reset_device() works but some devices no longer work after they are re-enumerated, sounds like they need a hardware reset. I see they are correctly enumerated again after a software disconnect but they no longer exchange data from device to host (opposite direction from host to device works) Any idea ? Thanks again

[ychuang3]

A self-powered hub cannot cut off VBUS to disconnect the device through USBH. If your goal is to re-enumerate the device, you can use the function:

int usbh_reset_device(UDEV_T *);

This is applicable to devices that have already been successfully enumerated. Using usbh_reset_device(UDEV_T *) will reset the device and trigger re-enumeration.

[jeromeDms]

Thanks
This is indeed the function I'm currently using.
It works as expected for some devices, but I found some other devices no longer send data to the host after they are re-enumerated (they can receive data but not send to the host), this is why I wanted to test a hardware reset.

[ychuang3]

What type of device is it?
If it is a Bus-powered device, the method mentioned can forcibly cut off power. If it is a Self-powered device, including those powered by a hub, it will not work.

[jeromeDms]

It is a USB midi device, bus powered.
The weird thing is the usbh_reset_device() properly disconnect and reconnect the device, all descriptors and endpoints are properly parsed, everything is recognized as expected.
But sending data from this device to the host no longer triggers the interrupt in the M482
utr is properly reallocated after the re-enumeration, utr->func is attached, but no interrupt received.
It works on the other direction, sending data from the host to the device works fine.

[ychuang3]

What kind of device?
If it is a HID device, you may have to call usbh_hid_start_int_read() again to install interrupt in pipe.

[jeromeDms]

I developed my own USB-MIDI driver, starting from your USB audio driver and adapting to Bulk endpoints.
When the device is re-enumerated, I call start_read() again to setup utr, I've no error message, but no interrupt received when the device sends data.

[ychuang3]

The condition for completing a bulk in transfer is either receiving the expected amount of data or receiving a zero-length packet. Before this, no interrupt notification will occur.
Do you have a USB sniffer or similar tool to check the USB bus transmission status?

[jeromeDms]

My issue was a memory alloc failing.
I increased the heap from 0x2000 to 0x3600 and now everything is ok.
I'm supporting 8 devices attached to a hub, and each device requires about 1.2k memory.