STM32F405 USB_OTG_HS Programming (Possible Clock Issue)
- January 26, 2018
- 9 replies
- 3019 views
I am developing a application using the STM32F405RGTx (LPQFP64). To isolate my issue I am running a bare bones setup. The project is generated using STM32CubeMX with the following selected: RCC (HSE Crystal), SYS(TIM1, JTAG 5 Pin), USB_OTG_HS (Internal Device_Only). Also pins PC6 & PC7 are used to debug the program to see if it works and set as GPIO_Output to LEDs.
If I make a project just using the LEDs and nothing else I can write in the main.c pregenerated while loop to toggle the LEDs with HAL_GPIO_TogglePin(). However, when I make a project with the USB_OTG_HS selected in CubeMX and generate the code then add ONLY the HAL toggle functions to see if it will work, I can no longer turn on the LEDs. I am running CubeMX version 4. Am I missing a step or is there an issue with the pre-generated code? Please let me know if you need any more information, I can send code snippets and images. Thanks for your time.
I was thinking this might be a clock configuration issue.
Stepping through the debugger I get stuck in an infinite loop in the SystemClock_Config() in the main function. Then the function HAL_RCC_OscConfig(&RCC_OSCInitStruct) is run then gets stuck in the statement:
if((RCC_OscInitStruct->HSEState) != RCC_HSE_OFF) { /* Get Start Tick*/ tickstart = HAL_GetTick();
/* Wait till HSE is ready */
while(__HAL_RCC_GET_FLAG(RCC_FLAG_HSERDY) == RESET)
{ if((HAL_GetTick() - tickstart ) > HSE_TIMEOUT_VALUE)
{ return HAL_TIMEOUT;
}
}
}It seems as if the HSE never 'gets ready'. Any suggestions? Would increasing the Timeout help or is it an issue with how the crystal is wired on the board?
After more debugging in the filestm32f4xx_hal_rcc.cthis function__HAL_RCC_GET_FLAG(RCC_FLAG_HSERDY)which is defined as:
#define __HAL_RCC_GET_FLAG(__FLAG__) (((((((__FLAG__) >> 5U) == 1U)? RCC->CR :((((__FLAG__) >> 5U) == 2U) ? RCC->BDCR :((((__FLAG__) >> 5U) == 3U)? RCC->CSR :RCC->CIR))) & (1U << ((__FLAG__) & RCC_FLAG_MASK)))!= 0U)? 1U : 0U)
Never evaluates as true, it is always set in the reset state. Again, I am not sure if this is a board or processor issue. Thanks.
#usb_device #stm32f405