USB HOST Library in RTOS mode

[GMeur]

Hi,

When I'm using the USB HOST Library in RTOS mode, the thread blocks in the enumeration phase and never leaves it. Is it a known issue? I must mention that it works perfectly when I'm using it in standalone mode. I haven't been able to debug it myself.

Also, if I call the USBH_Process() function inside a thread that I create myself, everything works fine.

Thanks in advance.

[Olivier GALLIEN]

Hi @GMeur​ 

Could you please specify which hardware platform you are using ?

Thanks

Olivier

[GMeur]

Hello, I'm using the STM32F769I-Discovery board

[MAlek]

Hi Guillaume,

take a look at the stack size you defined in the vTaskCreate ! Perhaps the default stack size is not sufficient for all variables created inside the scope and it is in the task created manually by you are defining it bigger .

Marcelo Aleks

[GMeur]

It could be a problem when I'm doing it 'manually', but not when I want to do it through the use of the library. To make my point a bit clearer: normally, the USB library is configured in 'RTOS mode' by setting USBH_USE_OS to 1 and the call to USBH_Process() is done in a wrapper function named static void USBH_Process_OS(void const *argument). So there should be no need to call it after in the user code as it's already done in the library. However, the function gets stuck in the enumeration phase after a few iterations, seemingly because it never receives a message on (USBH_HandleTypeDef *)argument)->os_event.

However, if I set USBH_USE_OS to 0 and call USBH_Process() by myself in my own thread, everything works withouth a hitch.

[MKDas]

It worked for me following your steps. Many many thanks.

[Luiz Pereira]

​Hi Guillaume

Several months ago I faced a similar issue with a STM32F767 (alientk) and freeRTOS. After several hours looking / debugging the code, I solved the problem ensuring that the thread owning the USBH task have the highest priority in the RTOS; after successful enumeration, the priority can be lowered (or alternatively controlled by events, assuring that others threads can run). Perhaps is not your problem but I don't know exactly wat you are trying to do.

Luiz

[Piranha]

It is important to understand that changing thread priorities principally can't fix bugs. It can only change how much those happen and what are the consequences. The only way to guarantee correct operation is using proper thread synchronization.

[MRey.1]

Hi, GMeur. I know it's an old thread but I have a similar issue. The USB blocks in enumeration with FreeRTOS, but works perfectly without it. How did you manage to solve it?

[Luiz Pereira]

Hi

My previous workaround (manipulating thread priorities) was obviously a transitory solution (on that time I really needed to test the system). After, I spent a lot of time trying to find the problem. And apparently, I found it by luck: in a different board, I didn't activate in FreeRTOS the tickless mode (configUSE_TICKLESS_IDLE = 0) and USB Host works perfectly... Going back to my original board I tested such possibility and everything works without any need to manipulate threads priorities... In a simple debug work, I found that by any reason (I didn't explore that) when the FreeRTOS enter in vPortSuppressTicksAndSleep, a next USB Host interrupt is not able to wake-up the system... My workaround (working now) was introduce a global variable (e.g. usbHostOn) that will be assigned to 1 if some device / peripheral is connect to USB Host port (and 0 if disconnect) and inside the callback function PreSleepProcessing (created by FreeRTOS when configUSE_TICKLESS_IDLE = 1), assign to the passed variable ulExpectedIdleTime, the value 0 if usbHostOn = 1. This avoid the FreeRTOS to enter in sleeping mode until the USB Host port is disconnected (and usbHostOn becomes zero). Unfortunately this implies that the FreeRTOS sleeping mode cannot be executed while the USB Host Port is active. Honestly I didn't have time to explore this issue in deep but I will do that when have available time...

Regards

Luiz

[Nredd.1]

I have faced a similar issue with an STM32F401 and freeRTOS.I am changing the USBH_PROCESS_PRIO level as "osPriorityHigh" and USBH_PROCESS_STACK_SIZEs to 1024, then it's working fine