2022-05-11 02:55 AM
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
Solved! Go to Solution.
2022-06-03 07:30 AM
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
2022-05-12 02:35 AM
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
------------------
Please can you send me your complete generated DTB, I will have a look at it to see If I find something.
Regards,
Kevin
2022-05-12 03:26 AM
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
2022-05-13 09:41 AM
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:
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 :
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:
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
2022-05-18 02:27 AM
Hello Kevin,
sorry for the delay.
I have tried your suggestions and I had partial success. The device connected to the USB bus is currently detected and working but there is still a timeout when probing the USB-OTG. Please see the log:
dmesg |grep usb
[ 0.112533] usbcore: registered new interface driver usbfs
[ 0.112639] usbcore: registered new interface driver hub
[ 0.112720] usbcore: registered new device driver usb
[ 1.596425] usb33: supplied by regulator-dummy
[ 1.649539] usbcore: registered new interface driver pegasus
[ 1.649630] usbcore: registered new interface driver asix
[ 1.649703] usbcore: registered new interface driver ax88179_178a
[ 1.649772] usbcore: registered new interface driver cdc_ether
[ 1.649858] usbcore: registered new interface driver smsc75xx
[ 1.649957] usbcore: registered new interface driver smsc95xx
[ 1.650024] usbcore: registered new interface driver net1080
[ 1.650090] usbcore: registered new interface driver cdc_subset
[ 1.650153] usbcore: registered new interface driver zaurus
[ 1.650249] usbcore: registered new interface driver cdc_ncm
[ 1.653373] usbcore: registered new interface driver usb-storage
[ 1.666971] usbcore: registered new interface driver usbhid
[ 1.666990] usbhid: USB HID core driver
[ 3.181441] vdd_usb: supplied by vin
[ 3.389238] stm32-usbphyc 5a006000.usbphyc: registered rev:1.0
[ 3.395289] dwc2 49000000.usb-otg: supply vusb_d not found, using dummy regulator
[ 3.401831] dwc2 49000000.usb-otg: supply vusb_a not found, using dummy regulator
[ 3.437518] dwc2: probe of 49000000.usb-otg failed with error -110
[ 3.446803] ehci-platform 5800d000.usbh-ehci: EHCI Host Controller
[ 3.451878] ehci-platform 5800d000.usbh-ehci: new USB bus registered, assigned bus number 1
[ 3.460691] ehci-platform 5800d000.usbh-ehci: irq 61, io mem 0x5800d000
[ 3.489523] ehci-platform 5800d000.usbh-ehci: USB 2.0 started, EHCI 1.00
[ 3.513020] ohci-platform 5800c000.usbh-ohci: Generic Platform OHCI controller
[ 3.526504] ohci-platform 5800c000.usbh-ohci: new USB bus registered, assigned bus number 2
[ 3.538535] ohci-platform 5800c000.usbh-ohci: irq 55, io mem 0x5800c000
[ 4.217883] usb 2-1: new full-speed USB device number 2 using ohci-platform
[ 4.957807] usb 1-2: new high-speed USB device number 3 using ehci-platform
[ 5.162798] cdc_ether 1-2:1.0 wwan0: register 'cdc_ether' at usb-5800d000.usbh-ehci-2, Mobile Broadband Networkb
[ 10.748090] usbcore: registered new interface driver cdc_acm
I am also attaching the current DTS configuration.
About your question about the port. It is not that easy because we have a micro-USB connector but it is used only for flashing. This connector is connected to the CPU using the USB multiplexer (TS3USB221). The same multiplexer is connected the LTE module and the output is switched if the bus voltage is detected on the micro-USB connector. This means that we do not have a connector in Linux kernel space, although it is present for the bootloader needs.
I also tried to compare the migrated code generated from STM32CubeMX with the generated code for stm32mp157c-dk2 and apart from USB-C usage, there is a difference in supply regulators that are not in the generated code.
Could the issue be related to the used USB connector?
Best regards,
Tomas
2022-05-19 12:29 AM
Hi Kevin,
I noticed that there is a regulator issue when initializing the dwc2 driver, so I tried to debug which one is it and it looks like reg18 (defined here). So I focused on this and compared the generated DTS for DK2 kit with the one I use and I am really missing the regulators supply for VDD and vdd_3v3_usbfs. So I added it like this:
&pwr_regulators{
status = "okay";
/* USER CODE BEGIN pwr_regulators */
vdd-supply = <&vdd>;
vdd_3v3_usbfs-supply = <&vdd_usb>;
/* USER CODE END pwr_regulators */
};
But unfortunately still no improvement. I am attaching the full dmesg output with the modified stm32-pwr-regulator driver. The modification consists only of the dumping call stack and regulator name when the enabling regulator timeouts.
Regards,
Tomas.
2022-06-01 05:57 AM
Hello @Tom�? Ju?ena ,
Sorry for the delay, I was on vacations.
Did you make some progress on this post?
Regards,
Kevin
2022-06-02 12:54 AM
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
2022-06-02 09:56 AM
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
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
2022-06-03 07:30 AM
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