OSAL FreeRTOS queue usage lead to wrong behavior of tasks

[jbruneaux31]

Operating System

Others

Board

Custom ARM CM33 board

Firmware

TinyUSB configured for one CDC and one USB Audio link

What happened ?

Lets describe a simple setup with 2 FreeRTOS tasks (Task1= TinyUSB, Task 2 = other process), with FreeRTOS scheduler not using time slicing (i.e same priorities tasks will run only when the other task will either suspend or yield):

• Task2 is running
• USB interrupt happens for audio EPOUT, which enqueue data using osal_queue_send function.
• Task2 should continue to run until it voluntarily yield or it suspends

We observe that this scenario is not always true. Most of the time, after the interrupt happens, we see a context switch and Task1 runs, which is not what is expected.

Investigation has shown that in functions osal_queue_send & osal_semaphore_post, the xHigherPriorityTaskWoken variable in not initialised (use the stack, so unpredictable content). This variable is passed to some FreeRTOS functions which will only set this variable to pdTRUE if task switch is required, but will not touch the variable otherwise.

The fix is to set xHigherPriorityTaskWoken to pdFALSE in those two functions.

How to reproduce ?

See description above. The best way to observe the problem is to do have an activable endless loop in Task2 so that after USB initialisation, the problem can be observed

Debug Log as txt file

No response

Screenshots

No response

I have checked existing issues, dicussion and documentation

• I confirm I have checked existing issues, dicussion and documentation.

[hathach]

it looks like a bug, since you are at it and have your setup testing it. Would you mind making an PR to fix this bug ?

[jbruneaux31]

Well, sorry I'm pretty new to this and will try to find how to make this PR. Will probably be able to do that in the next week.

[hathach]

Well, sorry I'm pretty new to this and will try to find how to make this PR. Will probably be able to do that in the next week.

That is OK, if you are not familiar with PR, would you mind giving the exact permanent link to 2 lines of code that you think we should change here, and maybe post the suggested code change here as well.

[jbruneaux31]

Hi,

I tried to make a pull-request. Let me know if this worked.

Regards,

[hathach]

Fixed by #1803