Skip to main content
Yoichi Shinoda
Senior
November 20, 2018
Question

STM32H743 USB_OTG_FS not responding to core reset?

  • November 20, 2018
  • 4 replies
  • 3431 views

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.

This topic has been closed for replies.

4 replies

waclawek.jan
Super User
November 20, 2018

> 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
Senior
November 22, 2018

@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
Senior
November 22, 2018

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
Super User
November 22, 2018

Thanks for coming back with the solution.

JW