STM32H743 USB_OTG_FS not responding to core reset?

[Yoichi Shinoda]

I have an application program running on a Nucleo-H743. While most of other components are working, I'm having trouble with onboard USB to work.

The USB handling is ported from CDC_Standalone application example for EVAL from STM32Cube_FW_H7_v1.3.0.

After some investigation, I found that the USB_OTG_FS is not responding to core reset command in USB_CoreReset called from USB_CoreInit, which in turn called from HAL_PCD_Init after HAL_PCD_Msp_Init is called, which is very early in the process of USB handling.

The failing function USB_CoreReset is

static HAL_StatusTypeDef USB_CoreReset(USB_OTG_GlobalTypeDef *USBx)
{
  uint32_t count = 0;
 
  /* Wait for AHB master IDLE state. */
  do
  {
    if (++count > 200000)
    {
      return HAL_TIMEOUT;
    }
  }
  while ((USBx->GRSTCTL & USB_OTG_GRSTCTL_AHBIDL) == 0);
  
  /* Core Soft Reset */
  count = 0;
  USBx->GRSTCTL |= USB_OTG_GRSTCTL_CSRST;
 
  do
  {
    if (++count > 200000)
    {
      return HAL_TIMEOUT;
    }
  }
  while ((USBx->GRSTCTL & USB_OTG_GRSTCTL_CSRST) == USB_OTG_GRSTCTL_CSRST);
  
  return HAL_OK;
}

The USB_OTG_GRSTCTL_CSRST bit set at line 17 is never cleared and the function returns HAL_TIMEOUT.

If I interrupt DFU boot loader in the middle of an active boot loading process, I can manually set the USB_OTG_GRSTCTL_CSRST bit and observe it is self cleared.

What would be probable causes for this symptom?

EDIT:

The USB_OTG_FS should be clocked by HSI48 now, but PLL3 just like the original example did not work either.

[waclawek.jan]

> The USB_OTG_FS should be clocked by HSI48 now, but PLL3 just like the original example did not work either.

Did you confirm the clocking selection, and that the USB clock is enabled at all, by reading out and checking the related RCC registers?

JW

[Yoichi Shinoda]

@Community member​ Yes, the HSI48 clock was running okay (it has been checked by feeding it to MCO).

However, we found the source of the issue, and the USB/VCP is now running.

[Yoichi Shinoda]

The problem was that non-working code had both ULPI and non-ULPI enabled.

    __HAL_RCC_USB2_OTG_FS_CLK_ENABLE();
    __HAL_RCC_USB2_OTG_FS_ULPI_CLK_ENABLE();

After disabling the ULPI call, the onboard USB started to work.

    __HAL_RCC_USB2_OTG_FS_CLK_ENABLE();
    //__HAL_RCC_USB2_OTG_FS_ULPI_CLK_ENABLE();

[waclawek.jan]

Thanks for coming back with the solution.

JW