# A single FreeRTOS task does not start - debugging suggestions? **URL:** \ **Category:** Kernel\ **Created:** [May 25, 2022, 9:40am UTC](https://forums.freertos.org/t/a-single-freertos-task-does-not-start-debugging-suggestions/15146 "2022-05-25T09:40:15Z")\ **Posts on this page:** 1\ **Showing post:** 8
**Author:** ![sdbbs](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/sdbbs/32/2535_2.png) [@sdbbs](https://forums.freertos.org/u/sdbbs)\ **Post date:** [May 26, 2022, 7:13pm UTC](https://forums.freertos.org/t/a-single-freertos-task-does-not-start-debugging-suggestions/15146/8 "2022-05-26T19:13:04Z")
Many thanks for the replies, all - much appreciated! > [@richard-damon](#): > > FreeRTOS doesn’t analyze your tasks to change its behavior. It uses the basic rule that when it is time to run the schedule, it Chooses the highest priority ready task, and in the case of ties, the first one on the list of that priority which will be the one waiting the longest. > > Yield doesn’t make a task “unready”, just runs the scheduler, so it will NEVER switch to a lower priority task, as it is still ready. Thanks for these remarks, good to have this clarified. I guess one part of my confusion is when “highest priority” gets mentioned, then I always think “but hey, I’ve got a low priority task here, how comes it runs?!” - then I have to remember that a condition is possible where all the higher-priority tasks are actually blocking on something, and the only “highest priority” task which is ready is the low priority task (or the idle one). > [@richard-damon](#): > > Generally ALL Task must “block” on something and make themselves “unready” (be it for a time or a queue or semaphore). From my limited reading so far, I also managed to build more-less the same mental model for tasks, however I was not sure how correct it is - thanks for confirming this. > [@richard-damon](#): > > The ONLY exception should be tasks at priority 0 (Idle), which can run continuously, and if you have time slicing, (or they occasionally yield) will switch among themselves to use up remaing time. I will keep this in mind as well. > [@aggarg](#): > > This indicates that the actual problem is elsewhere. It is hard to make a guess without looking at the code - can you remove all your proprietary code and provide a minimal project which just uses FreeRTOS constructs and demonstrates the problem? I tried to - and it turns out, I cannot get really get it to run, even with what I thought was the original problem (`my_printer_task`) removed. Ok, so here is the code: > Basically, what I’m trying to show is: - There is a LED task, which simply blinks the LED, all day long … but it also starts the ISR - There is some ISR running, generating data - here simulated with a timer - This ISR writes to queue\_01, and thereby wakes `working_01_task`, which stores the data from the ISR in different buffers, then depending on some condition, wants to wake either `working_02_task` to handle one of the buffers, or `working_03_task` to handle the other. This signalling I tried to do via task notifications - To give them some busywork, here `working_02_task`and `working_03_task` merely should write out string reports based on their respective buffer when triggered - When done, as a final step, I wanted these tasks to signal a final task, `my_printer_task` - here by writing a “task id” number to another queue, `queue_02` - which would then `printf()` the corresponding string report (depending on which task id was read from the queue). This part is, however, undefined away in the posted code. The code has some debug pin instrumentation, and here is a capture: ![logic_test_freertos](https://d2v6vdsk2p900z.cloudfront.net/original/2X/c/c88fdd765677b4fb78a355866fdc35a52990c876.png) So if one looks from top: - led\_task starts first, and indeed manages to start timer\_alarm\_isr - timer alarm\_isr does indeed manage to (seemingly) trigger the worker\_01\_task - however, worker\_02\_task starts pulsing randomly _waaaaaaay_ before led\_task ever started! - Something also managed to trigger worker\_03\_task (but I’ve taken several of these captures, and it does not always happen) However, it is clear, that after a couple of runs of the timer isr, the whole program crashes. This happens: - Regardless if a `printf` is fully undef’d (there are more pulsings and everything happens more quickly, but we still run into a crash) - Regardless if I use indexed task notification or unindexed/not indexed Somehow, it looks to me that task notification fails, since worker\_02\_task simply goes wild, as if it does not block waiting on anything - whereas worker\_03\_task might react, but usually the crash is not soon after. (Strange because I have more/less same setup in my proprietary code do, which does a lot more with printfs all over the place, and it _works_?!) Would anyone have any comments on these results? --- _[View the full topic](https://forums.freertos.org/t/a-single-freertos-task-does-not-start-debugging-suggestions/15146)._