cancel
Showing results for 
Search instead for 
Did you mean: 

USB Core Soft Reset problem in MX_USB_DEVICE_Init() for STM32F407VE

risingEdge
Associate II

There are a lot of entries about this problem as I saw. But I also want to tell my story :D

STM32F407VE is used as MCU and USB3320 is used as external PHY for obtaining high speed rate in USB operations. And, STM32CUBE IDE is used to generate code and debug the code in MCU in my PCB. 

the initial optimizations for USB_OTG_HS and CDC Class are done according to documents in literature, and then the clock that is sent to MCU(from USB3320) is 60 Mhz. However USB_CoreInit() function in HAL Driver of " stm32f4xx_ll_usb.c " return to HAL_TIMEOUT and MX_USB_DEVICE_Init() goes into directly while(1) loop inside the "Error Handler". As shared code below;

USB->GRSTCTL |= USB_OTG_GRSTCTL_CSRST;

 do

 {

  if (++count > 200000U)

  {

   return TIMEOUT; /// After counter code returns with TIMEOUT error\\\

  }

 }

 while ((USB->GRSTCTL & USB_OTG_GRSTCTL_CSRST) == USB_OTG_GRSTCTL_CSRST);

What can be possible reasons for why USB Core does not take soft reset?  

If you have any idea, please share with me and this community for possible future problem :/

2 REPLIES 2

First, check you have OTG_HS_ULPI_CK clock as required, i.e. check presence of clock on PA5 and check in GPIO that PA5 is properly set; also check in RCC if both OTG_HS enable bits are set.

Also, read https://community.st.com/s/question/0D53W000018UaLFSA0/otg-usb-delay-needed-between-selecting-phy-and-softreset

JW

risingEdge
Associate II

First, thank you so much for guidance. I checked the clock generating from usb3320. that is at desired frequency and RCC for high speed also is set. however, when I look at the shared link, I recognize that the link is about internal FS phy whereas my concern is about external HS phy . if you have any ideas about external hs phy, i will glad to hear them :l.

Since i didnt find the deep information about why usb core take soft reset, i dont know when usb core take soft reset( so, the code gets rid of returning HAL_TIMEOUT error) ? Should i suspect my hardware in my PCB or there could be an unlucky bug in stm32cube ide program(possible software problem).