New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
initialisation setting for USB_OTG_HS as a disable HOST fails to return from init when using FW_H7 v1.11.2. (not so with v1.11.1 #286
Comments
On closer inspection it appears that the STM32CubeMX has not set the __USB_OTG_HS_CLK_ENABLE() in this setup. This maybe the real reason it timesout. |
Further Investigation has found STM32CubeMX has not created the HAL_HCD_mspInit() or HAL_HCD_mspDeInit(). When manually coding these it has fixed the problem. So this should be passed to the STM32CubeMX team to fix as I have noticed there are many posts from people all having related problems to the Timeout issue here |
Hi @AnthonyGBES, Thank you for all these helpful details. However, I generated a project using the same configuration as you described and noticed no issue. Both Would you mind double-checking please? Otherwise, please let me know in case I missed somehting. Below the configuration I used:
With regards, |
Do you also have generate separate .c/.h files set? When this is the case the MX_XXX_Init() and HAL_XXX_MspInit() functions are usually created in these seperate .c/.h files not the stm32h7xx_hal_msp.c. In this USB setup case it creates usb_otg_hs.c which has the MX_USB_OTG_HS_HCD_Init() but not the HAL_XXX_MspInit()/HAL_HCD_MspDeInit() functions. All the other modules seem correct and have both sets of functions UART, QSPI, ,LTDC etc. Here's the sum total of my stm32h7xx_hal_msp.c file and below that the /* USER CODE BEGIN Header */ /* USER CODE BEGIN Header /
/ /* Includes ------------------------------------------------------------------*/ /* USER CODE BEGIN Includes */ /* USER CODE END Includes */ /* Private typedef -----------------------------------------------------------/ /* USER CODE END TD */ /* Private define ------------------------------------------------------------/ /* USER CODE END Define */ /* Private macro -------------------------------------------------------------/ /* USER CODE END Macro */ /* Private variables ---------------------------------------------------------/ /* USER CODE END PV */ /* Private function prototypes -----------------------------------------------/ /* USER CODE END PFP */ /* External functions --------------------------------------------------------/ /* USER CODE END ExternalFunctions */ /* USER CODE BEGIN 0 */ /* USER CODE END 0 /
/* USER CODE END MspInit 0 */ __HAL_RCC_SYSCFG_CLK_ENABLE(); HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_3); /* System interrupt init*/ /** Enable the VREF clock /** Disable the Internal Voltage Reference buffer /** Configure the internal voltage reference buffer high impedance mode /* USER CODE BEGIN MspInit 1 */ /* USER CODE END MspInit 1 */ /* USER CODE BEGIN 1 */ /* USER CODE END 1 */ This is the generated usb_otg_hs.c i have
/ /* USER CODE BEGIN 0 */ /* USER CODE END 0 */ HCD_HandleTypeDef hhcd_USB_OTG_HS; /* USB_OTG_HS init function */ void MX_USB_OTG_HS_HCD_Init(void) /* USER CODE BEGIN USB_OTG_HS_Init 0 */ /* USER CODE END USB_OTG_HS_Init 0 */ /* USER CODE BEGIN USB_OTG_HS_Init 1 */ /* USER CODE END USB_OTG_HS_Init 1 / /* USER CODE END USB_OTG_HS_Init 2 */ } |
Hi @AnthonyGBES, I regenerated my project after having ticket the option It could be that you have ticked some other option at some moment, which causes this unwanted behavior. May I suggest that you restart creating a new IOC file from scratch with the tool's default options? Please keep me informed. With regards, |
Hi @AnthonyGBES, I hope my previous comment is useful and you can easily overcome the issue you are facing. As suggested, it could be that you have ticked some other option at some moment, which causes this unwanted behavior. Please allow me to close this thread. Thank you for your comprehension. With regards, |
It’s a lot of work to redo a 240 pin chip every time ST32CubeMX get confused!!!
It’s not just the pins that need setting up again but the whole 3 months project work. As all the user code sections will need redoing.
I think this is something you should really be investigating further and trying to fix.
What use is a code generator if you have to keep rebuilding it every time it gets confused.
I’m guessing all your setting up is the USB and not a more complicated project.
Try setting it to a different set up of usb E.g. a host msc from the same project you’ve set up as host disabled working project and see if it changes the files. And then try host disabling back again.
Perhaps it getting it right then first time but not if you change a project host use.
…Sent from my iPhone
On 2 May 2024, at 10:25, Ali LABBENE ***@***.***> wrote:
Hi @AnthonyGBES<https://github.com/AnthonyGBES>,
I hope my previous comment is useful and you can easily overcome the issue you are facing. As suggested, it could be that you have ticked some other option at some moment, which causes this unwanted behavior.
Please allow me to close this thread. Thank you for your comprehension.
With regards,
—
Reply to this email directly, view it on GitHub<#286 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BFHYNEBRWZVYBHRLT5YURGLZAIA6ZAVCNFSM6AAAAABFXXS4KCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJQGAYDAMJTGU>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Hi @AnthonyGBES, Really sorry to read that. Best of luck to update your project. Just one question about this sentence you wrote:
Could you be more precise please? I guess your user code is correctly placed between the different With regards, |
Caution
The Issues are strictly limited for the reporting of problem encountered with the software provided in this project.
For any other problem related to the STM32 product, the performance, the hardware characteristics and boards, the tools the environment in general, please post a topic in the ST Community/STM32 MCUs forum
Describe the set-up
Describe the bug
Setting up the USB_OTG_HS as host only and as internal Full speed PHY, and setting up the middleware USB_HOST to disabled. The Main() code never returns from MX_USB_OTG_HS_HCD_Init();
This was not the case with FW_H7 1.11.1
How To Reproduce
USB Clock set to 48Mhz via PLL1
enabling the pins for USB_OTG_HS and Set the USB_OTG_HS as host only and as internal Full speed PHY, but leave disabled in the middlewares Test with v1.11.1 and it will continue after function call to MX_USB_OTG_HS_HCD_Init(); (the reason for doing this is we have a HOST port connection there but it is not currently used)
Repeat same setup for v1.11.2 and it won't return from the MX_USB_OTG_HS_HCD_Init(); function.
Additional context
I beleive the problem is it returns HAL_TIMEOUT from the call USB_CoreReset(); in both varients. but the call to USB_CoreInit(USB_OTG_GlobalTypeDef *USBx, USB_OTG_CfgTypeDef cfg) then void the return in HAL_HCD_init() in v1.11.1 and thus it carrys on regardless.
in v1.11.2 it checks the return value and then returns HAL_ERROR and gets caught by the Error_Handler(); within the MX_USB_OTG_HS_HCD_Init();
I suspect the real reason is why the USB_coreReset() is timing out???
Screenshots
If applicable, add screenshots to help explain your problem.
The text was updated successfully, but these errors were encountered: