A single FreeRTOS task does not start - debugging suggestions?

[sdbbs]

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:

https://gist.github.com/sdbbs/652d4abeda027999be9245db0035c78f/d7b41f932e54fd3c5f51230a3ea243c8388b0f3e

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_taskand 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:

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?