STM32U595 timeout in USB_CoreReset()

[Lukasz Nowak]

I am working on a project using USB HS with:

STM32U595VJT
STM32CubeIDE 1.14.0
STM32Cube_FW_U5_V1.4.0

Using the init code, as generated by CubeMX, I was getting HAL_TIMEOUT returned by USB_CoreReset():

MX_USB_OTG_HS_PCD_Init() -> HAL_PCD_Init() -> USB_CoreInit() -> USB_CoreReset()

After looking into example applications, e.g.:

STM32Cube_FW_U5_V1.4.0/Projects/NUCLEO-U5A5ZJ-Q/Applications/USBX/Ux_Device_CDC_ACM/Core/Src/stm32u5xx_hal_msp.c

the problem turns out to be a missing call to:

__HAL_RCC_SYSCFG_CLK_ENABLE();

CubeMX code does not generate it.

The application example has it in the "USER CODE" section:

void HAL_PCD_MspInit(PCD_HandleTypeDef* hpcd)
{
  RCC_PeriphCLKInitTypeDef PeriphClkInit = {0};
  if(hpcd->Instance==USB_OTG_HS)
  {
  /* USER CODE BEGIN USB_OTG_HS_MspInit 0 */

    __HAL_RCC_SYSCFG_CLK_ENABLE();

  /* USER CODE END USB_OTG_HS_MspInit 0 */

This seems to be specific to chips with USB HS (U595, U599, U5A5, U5A9).

As the USB is not usable without it, can this missing call be added to output code generated by CubeMX?

Thank you.

[KDJEM.1]

Hello @Lukasz Nowak ,

Thank you for sharing this issue.

I confirm the issue and it has already been reported internally.

Internal ticket number: 157784 (This is an internal tracking number and is not accessible or usable by customers).

Kaouthar

[Raees]

Hello,

Getting the same issue with an STM32F722RET. HAL_TIMEOUT returned by USB_CoreReset():

But at the same time, USB_OTG_FS init is working and there is no time-out. 

Any solution or workaround for this issue?

[KDJEM.1 · Accepted solution]

Hello,

@Lukasz Nowak The issue is fixed in STM32CubeIDE1.16.0 and STM32Cube MX 6.12.0 versions.

void HAL_PCD_MspInit(PCD_HandleTypeDef* hpcd)
{
  RCC_PeriphCLKInitTypeDef PeriphClkInit = {0};
  if(hpcd->Instance==USB_OTG_HS)
  {
  /* USER CODE BEGIN USB_OTG_HS_MspInit 0 */

    __HAL_RCC_SYSCFG_CLK_ENABLE();

  /* USER CODE END USB_OTG_HS_MspInit 0 */

  /** Initializes the peripherals clock
  */
    PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_USBPHY;
    PeriphClkInit.UsbPhyClockSelection = RCC_USBPHYCLKSOURCE_HSE;
    if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInit) != HAL_OK)
    {
      Error_Handler();
    }

@Raees Could you please try with the last version of STM32CubeMx and let me know if the issue is solved.

I have noted that __HAL_RCC_SYSCFG_CLK_ENABLE(); has been included stm32f7xx_hal_msp.c file.

Please take a look at these examples may help you STM32CubeF7/Projects/STM32F722ZE-Nucleo/Applications/USB_Device at master · STMicroelectronics/STM32CubeF7 · GitHub

Thank you.

Kaouthar

[Raees]

It's working now. But I have to comment this line __HAL_RCC_USB_OTG_HS_ULPI_CLK_ENABLE(); line in the CubeIDE generated code for it to work

[KDJEM.1]

Hi @Raees ,

I think you're facing a different issue than the one originally reported in the initial thread.

For that I recommend you to create a dedicate post for the new issue.

Also, I advise you to share your .ioc file for checking.

Thank you.

Kaouthar 

[Lukasz Nowak]

Hi @KDJEM.1 

I can confirm that the code generated by STM32CubeIDE 1.16.0 for STM32U595 is correct now. The missing line has been added.

While trying to test it, I still had USB_CoreReset() failing to exit. It was looping here:

  do
  {
    count++;

    if (count > HAL_USB_TIMEOUT)
    {
      return HAL_TIMEOUT;
    }
  } while ((USBx->GRSTCTL & USB_OTG_GRSTCTL_CSRST) == USB_OTG_GRSTCTL_CSRST);

The USB_OTG_GRSTCTL_CSRST was not getting cleared.

I was able to fix it by switching OTG HS Clock Mux from HSE / 2 (my crystal is 32 MHz) to PLL1P:

System Clock Mux is set to PLLCLK, PLL1 Source Mux is HSE.

With PLL1P, USB_CoreReset() returns successfully. With HSE / 2 - it does not.

If I switch OTG PHY ref clock to 32 MHz and use HSE as source, it also works correctly. So the problem appears to be with the HSE / 2 setting only.

I am not sure if you want to track it here. The original problem, with the missing __HAL_RCC_SYSCFG_CLK_ENABLE() is fixed.

[KDJEM.1]

Hi @Lukasz Nowak ,

Thank you for confirming that the original issue has been fixed in STM32CubeIDE1.16.0 version.

To give more visibility, I recommend you to create a dedicate thread for this new issue.

Thank you for your contribution in STCommunity.

Kaouthar