2023-10-18 12:11 AM - edited 2023-10-18 12:43 AM
When I try to add USB_OTG_FS (host only) to a project which uses FreeRTOS the code locks up on initialisation of USB_OTG_FS.
When USB OTG FS is added, a call to "MX_USB_OTG_FS_HCD_Init" is added to "main" function. It goes before a call to "osKernelStart()". During initialisation HAL_Delay is called, and the code locks up on that.
The path looks like this: MX_USB_OTG_FS_HCD_Init >> HAL_HCD_Init >> USB_SetCurrentMode >> HAL_Delay(1U)
And that is where it locks up.
If I comment out the call to "MX_USB_OTG_FS_HCD_Init" the rest works fine. If I put "HAL_Delay" in one of FreeRTOS threads, that works as expected (presumably due to OS being fully functional by that point). If I put "HAL_Delay" just before a call to "osKernelStart()" - it locks up.
It seems that HAL_Delay cannot be called before the call to osKernelStart, and the auto-generated code for initialisation of USB is doing exactly that.
Is it a bug or I am missing something? What would you recommend?
Solved! Go to Solution.
2023-10-18 08:05 AM
This is a known issue with FreeRTOS - calling any function that creates a mutex/queue/task/etc. before osKernelStart() will leave interrupts disabled. Move the MX_USB_OTG_FS_HCD_Init() call either before MX_FREERTOS_Init()** or inside the default task.
** Presuming you have no other init functions that create FreeRTOS entities.
2023-10-18 08:05 AM
This is a known issue with FreeRTOS - calling any function that creates a mutex/queue/task/etc. before osKernelStart() will leave interrupts disabled. Move the MX_USB_OTG_FS_HCD_Init() call either before MX_FREERTOS_Init()** or inside the default task.
** Presuming you have no other init functions that create FreeRTOS entities.
2023-10-18 11:53 AM
Thank you, @Bob S. I have moved it to the default task and now it works fine.
2023-10-18 02:01 PM
Glad it helped. Feel free to mark my post as "the answer" :)