STM32F429ZI HS USB: USB_CoreReset() timing out waiting for CSRST == 0

[Don Starr]

Posted on October 28, 2017 at 21:00

Custom board based on STM32F429ZI with Microchip USB3300-EZK HS PHY. The clocks and USB connections modeled on the STM32429I-EVAL1 schematic. I've verified that the CubeMX-generated code for my board looks just like what is generated for the EVAL1. The EVAL1 code works. At least, up through USB_CoreReset().

At startup, the code calls USB_CoreInit() which calls USB_CoreReset(), both instm32f4xx_ll_usb.c.

From USB_CoreReset():

 /* Core Soft Reset */
 count = 0U;
 USBx->GRSTCTL |= USB_OTG_GRSTCTL_CSRST;
 do
 {
 if (++count > 200000U)
 {
 return HAL_TIMEOUT; // <<<--- THIS LINE ALWAYS HIT
 }
 }
 while ((USBx->GRSTCTL & USB_OTG_GRSTCTL_CSRST) == USB_OTG_GRSTCTL_CSRST);
 
 return HAL_OK;
�?�?�?�?�?�?�?�?�?�?�?�?�?

Does completion of that reset depend on the 60MHz PHY clock from the USB3300 (USB_OTG_HS_ULPI_CK input to STM32F429) being active?

Any ideas why that clock might not be present? Based on the USB3300 data sheet, it looks like it should be running as long as the part has power, VBUS, and a 24MHz XTAL connected.

[waclawek.jan · Accepted solution]

Posted on October 29, 2017 at 11:54

Verify with oscilloscope if clock is actually present on OTG_HS_ULPI_CK. Verify, if that pin is properly set to AF in GPIO_MODER, and proper AF is selected in GPIO_AFRL/AFRH. Verify that both OTG_HS enable bits are set in RCC_AHB1ENR.

JW

[Don Starr]

Posted on October 29, 2017 at 16:59

Thanks for the reply.

No oscilloscope handy, but connecting a logic analyzer (1M ohm, 10pF) to the ULPI_CK input (USB3300's CLKOUT pin) does not show a 60MHz clock present. That's probably where my problem lies, if the '429 needs it before USB_OTG_GRSTCTL_CSRST will be cleared.

Looks like it might be a PCB layout problem. The USB3300's GND pins (pins 1 and 2) aren't actually connected to GND. And they (the guys who laid out the PCB) also tied that part's VDD1.8 and VDDA1.8 together. Some rework is in order. <time passes> After connecting pins 1 and 2 to GND, the '429 now gets past the reset successfully.

As far as pin configs, they look right...

The twelve USB_OTG_HS_ULPI_*** pins appear to be configured correctly:

 /**USB_OTG_HS GPIO Configuration 
 PC0 ------> USB_OTG_HS_ULPI_STP
 PC2 ------> USB_OTG_HS_ULPI_DIR
 PC3 ------> USB_OTG_HS_ULPI_NXT
 PA3 ------> USB_OTG_HS_ULPI_D0
 PA5 ------> USB_OTG_HS_ULPI_CK
 PB0 ------> USB_OTG_HS_ULPI_D1
 PB1 ------> USB_OTG_HS_ULPI_D2
 PB10 ------> USB_OTG_HS_ULPI_D3
 PB11 ------> USB_OTG_HS_ULPI_D4
 PB12 ------> USB_OTG_HS_ULPI_D5
 PB13 ------> USB_OTG_HS_ULPI_D6
 PB5 ------> USB_OTG_HS_ULPI_D7 
 */
 GPIO_InitStruct.Pin = GPIO_PIN_0|GPIO_PIN_2|GPIO_PIN_3;
 GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
 GPIO_InitStruct.Pull = GPIO_NOPULL;
 GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
 GPIO_InitStruct.Alternate = GPIO_AF10_OTG_HS;
 HAL_GPIO_Init(GPIOC, &GPIO_InitStruct);
 GPIO_InitStruct.Pin = GPIO_PIN_3|GPIO_PIN_5;
 GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
 GPIO_InitStruct.Pull = GPIO_NOPULL;
 GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
 GPIO_InitStruct.Alternate = GPIO_AF10_OTG_HS;
 HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
 GPIO_InitStruct.Pin = GPIO_PIN_0|GPIO_PIN_1|GPIO_PIN_10|GPIO_PIN_11 
 |GPIO_PIN_12|GPIO_PIN_13|GPIO_PIN_5;
 GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
 GPIO_InitStruct.Pull = GPIO_NOPULL;
 GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
 GPIO_InitStruct.Alternate = GPIO_AF10_OTG_HS;
 HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

(Of course, I'm presuming that HAL_GPIO_Init() works correctly. That seems to be the case, as other AFs I've set up for other pins/functions are working - e.g. the 4-bit-wide SD interface, five timer PWM outputs.)

After the above GPIO inits of the ULPI pins, HAL_PCD_MspInit() then sets up the OTG_HS bits in RCC_AHB1ENR:

 /* Peripheral clock enable */
 __HAL_RCC_USB_OTG_HS_CLK_ENABLE();
 __HAL_RCC_USB_OTG_HS_ULPI_CLK_ENABLE();
�?�?�?

Those are from stm32f4xx_hal_rcc_ex.h:

#define __HAL_RCC_USB_OTG_HS_CLK_ENABLE() do { \
 __IO uint32_t tmpreg = 0x00U; \
 SET_BIT(RCC->AHB1ENR, RCC_AHB1ENR_OTGHSEN);\
 /* Delay after an RCC peripheral clock enabling */ \
 tmpreg = READ_BIT(RCC->AHB1ENR, RCC_AHB1ENR_OTGHSEN);\
 UNUSED(tmpreg); \
 } while(0U)
#define __HAL_RCC_USB_OTG_HS_ULPI_CLK_ENABLE() do { \
 __IO uint32_t tmpreg = 0x00U; \
 SET_BIT(RCC->AHB1ENR, RCC_AHB1ENR_OTGHSULPIEN);\
 /* Delay after an RCC peripheral clock enabling */ \
 tmpreg = READ_BIT(RCC->AHB1ENR, RCC_AHB1ENR_OTGHSULPIEN);\
 UNUSED(tmpreg); \
 } while(0U)�?�?�?�?�?�?�?�?�?�?�?�?�?�?

[waclawek.jan]

Posted on October 30, 2017 at 10:58

After connecting pins 1 and 2 to GND, the '429 now gets past the reset successfully.

Thanks for letting us know.

(Of course, I'm presuming that HAL_GPIO_Init() works correctly.

I know I am ehm conservative, but I simply don't get this - isn't certainty worth a few clicks in debugger and perhaps two glances into the RM/DS?

(This was a rhetoric question, I don't expect answer, and it was not personal)

JW

[Don Starr]

Posted on October 30, 2017 at 13:41

I'll answer anyway 

Yes, it (verifying that HAL_GPIO_Init() works) was worth those clicks/glances. Prior to my original question, I'd already stepped through in the debugger, examining every line of the executed code and comparing read/written register values to those listed in the Reference Manual. That, combined with the fact that the EVAL1 board works, made me quite confident that HAL_GPIO_Init() was working correctly; I probably shouldn't have made that comment.

Thanks again for your help!

[MKing]

Hi,

I had the same problem. The reset waited as well for the reset of the external PHY USB3310. So I had to disable the RESET pin before USB init is done:

#define USB_RESET_On   HAL_GPIO_WritePin(USB_RESET_GPIO_Port, USB_RESET_Pin, GPIO_PIN_RESET)
#define USB_RESET_Off  HAL_GPIO_WritePin(USB_RESET_GPIO_Port, USB_RESET_Pin, GPIO_PIN_SET)

void MX_USB_DEVICE_Init(void)
{
  /* USER CODE BEGIN USB_DEVICE_Init_PreTreatment */
	  USB_RESET_Off;

The second problem was that the USB_REFCLK was missing. When i created the project by CubeMX the "Maximum output speed" is "Low" bit in my case I have 24Mhz so I set it to "Very High".