Strange Task Scheduling Behavior

Hello all,

I’ve been working on a project and I’ve been running into some issues with the task scheduling. At the moment, there are two tasks with task the priority of 2 (I will call them Task A and Task B) and one task with the priority of 1 (I will call this Task C). Task C begins in the suspended state and is then brought in and out of the ready state depending on software events (I realize this may not be the best way to do this, I plan on switch to event group to handle this but for now I want to keep it as is). Task A and Task C work perfectly, sharing time slices between them but when I added Task B it is never given a time slice. I removed Task A and C and Task B works fine, so it isn’t an issue with the set up. I also went into the FreeRTOSConfig.h file to make sure configUSE_TIME_SLICING was set to 1 and for some reason my version of that header file does not have that as an option. I added #define configUSE_TIME_SLICING 1 to the config file and I am still having the same issue. Task A and B are both running in a continuous loop and Task C is not so I believe the issue has to do with the passing task control during delays when the Task that is running hasn’t fully completed what is has to do. If this isn’t clear please let me know and I can provide any extra information needed.


TaskA = priority 2
TaskB = priority 2
TaskC = priority 1

TaskA has a higher priority than TaskB, so I would expect TaskA to run continuously unless it makes a blocking API call that puts it into the Blocked state.

TaskA and TaskB have the same priority - so if you use time slicing they should run for one time slice each in turn unless either put themselves into the Blocked state. TaskC should not run at any time unless both TaskA and TaskB are in the Blocked state.

This defaults to 1 if it’s left undefined.

This isn’t clear. Are you saying TaskA and TaskB run in a continuous loop without blocking - if so I would never expect TaskC to run at all. Or are you saying TaskA and TaskB are implemented within an infinite loop, but TaskC is allowed to execute off the end of its implementing function? If so, I would just expect it to crash.

Thank you for the reply.

Task A and Task C share time slices due to Task A containing several vTaskDelay calls, sorry if I wasn’t clear there.

This is what I’m expecting, but for some reason Task B is never given a time slice. Do you have any Idea why this may be the case?

Make sure you have enough memory so Task B was actually created, and the create function didn’t just fail for lack of memory.

Thanks for the reply, I think I actually had the opposite problem. I oversized the stack for each of the tasks and ran out of memory. Thanks for the help

That is exactly the problem I was describing. Each task took too much memory so you failed to create the third task.

This is one reason defining the debug hooks can help. If you don’t expect to be dealing with the allocations failing, defining the malloc fail hook can alert you that it happened.

Also, do not forget to check the return value of EVERY system call. The failure return of xTaskCreate for task C would have given you a clue instantly.