STM32MP135F-DK - Moving USB HOST HID function from OTG/Type C to HOST

[SteMMo]

Hi all,

I'd like to move the USB HID/CDC function, implemented in the Ux_Host_HID_CDC_ACM sample, from TypeC OTG port to USB host port.

Does it make sense?

I started to create a usb_host.c based on usb_otg.c, changing the OTG into the USB Port1 references.

But I don't know how to enable the VUSB voltages on the USB connectors: the enables seems to be under control of the USB hub on the DK board.

Do I need to send commands via the i2c5 bus?

Which commands?

 

Thanks!

 

-- ADDED --

Looking better the schematics I note that the resistors connected with the I2C pins are not inserted, so it is impossible communicate with the USB hub chip.

So, why the VBUSs on the USB TypeA sockets are not enabled (and then they not feed any USB devices ..) ??

 

-- ADDED 2 --

Why the GPIO PortB Pin2 is set as original implementation of USBH_DriverVBUS() ??

 

-- ADDED 3 --

Definitively I'm not able to point to USB Host port.

My guess is that the USB hub is sleeping/disabled cause a configuration error of the USB_DP1+USB_DN1 pins.

Can anyone help me to configure the USB Host module, please?

 

[SteMMo]

Has anyone managed to make the example work?

Same problem with Ux_Host_MSC_A7 ... no VBus voltage on the Type-A USB Host connectors.

In this sample VBUS is set by the GPIO PortH Pin5 .. !?!?!?!?!

 

[Jean-Marc S]

Hello

On the USB Host side of the schematic you can indeed see an I2C interface connected to the Hub component.

However we do not need to use this I2c, by default it works as expected on our application

The I2C could be needed to program differently the Hub (I am not familiar with it you may certainly find the datasheet of this component if needed)

 

The VBUS is generated from the 2 components on top of the schematic (U23/U24: STMPS2252MTR)

Those are used to detect overcurrent from IN (5V_VIN) to OUT1, OUT2

If the current from VIN to one of the OUT1/2 exceeds the limit current then the signals "notOC1"/"notOC2" will be activated and inform the Hub component to disable the corresponding "PRTPWR1/2/3/4" signals which then will switch off the VBUS on the U23/U24 components. 

Those  "PRTPWR1/2/3/4" signals are activated when VBUS_DET is 1 (3V3_SW provided by the PMIC)

hope it clarifies a bit the schematic

[SteMMo]

Thanks @Jean-Marc S ,

this is also my understanding, but, without any attached USB device, the PRTPWR1/2/3/4 signals are low (0V), "notOC1"/"notOC2" to 2.18V (?), VIN to 4.36V, , OUT1/2 to 0.45V.

Voltage VBUS_DET = 3V3_SW = TP49 = 3.17V so, the signals should be high, is it?

The U33 datasheet says:

The USB251xB/xBi enables VBUS by asserting the port power (PRTPWR) as soon as the hardware configuration 
process has completed. If the port detects an over-current condition, PRTPWR will be turned off to protect 
the circuitry from overloading.

 Should I assume that there is an overcurrent?

Which is this condition?

Thanks

 

[PatrickF]

Hi,

some thoughts.

VIN 4.36V seems a bit low. although not an issue I think. Could you try using another supply ?

2.18V on notOCx pin sound not really normal. Maybe you damaged something on the board.

3V3_SW is present, so your SW manage to enable the STPMIC1 USB_SW, right ?

Are the USB_DP1/DM1 correctly initialized ? Maybe the USB2514 assume there is an USB suspend mode and shutdown the whole USB output ports.

 

To check correct HW board behavior, 1st is to check with official Starter Package ?
https://wiki.st.com/stm32mpu/wiki/Getting_started/STM32MP1_boards/STM32MP135x-DK/Let%27s_start/Populate_the_target_and_boot_the_image

 

Regards.

[PatrickF]

Hi @SteMMo 

plase also refer to https://community.st.com/t5/stm32-mpus-products/stm32mp135f-dk-bare-metal-how-to-use-the-usb-host-ports-not-otg/td-p/721759

 

Managing USB host in bare-metal is a quite complex topic as you should manage all the case (hubs, various USB peripherals drivers, power, etc...) to ensure USB certification (much more complex for Host than OTG or device).

We do not provide any SW for USBH in bare-metal due to the complexity behind EHCI/OHCI stack.

Note that OTG and USBH are completely different IP and different SW concept behind, so almost no possible reuse.

As EHCI/OHCI is standard, you might find some existing solution on different ICs you could try to port to STM32MP13, but we cannot guarantee any support on this.

Regards.