Has anyone used the USB HS port used as a USB FS on STM32F4?


Li, Jun R
 

Hi,

 

I have a STM32F429 board on which the USB high speed port (pinned out by PB14 and PB15) is exposed as a USB normal speed port, compared with the USB FS port from PA11 and PA12 usually on other STM32F4’s discovery boards. I’m sure the high speed USB port on PB14 and PB15 can work as a normal speed USB port since we have another working firmware running on the same board and using the same USB port.

 

Now I’m trying to port Zephyr 1.12 to this board, and enabling this USB port. I’ve checked the USB device driver file: drivers/usb/device/usb_dc_stm32.c and found that it seems the high speed USB port is already supported if the macro “USB” is enabled. However, I can’t find where the macro “USB” can be enabled. So, I’m wondering if anyone has used the USB port on PB14 and PB15 with Zephyr and enabled the macro “USB”?

 

Also, the macro “USB” is very confusing with zephyr’s macro “CONFIG_USB”. I recommend to rename this one with other proper name.  The macro seems to have been introduced by Yannis Damigos. So, I’m cc’ing Yannis Damigos here, trying to get his attention to this.

 

Thank you!

 

Jun Li @ Intel

 


Erwan Gouriou
 

Hi Jun Li,

About 'USB' flag, you might be interested by the following comment, file sub_dc_stm32.c, line72:
/*
 * USB and USB_OTG_FS are defined in STM32Cube HAL and allows to distinguish
 * between two kind of USB DC. STM32 F0, F3, and L0 series support USB device
 * controller. STM32 F4 and F7 series support USB_OTG_FS device controller.
 * STM32 F1 and L4 series support either USB or USB_OTG_FS device controller.
 *
 * WARNING: Don't mix USB defined in STM32Cube HAL and CONFIG_USB from Zephyr
 * Kconfig system.
 */

I agree the name of 'USB' is unfortunate, I've submitted a request to change it.
This might take a while though.

Cheers
Erwan


On Fri, 6 Jul 2018 at 03:21, Li, Jun R <jun.r.li@...> wrote:

Hi,

 

I have a STM32F429 board on which the USB high speed port (pinned out by PB14 and PB15) is exposed as a USB normal speed port, compared with the USB FS port from PA11 and PA12 usually on other STM32F4’s discovery boards. I’m sure the high speed USB port on PB14 and PB15 can work as a normal speed USB port since we have another working firmware running on the same board and using the same USB port.

 

Now I’m trying to port Zephyr 1.12 to this board, and enabling this USB port. I’ve checked the USB device driver file: drivers/usb/device/usb_dc_stm32.c and found that it seems the high speed USB port is already supported if the macro “USB” is enabled. However, I can’t find where the macro “USB” can be enabled. So, I’m wondering if anyone has used the USB port on PB14 and PB15 with Zephyr and enabled the macro “USB”?

 

Also, the macro “USB” is very confusing with zephyr’s macro “CONFIG_USB”. I recommend to rename this one with other proper name.  The macro seems to have been introduced by Yannis Damigos. So, I’m cc’ing Yannis Damigos here, trying to get his attention to this.

 

Thank you!

 

Jun Li @ Intel

 


Yannis Damigos
 

Hi,

STM32F429 SoCs support OTG FS USB. Check 96b_carbon board as a
reference to enable it.
You should also configure pinmux for PB14 and PB15.

Regards,
Yannis

On Fri, Jul 6, 2018 at 10:34 AM Erwan Gouriou <erwan.gouriou@linaro.org> wrote:

Hi Jun Li,

About 'USB' flag, you might be interested by the following comment, file sub_dc_stm32.c, line72:
/*
* USB and USB_OTG_FS are defined in STM32Cube HAL and allows to distinguish
* between two kind of USB DC. STM32 F0, F3, and L0 series support USB device
* controller. STM32 F4 and F7 series support USB_OTG_FS device controller.
* STM32 F1 and L4 series support either USB or USB_OTG_FS device controller.
*
* WARNING: Don't mix USB defined in STM32Cube HAL and CONFIG_USB from Zephyr
* Kconfig system.
*/

I agree the name of 'USB' is unfortunate, I've submitted a request to change it.
This might take a while though.

Cheers
Erwan

On Fri, 6 Jul 2018 at 03:21, Li, Jun R <jun.r.li@intel.com> wrote:

Hi,



I have a STM32F429 board on which the USB high speed port (pinned out by PB14 and PB15) is exposed as a USB normal speed port, compared with the USB FS port from PA11 and PA12 usually on other STM32F4’s discovery boards. I’m sure the high speed USB port on PB14 and PB15 can work as a normal speed USB port since we have another working firmware running on the same board and using the same USB port.



Now I’m trying to port Zephyr 1.12 to this board, and enabling this USB port. I’ve checked the USB device driver file: drivers/usb/device/usb_dc_stm32.c and found that it seems the high speed USB port is already supported if the macro “USB” is enabled. However, I can’t find where the macro “USB” can be enabled. So, I’m wondering if anyone has used the USB port on PB14 and PB15 with Zephyr and enabled the macro “USB”?



Also, the macro “USB” is very confusing with zephyr’s macro “CONFIG_USB”. I recommend to rename this one with other proper name. The macro seems to have been introduced by Yannis Damigos. So, I’m cc’ing Yannis Damigos here, trying to get his attention to this.



Thank you!



Jun Li @ Intel




Aurelien Jarno
 

Hi,

On 2018-07-06 12:27, Yannis Damigos wrote:
Hi,

STM32F429 SoCs support OTG FS USB. Check 96b_carbon board as a
reference to enable it.
You should also configure pinmux for PB14 and PB15.
I don't think that's possible. PB14 and PB15 can only be mapped to the
full-speed OTG_HS PHY, not the to the full-speed OTG_FS PHY (yes, this
is confusing).

I don't think there is a way to enable both ports at the same time given
how the USB API is designed (it doesn't take a usb device in argument).
That said it would be nice if we can choose either via Kconfig or via
device tree which of the two OTG ports to use on STM32F4 and STM32F7
families. Any suggestion how to do that?

I am interesting to get the OTG_HS working on the STM32F723 at some
point, as it has an integrated full speed PHY.

Aurelien

--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net


Yannis Damigos
 

I don't think that's possible. PB14 and PB15 can only be mapped to the
full-speed OTG_HS PHY, not the to the full-speed OTG_FS PHY (yes, this
is confusing).
I misunderstood the question. I thought that OTG FS was mapped to PB14 / PB15.
I didn't tested usb_dc_stm32 using OTG_HS PHY.

Yannis


Li, Jun R
 

Hi Aurelien and Yannis,

 

Based on the datasheet of STM32F429(Page 40), the OTG_HS port supports both full-speed with its integrated transceiver or high-speed with an external Phy. So, the port can still be used as a full-speed USB port without any hardware efforts, which is the way I’m using it on a 429 board I have.

 

To support it, we just need to use the corresponding registers for OTG_HS. This is what I’m expecting. So, I’m wondering where the macro “USB” will be enabled? I think renaming it to something else like CONFIG_HAS_USB_OTG_HS would be more meaningful.

 

Regards,

Jun

 

 

On 7/6/18, 07:00, "Yannis Damigos" <giannis.damigos@...> wrote:

 

    > I don't think that's possible. PB14 and PB15 can only be mapped to the

    > full-speed OTG_HS PHY, not the to the full-speed OTG_FS PHY (yes, this

    > is confusing).

   

    I misunderstood the question. I thought that OTG FS was mapped to PB14 / PB15.

    I didn't tested usb_dc_stm32 using OTG_HS PHY.

   

    Yannis

    


Yannis Damigos
 

Hi Jun,

On 07/06/2018 06:32 PM, Li, Jun R wrote:
Based on the datasheet <https://www.st.com/resource/en/datasheet/stm32f427vg.pdf> of STM32F429(Page 40), the OTG_HS port supports both full-speed with its integrated transceiver or high-speed with an external Phy. So, the port can still be used as a full-speed USB port without any hardware efforts, which is the way I’m using it on a 429 board I have.

 

To support it, we just need to use the corresponding registers for OTG_HS. This is what I’m expecting. So, I’m wondering where the macro “USB” will be enabled? I think renaming it to something else like CONFIG_HAS_USB_OTG_HS would be more meaningful.
I haven't checked the USB_OTG_HS in STM32Cube and I don't know if it will work out of the box with the usb_dc_stm32 driver. Probably not.
We need to create a second instance of a "USB device" (the driver right now doesn't support this). We also need to add support for this peripheral in the DT.
CONFIG_HAS_USB_OTG_HS (or just CONFIG_USB_OTG_HS) sounds reasonable to me.

Yannis


Li, Jun R
 

Hi Yannis,

The OTG_HS USB on my board is working with a modified version of the earlier usb_dc_stm32.c on zephyr 1.9. (usb_dc_stm32.c was actually imported from a PR which had not been merged.). We did some modifications to make it work for the OTG_HS port. I can forward that modified file to you if you'd like to take a look. Also, You should be the right person to integrate this feature since most changes on the latest usb_dc_stm32.c come from you.

Regards,
Jun


On 7/6/18, 10:07, "Yannis Damigos" <giannis.damigos@gmail.com> wrote:

Hi Jun,

On 07/06/2018 06:32 PM, Li, Jun R wrote:
> Based on the datasheet <https://www.st.com/resource/en/datasheet/stm32f427vg.pdf> of STM32F429(Page 40), the OTG_HS port supports both full-speed with its integrated transceiver or high-speed with an external Phy. So, the port can still be used as a full-speed USB port without any hardware efforts, which is the way I’m using it on a 429 board I have.
>
>
>
> To support it, we just need to use the corresponding registers for OTG_HS. This is what I’m expecting. So, I’m wondering where the macro “USB” will be enabled? I think renaming it to something else like CONFIG_HAS_USB_OTG_HS would be more meaningful.
>

I haven't checked the USB_OTG_HS in STM32Cube and I don't know if it will work out of the box with the usb_dc_stm32 driver. Probably not.
We need to create a second instance of a "USB device" (the driver right now doesn't support this). We also need to add support for this peripheral in the DT.
CONFIG_HAS_USB_OTG_HS (or just CONFIG_USB_OTG_HS) sounds reasonable to me.

Yannis


Yannis Damigos
 

Hi Jun,

The OTG_HS USB on my board is working with a modified version of the earlier usb_dc_stm32.c on zephyr 1.9. (usb_dc_stm32.c was actually imported from a PR which had not been merged.). We did some modifications to make it work for the OTG_HS port. I can forward that modified file to you if you'd like to take a look. Also, You should be the right person to integrate this feature since most changes on the latest usb_dc_stm32.c come from you.
I' ll check the file and try to find a way to integrate it in the usb_dc_stm32 driver.
I' ll try to do it asap but as I work on zephyr on my free time, it may take a while.

Yannis


Yannis Damigos
 

Hi Jun and Aurelien,

I created the following branch in my repository to add support for OTG
HS: https://github.com/ydamigos/zephyr/commits/stm32_otg_hs

It was tested on stm32f429 SoC by Jun and on STM32F723E-DISCO by Aurelien.

I updated my repository following your comments. Could you test it
again because I don't have the hw?

Before opening a PR upstream I would like to add support for the
boards you tested it. Could you open a pull request to my branch?

Please note that only one interface should be enabled at a time, OTG
FS or OTG HS. The driver will raise an error if both are enabled.

The USB API should change if we want to have them both enabled.

Yannis


Aurelien Jarno
 

Hi Yannis,

On 2018-07-10 11:30, Yannis Damigos wrote:
Hi Jun and Aurelien,

I created the following branch in my repository to add support for OTG
HS: https://github.com/ydamigos/zephyr/commits/stm32_otg_hs

It was tested on stm32f429 SoC by Jun and on STM32F723E-DISCO by Aurelien.

I updated my repository following your comments. Could you test it
again because I don't have the hw?
Thanks for this new version, and for working on it blindly without the
hardware.

I have just tested it on the STM32F723E-DISCO board on top PR#8667. I
had to do a few changes:
- The PHY has to be USB_OTG_HS_EMBEDDED_PHY on that board as it doesn't
have an embedded full-speed PHY
- The check on CONFIG_SERIES_STM32F7X is wrong and should be
CONFIG_SOC_SERIES_STM32F7X instead.

I also I believe that the STM32F7 SoCs without embedded HS speed behave
the same than the STM32F4. Therefore I think that both OTGHSULPI and
OTGPHYC clocks should be enabled if the SoC has an internal HS PHY,
otherwise OTGHSULPI should be disabled.

I have added a patch fixing the small issues and doing that changes at
the end of this mail.

Note that right now it's still work on full-speed mode even on this
board, but I think that should be changed later in a second step.

Before opening a PR upstream I would like to add support for the
boards you tested it. Could you open a pull request to my branch?
The support for USB on the board I tested is still not merged, it's
PR#8667. Then enabling it is just about replacing usbotg_fs by usbotg_hs
in stm32f723e_disco.dts. Strangely pinmux changes are not needed. I am
not sure which USB connector we want to enable as default on this board.

Aurelien


diff --git a/drivers/usb/device/usb_dc_stm32.c b/drivers/usb/device/usb_dc_stm32.c
index f11233535..c85bca9a5 100644
--- a/drivers/usb/device/usb_dc_stm32.c
+++ b/drivers/usb/device/usb_dc_stm32.c
@@ -248,17 +248,14 @@ static int usb_dc_stm32_clock_enable(void)

#ifdef CONFIG_USB_HS_BASE_ADDRESS

-#ifdef CONFIG_SERIES_STM32F7X
- LL_AHB1_GRP1_EnableClock(LL_AHB1_GRP1_PERIPH_OTGHSULPI);
-
#ifdef USB_HS_PHYC
+ /* Enable ULPI interface and internal high-speed PHY clocks */
+ LL_AHB1_GRP1_EnableClock(LL_AHB1_GRP1_PERIPH_OTGHSULPI);
LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_OTGPHYC);
-#endif /* USB_HS_PHYC
-
#else
/* Disable ULPI interface (for external high-speed PHY) clock */
LL_AHB1_GRP1_DisableClock(LL_AHB1_GRP1_PERIPH_OTGHSULPI);
-#endif /* CONFIG_SERIES_STM32F7X */
+#endif /* USB_HS_PHYC */

#endif /* CONFIG_USB_HS_BASE_ADDRESS */

@@ -285,7 +282,11 @@ static int usb_dc_stm32_init(void)
#endif
usb_dc_stm32_state.pcd.Init.dev_endpoints = CONFIG_USB_NUM_BIDIR_ENDPOINTS;
usb_dc_stm32_state.pcd.Init.speed = USB_OTG_SPEED_FULL;
+#ifdef USB_HS_PHYC
+ usb_dc_stm32_state.pcd.Init.phy_itface = USB_OTG_HS_EMBEDDED_PHY;
+#else
usb_dc_stm32_state.pcd.Init.phy_itface = PCD_PHY_EMBEDDED;
+#endif /* USB_HS_PHYC */
usb_dc_stm32_state.pcd.Init.ep0_mps = USB_OTG_MAX_EP0_SIZE;
usb_dc_stm32_state.pcd.Init.vbus_sensing_enable = DISABLE;



--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net


Li, Jun R
 

Hi Yannis,

I verified your branch with samples/subsys/usb/cdc_acm on my customized STM32F429 board, and found enumeration issues:

 

[6176209.029339] usb 1-1.5.2.1: new full-speed USB device number 30 using ehci-pci

[6176209.437330] usb 1-1.5.2.1: device not accepting address 30, error -32

[6176209.525325] usb 1-1.5.2.1: new full-speed USB device number 31 using ehci-pci

[6176209.933339] usb 1-1.5.2.1: device not accepting address 31, error -32

[6176209.933545] usb 1-1.5.2-port1: unable to enumerate USB device

 

I double checked your code again and found you removed the following two lines on the line 247 which I had recommended:

        LL_AHB1_GRP1_DisableClockLowPower(RCC_AHB1LPENR_OTGHSULPILPEN);

        LL_AHB1_GRP1_EnableClockLowPower(RCC_AHB1LPENR_OTGHSLPEN);

 

Without these two lines, the USB_OTG_HS port doesn't work, can't be enumerated.

 

After adding those two lines, the usb was correctly enumerated and the cdc_acm works well:

 

[6176395.476959] usb 1-1.5.2.1: new full-speed USB device number 32 using ehci-pci

[6176395.587715] usb 1-1.5.2.1: New USB device found, idVendor=2fe3, idProduct=0100

[6176395.587729] usb 1-1.5.2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[6176395.587732] usb 1-1.5.2.1: Product: Zephyr CDC ACM sample

[6176395.587734] usb 1-1.5.2.1: Manufacturer: ZEPHYR

[6176395.587736] usb 1-1.5.2.1: SerialNumber: 0.01

[6176395.588150] cdc_acm 1-1.5.2.1:1.0: ttyACM2: USB ACM device

 

So, can you add those two lines back to your branch?

 

Best Regards,

Jun

 

On 7/10/18, 01:30, "devel@... on behalf of Yannis Damigos" <devel@... on behalf of giannis.damigos@...> wrote:

 

    Hi Jun and Aurelien,

   

    I created the following branch in my repository to add support for OTG

    HS: https://github.com/ydamigos/zephyr/commits/stm32_otg_hs

   

    It was tested on stm32f429 SoC by Jun and on STM32F723E-DISCO by Aurelien.

   

    I updated my repository following your comments. Could you test it

    again because I don't have the hw?

   

    Before opening a PR upstream I would like to add support for the

    boards you tested it. Could you open a pull request to my branch?

   

    Please note that only one interface should be enabled at a time, OTG

    FS or OTG HS. The driver will raise an error if both are enabled.

   

    The USB API should change if we want to have them both enabled.

   

    Yannis

   

    

   

    


Yannis Damigos
 

Hi Aurelien,

Thanks for reviewing it.

- The PHY has to be USB_OTG_HS_EMBEDDED_PHY on that board as it doesn't
have an embedded full-speed PHY
Strange. STM32F72xxx SoC reference manual mentions an on-chip full-speed PHY.

- The check on CONFIG_SERIES_STM32F7X is wrong and should be
CONFIG_SOC_SERIES_STM32F7X instead.
Fixed.

I also I believe that the STM32F7 SoCs without embedded HS speed behave
the same than the STM32F4. Therefore I think that both OTGHSULPI and
OTGPHYC clocks should be enabled if the SoC has an internal HS PHY,
otherwise OTGHSULPI should be disabled.
I agree. That's why I am trying to find a way to define the PHYs
(maybe in device tree).

diff --git a/drivers/usb/device/usb_dc_stm32.c b/drivers/usb/device/usb_dc_stm32.c
index f11233535..c85bca9a5 100644
--- a/drivers/usb/device/usb_dc_stm32.c
+++ b/drivers/usb/device/usb_dc_stm32.c
@@ -248,17 +248,14 @@ static int usb_dc_stm32_clock_enable(void)

#ifdef CONFIG_USB_HS_BASE_ADDRESS

-#ifdef CONFIG_SERIES_STM32F7X
- LL_AHB1_GRP1_EnableClock(LL_AHB1_GRP1_PERIPH_OTGHSULPI);
-
#ifdef USB_HS_PHYC
+ /* Enable ULPI interface and internal high-speed PHY clocks */
+ LL_AHB1_GRP1_EnableClock(LL_AHB1_GRP1_PERIPH_OTGHSULPI);
LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_OTGPHYC);
-#endif /* USB_HS_PHYC
-
#else
/* Disable ULPI interface (for external high-speed PHY) clock */
LL_AHB1_GRP1_DisableClock(LL_AHB1_GRP1_PERIPH_OTGHSULPI);
-#endif /* CONFIG_SERIES_STM32F7X */
+#endif /* USB_HS_PHYC */

#endif /* CONFIG_USB_HS_BASE_ADDRESS */
USB_HS_PHYC is not defined on all STM32F7 SoCs, so enabling ULPI clock
if it is defined won't
work on other SoCs.

@@ -285,7 +282,11 @@ static int usb_dc_stm32_init(void)
#endif
usb_dc_stm32_state.pcd.Init.dev_endpoints = CONFIG_USB_NUM_BIDIR_ENDPOINTS;
usb_dc_stm32_state.pcd.Init.speed = USB_OTG_SPEED_FULL;
+#ifdef USB_HS_PHYC
+ usb_dc_stm32_state.pcd.Init.phy_itface = USB_OTG_HS_EMBEDDED_PHY;
+#else
usb_dc_stm32_state.pcd.Init.phy_itface = PCD_PHY_EMBEDDED;
+#endif /* USB_HS_PHYC */
usb_dc_stm32_state.pcd.Init.ep0_mps = USB_OTG_MAX_EP0_SIZE;
usb_dc_stm32_state.pcd.Init.vbus_sensing_enable = DISABLE;
The PR is focused on enabling FS mode on OTG_HS that's why I didn't
change PHY interface.

Yannis


Yannis Damigos
 

Hi Jun,

thanks for testing.

I double checked your code again and found you removed the following two lines on the line 247 which I had recommended:

LL_AHB1_GRP1_DisableClockLowPower(RCC_AHB1LPENR_OTGHSULPILPEN);

LL_AHB1_GRP1_EnableClockLowPower(RCC_AHB1LPENR_OTGHSLPEN);
Why do you enable the clocks in low power mode?

Line 260 in my tree
LL_AHB1_GRP1_DisableClock(LL_AHB1_GRP1_PERIPH_OTGHSULPI); disables
ULPI clock.
OTG_HS clock is enabled by lines 184-187.

STM32Cube HAL defines:
#define LL_AHB1_GRP1_PERIPH_OTGHS RCC_AHB1ENR_OTGHSEN
#define LL_AHB1_GRP1_PERIPH_OTGHSULPI RCC_AHB1ENR_OTGHSULPIEN

and functions LL_AHB1_GRP1_EnableClock, LL_AHB1_GRP1_DisableClock,
LL_AHB1_GRP1_DisableClockLowPower,
LL_AHB1_GRP1_EnableClockLowPower mentions
LL_AHB1_GRP1_PERIPH_OTGHSULPI and LL_AHB1_GRP1_PERIPH_OTGHSULPI
as valid parameters.

Could you check again I found a typo in ifdefs which didn't disable ULPI clock?

Yannis


Li, Jun R
 

Yes, it works. The two lines are not needed, actually. Sorry for confusing!

Regards,
Jun


On 7/11/18, 01:16, "Yannis Damigos" <giannis.damigos@gmail.com> wrote:

Hi Jun,

thanks for testing.

> I double checked your code again and found you removed the following two lines on the line 247 which I had recommended:
>
> LL_AHB1_GRP1_DisableClockLowPower(RCC_AHB1LPENR_OTGHSULPILPEN);
>
> LL_AHB1_GRP1_EnableClockLowPower(RCC_AHB1LPENR_OTGHSLPEN);
>

Why do you enable the clocks in low power mode?

Line 260 in my tree
LL_AHB1_GRP1_DisableClock(LL_AHB1_GRP1_PERIPH_OTGHSULPI); disables
ULPI clock.
OTG_HS clock is enabled by lines 184-187.

STM32Cube HAL defines:
#define LL_AHB1_GRP1_PERIPH_OTGHS RCC_AHB1ENR_OTGHSEN
#define LL_AHB1_GRP1_PERIPH_OTGHSULPI RCC_AHB1ENR_OTGHSULPIEN

and functions LL_AHB1_GRP1_EnableClock, LL_AHB1_GRP1_DisableClock,
LL_AHB1_GRP1_DisableClockLowPower,
LL_AHB1_GRP1_EnableClockLowPower mentions
LL_AHB1_GRP1_PERIPH_OTGHSULPI and LL_AHB1_GRP1_PERIPH_OTGHSULPI
as valid parameters.

Could you check again I found a typo in ifdefs which didn't disable ULPI clock?

Yannis


Aurelien Jarno
 

On 2018-07-11 11:03, Yannis Damigos wrote:
Hi Aurelien,

Thanks for reviewing it.

- The PHY has to be USB_OTG_HS_EMBEDDED_PHY on that board as it doesn't
have an embedded full-speed PHY
Strange. STM32F72xxx SoC reference manual mentions an on-chip full-speed PHY.
All the STM32F7 SoCs except the STM32F723 have an on-chip FS PHY, just
like the STM32F4 family. The STM32F723 only has an on-chip HS PHY and
does not have the FS PHY.

You can see that on RM0431, pages 1172 and 1173.

- The check on CONFIG_SERIES_STM32F7X is wrong and should be
CONFIG_SOC_SERIES_STM32F7X instead.
Fixed.

I also I believe that the STM32F7 SoCs without embedded HS speed behave
the same than the STM32F4. Therefore I think that both OTGHSULPI and
OTGPHYC clocks should be enabled if the SoC has an internal HS PHY,
otherwise OTGHSULPI should be disabled.
I agree. That's why I am trying to find a way to define the PHYs
(maybe in device tree).

diff --git a/drivers/usb/device/usb_dc_stm32.c b/drivers/usb/device/usb_dc_stm32.c
index f11233535..c85bca9a5 100644
--- a/drivers/usb/device/usb_dc_stm32.c
+++ b/drivers/usb/device/usb_dc_stm32.c
@@ -248,17 +248,14 @@ static int usb_dc_stm32_clock_enable(void)

#ifdef CONFIG_USB_HS_BASE_ADDRESS

-#ifdef CONFIG_SERIES_STM32F7X
- LL_AHB1_GRP1_EnableClock(LL_AHB1_GRP1_PERIPH_OTGHSULPI);
-
#ifdef USB_HS_PHYC
+ /* Enable ULPI interface and internal high-speed PHY clocks */
+ LL_AHB1_GRP1_EnableClock(LL_AHB1_GRP1_PERIPH_OTGHSULPI);
LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_OTGPHYC);
-#endif /* USB_HS_PHYC
-
#else
/* Disable ULPI interface (for external high-speed PHY) clock */
LL_AHB1_GRP1_DisableClock(LL_AHB1_GRP1_PERIPH_OTGHSULPI);
-#endif /* CONFIG_SERIES_STM32F7X */
+#endif /* USB_HS_PHYC */

#endif /* CONFIG_USB_HS_BASE_ADDRESS */
USB_HS_PHYC is not defined on all STM32F7 SoCs, so enabling ULPI clock
if it is defined won't
work on other SoCs.
The idea is to disable the ULPI clock for SoCs which do not have an HS
PHY, as the FS PHY should be used instead. If USB_HS_PHYC is defined,
the SoC has an HS PHY but not FS PHY, when it is not defined, it has a
FS PHY but no HS PHY.

@@ -285,7 +282,11 @@ static int usb_dc_stm32_init(void)
#endif
usb_dc_stm32_state.pcd.Init.dev_endpoints = CONFIG_USB_NUM_BIDIR_ENDPOINTS;
usb_dc_stm32_state.pcd.Init.speed = USB_OTG_SPEED_FULL;
+#ifdef USB_HS_PHYC
+ usb_dc_stm32_state.pcd.Init.phy_itface = USB_OTG_HS_EMBEDDED_PHY;
+#else
usb_dc_stm32_state.pcd.Init.phy_itface = PCD_PHY_EMBEDDED;
+#endif /* USB_HS_PHYC */
usb_dc_stm32_state.pcd.Init.ep0_mps = USB_OTG_MAX_EP0_SIZE;
usb_dc_stm32_state.pcd.Init.vbus_sensing_enable = DISABLE;
The PR is focused on enabling FS mode on OTG_HS that's why I didn't
change PHY interface.
I understand that, that's why my patch didn't change USB_OTG_SPEED_FULL
(but I have verified it work in HS mode). That said given that there is
no FS PHY when there is an HS PHY, we need to use it in FS mode instead.

Aurelien

--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net


Yannis Damigos
 

All the STM32F7 SoCs except the STM32F723 have an on-chip FS PHY, just
like the STM32F4 family. The STM32F723 only has an on-chip HS PHY and
does not have the FS PHY.

You can see that on RM0431, pages 1172 and 1173.

The idea is to disable the ULPI clock for SoCs which do not have an HS
PHY, as the FS PHY should be used instead. If USB_HS_PHYC is defined,
the SoC has an HS PHY but not FS PHY, when it is not defined, it has a
FS PHY but no HS PHY.
Thanks for the pointers. I updated my tree accordingly.

Yannis


Aurelien Jarno
 

On 2018-07-11 13:04, Yannis Damigos wrote:
All the STM32F7 SoCs except the STM32F723 have an on-chip FS PHY, just
like the STM32F4 family. The STM32F723 only has an on-chip HS PHY and
does not have the FS PHY.

You can see that on RM0431, pages 1172 and 1173.

The idea is to disable the ULPI clock for SoCs which do not have an HS
PHY, as the FS PHY should be used instead. If USB_HS_PHYC is defined,
the SoC has an HS PHY but not FS PHY, when it is not defined, it has a
FS PHY but no HS PHY.
Thanks for the pointers. I updated my tree accordingly.
Thanks, I confirm it works well on STM32F723E-DISCO, by just changing
the device tree to disable usbotg_fs and enable usbotg_hs.

Aurelien

--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net