Unable to initialize USB OTG

[Tomáš Juřena]

Hello,

I am having difficulties initializing the USB OTG in the ST Ecosystem 3.1.0 with the STM32MP157C in the Octavo OSD32MP15x SiP. With the ST Ecosystem 2.1.0 there was no issue and the previous image still works on my development board. I only need the host mode because we have only an LTE module connected to it.

The kernel log says the device timeouted when probing.

dmesg |grep usb
[ 0.112487] usbcore: registered new interface driver usbfs
[ 0.112570] usbcore: registered new interface driver hub
[ 0.112642] usbcore: registered new device driver usb
[ 1.595777] usb33: supplied by regulator-dummy
[ 1.648809] usbcore: registered new interface driver pegasus
[ 1.648893] usbcore: registered new interface driver asix
[ 1.648970] usbcore: registered new interface driver ax88179_178a
[ 1.649033] usbcore: registered new interface driver cdc_ether
[ 1.649112] usbcore: registered new interface driver smsc75xx
[ 1.649192] usbcore: registered new interface driver smsc95xx
[ 1.649265] usbcore: registered new interface driver net1080
[ 1.649327] usbcore: registered new interface driver cdc_subset
[ 1.649385] usbcore: registered new interface driver zaurus
[ 1.649477] usbcore: registered new interface driver cdc_ncm
[ 1.652573] usbcore: registered new interface driver usb-storage
[ 1.666098] usbcore: registered new interface driver usbhid
[ 1.666110] usbhid: USB HID core driver
[ 1.892129] vdd_usb: supplied by vin
[ 2.004922] stm32-usbphyc 5a006000.usbphyc: registered rev:1.0
[ 2.006324] dwc2 49000000.usb-otg: supply vusb_d not found, using dummy regulator
[ 2.006632] dwc2 49000000.usb-otg: supply vusb_a not found, using dummy regulator
[ 2.028150] dwc2: probe of 49000000.usb-otg failed with error -110
[ 2.029872] ehci-platform 5800d000.usbh-ehci: EHCI Host Controller
[ 2.029935] ehci-platform 5800d000.usbh-ehci: new USB bus registered, assigned bus number 1
[ 2.030427] ehci-platform 5800d000.usbh-ehci: irq 61, io mem 0x5800d000
[ 2.057802] ehci-platform 5800d000.usbh-ehci: USB 2.0 started, EHCI 1.00
[ 2.061717] ohci-platform 5800c000.usbh-ohci: Generic Platform OHCI controller
[ 2.061767] ohci-platform 5800c000.usbh-ohci: new USB bus registered, assigned bus number 2
[ 2.062443] ohci-platform 5800c000.usbh-ohci: irq 55, io mem 0x5800c000
[ 2.757744] usb 2-1: new full-speed USB device number 2 using ohci-platform
[ 7.386603] usbcore: registered new interface driver cdc_acm

To generate the device tree I used the STM32CubeMX 6.5.0 after migrating from 6.1.0.

Since the USB works fine with the older Ecosystem I assume that it is only an SW problem. I have already tried quite a few DTS configurations but without success. Did anyone encounter this issue? Any advice will be appreciated.

Best regards,

Tomas

[Kevin HUBER]

Hello @Tom�? Ju?ena​ ,

If you want to be in Host mode, why did you put the lines into comments?

/*	dr_mode = "host";
	usb-role-switch;
	role-switch-default-mode = "host";
*/

In my opinion, it is a problem of DTS configuration. When you do a migration from an ecosystem to another by using CubeMx, the user sections from DTS are not migrated. They msut be updated manually because they may contain user updates (that should be overwritten).

The recommand way to migrate from an older ecosystem to a new one is to:

1.Backup your project

�? Copy all the project into a backup folder to avoid losing codes or configurations if you make an error.

2.Migrate

�? Migrate your project with the newest version of CUBEMX (6.5.0) and generate the DTS

3.Project Reference

�? Create a new project with the newest version of CubeMX (6.5.0) by selecting the ST Board which is the most similar to your custom project.

This project will be used as a reference to see the difference brought by the ecosystem update into the User Section areas.

Merge

• Use a diff tool like “meld�? to merge the reference DTS from CubeMX 6.5.0 with the migrated one from CubeMX 6.1.0.

------------------

Please can you send me your complete generated DTB, I will have a look at it to see If I find something.

Regards,

Kevin

[Tomáš Juřena]

Hello Kevin,

thanks for the quick response.

I experimented with a lot of combinations but none of them work, so it is there as a result of my tries. I am planning to uncomment it when the USB is working. The default value for dr_mode is otg so it should still work in host mode, doesn't it?

I will try the suggested migration process. Perhaps I could use the provided DK2 device tree and only redefine the PMIC regulators just to see if I made some errors while migrating.

In the meantime, I am sending the compiled dtb file.

Regards,

Tomas

[Kevin HUBER]

Hello @Tom�? Ju?ena​ ,

After looking at your DTS/DTB, I didn't found the error yet, but I have a question and some remarks. Maybe they will help you.

Which usb port are you trying to use? Is it the USB C port CN7?

Because if this is the USB-C port, I advise you to follow this chapter in the wiki:

https://wiki.st.com/stm32mpu/wiki/OTG_device_tree_configuration#DT_configuration_example_as_high_speed_OTG-2C_with_Type-C_connector

This is what is implemented in the stm32mp157c-dk2.dts delivered with the developer package of ecosystem v3.1.

If you want to use the USB C port, you have to add it in your i2c and add the port in the usbotg_hs node.

This example is in host and device mode.

----------

The other point is about the "phys" configuration of your usbotg_hs config:

In your DTB/DTS, we can see:

phys = <0x2d 0x00>;
phy-names = "usb2-phy";

which means:

phys = <&usbphyc_port1 0>;
phy-names = "usb2-phy";

If you want to use the usboth_hs in host mode, you have to set the phys port like this:

phys = <&usbphyc_port1 1>;

The second parameter indicates if you want to use the OTG controller or the Host controller. This is explained here with a great ascii-art :

https://elixir.bootlin.com/linux/v5.12-rc2/source/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml

 

So if extra parameter of &usbphyc_port1 is 0, OTG controller uses DP2/DM2, if it is 1, HOST (USBH) controller uses DP2/DM2.

Since you want to configure the "usbotg_hs" node as a host, you must put 1 in extra parameter of &usbphyc_port1.

And regarding the phys port that you used for usbh-ehci and ohci, I don't think you must use the port0:

phys = <&usbphyc_port0>;
phy-names = "usb";

Because if you look at the wiki page:

https://wiki.st.com/stm32mpu/wiki/USBH_device_tree_configuration#DT_configuration_when_using_the_two_physical_ports

You can see that to configure the UTMI switch (like for the OTG) in USB Host controller, you have to use the port #2:

/* Use USBPHYC HS PHY port #2, configure UTMI switch to select USBH controller */

<&usbphyc_port1 1>;

------------

If you still are blocked, please can I have the complete bootlog traces related to the latest DTB/DTS that you sent? Because the first traces that you put in your first post is from your previous test. It will help me and the community to help you :).

Hope it helps,

Regards,

Kevin

[Kevin HUBER]

Hello @Tom�? Ju?ena​ ,

Sorry for the delay, I was on vacations.

Did you make some progress on this post?

Regards,

Kevin

[Tomáš Juřena]

Hi Kevin,

thanks for coming back to this.

Unfortunately, I did not find the cause of this issue. I have tried to add more logs to the stm32-pwr-regulator driver, to see what went wrong and to me, it confirms that the problem is with the regulators. I am not sure what can be the issue since these regulators are internal and are not altered from DTS or CubeMX.

I am attaching the current dmesg output and the patch with changes that I made in drivers.

Is it possible to still have an error in the DTS or should I look somewhere else?

Best regards,

Tomas

[Kevin HUBER]

Hi @Tom�? Ju?ena​ ,

I think I finally found the problem! (I hope)

If you look at the wiki page of the regulator: https://wiki.st.com/stm32mpu/wiki/Regulator_overview#Consumers

The USBPHY is supplied by vdd_usb:

 &usbphyc {
 vdd-supply = <&vdd_usb>;
 };

And in the chapter 6.1 of the same page: https://wiki.st.com/stm32mpu/wiki/Regulator_overview#How_to_trace

You can see that vdd_usb is configured to 3300mV

 

• Your DTS

You were right, vdd-supply and vdd_3v3_usbfs-supply were missing in your DTS, so you added:

	vdd-supply = <&vdd>;
	vdd_3v3_usbfs-supply = <&vdd_usb>;

This is nice, but if we look at the latest dts that you sent, the node related to vdd is:

buck3 {
	regulator-name = "vdd";
	regulator-min-microvolt = <0x1b7740>;
	regulator-max-microvolt = <0x1b7740>;
	regulator-always-on;
	st,mask-reset;
	regulator-initial-mode = <0x00>;
	regulator-over-current-protection;
};

and the vdd voltage is 0x1b7740 microvolt (1 800mv) and it must be 3300mv as visibile in the wiki.

When I look at the DTB that I compiled for my STM32MP157C-DK2 board, I can see in the pwr node that

vdd-supply = <0x4f>;

and 0x4f is:

buck3 {
	regulator-name = "vdd";
	regulator-min-microvolt = <0x325aa0>;
	regulator-max-microvolt = <0x325aa0>;
	regulator-always-on;
	st,mask-reset;
	regulator-initial-mode = <0x00>;
	regulator-over-current-protection;
	phandle = <0x4f>;
};

with 0x325aa0 microvolt (3 300 mv) as visible in the consumers example of the wiki.

Please can you make a test to set the "vdd-supply" property to a BUCKs configured to 3300mv ?

Hope it helps,

Regards,

Kevin

[Tomáš Juřena]

Hello Kevin,

I cannot change the buck3 because it will damage some other ICs on the board, but I believe that you are correct. I have checked the Reference manual (section 9.2), the Getting started application note (section 4.2), and the discrete power supply hardware integration application note (section 3.2) in more detail, and there is stated that the internal 1.8V LDO regulator works if BYPASS is VSS and the supplied VDD is above 2.25 V. So I tried to set the buck3 to 2.3 V and the issue with the regulator is solved. I wonder why the 5.4 kernel works fine and the 5.10 does not.

I think to fix this we need to change the board layout and connect the BYPASS_REG1V8, then it should work as expected. Thanks for your help on this issue.

Best regards,

Tomas

[Kevin HUBER]

Hello @Tom�? Ju?ena​ ,

Good news :).

Yes, as explained in AN5031, it should work with BYPASS_REG1V8 connected.

Thanks for the explanation, it will help other people.

Best Regards,

Kevin