Tasks lock up checking a flag

Kernel
1

I have FreeRTOS 10.0 running on a SAME70 at 300mhz. 4 tasks built, all running.
Task 1 is console task, services console input
Task 2 is system task, takes care of houskeeping.
Task 3 dedicated to a state machine watching SPI port
Task 4 service another serial port, idle at moment.

Using premption, tick rate 1ms priorities 1-3 assigned…

all things run by themselves, but following sequence lock up scheduler.

  1. user enters command, sets a flag

  2. system task picks up flag, runs function to pump data out SPI port and wait for a return, this is done in the SPI task.
    SPI port is completely interrupt driven, fast ,no rtos calls in it…I’m sure this works.

  3. System task function called, spins in while loop waiting for a Complete flag to be set.

system hangs here forever, all other task never run, clocks are fine and running…Flag cannot be changed if task are not running…

So question is what am i missing here? why will this not work…
I have tried adding taskYield() in while loop, did not help things…

any enlightenment appreciated!
thanks
Ken

2

If the task spin-waiting for a flag (?) has the highest prio and the spin loop doesn’t a reasonable vTaskDelay to give up the CPU for a while, it starves all other, lower prio tasks. Do you know which part of the sequence doesn’t complete ?
Besides that it’s far better to use FreeRTOS signaling functions like task notifications or queues instead of bare (volatile ?) flags.

3

Thanks for reply!
I tried to make this simple and add complexity as i go. Not my first RTOS projects, but first at such a high cpu speed.
i stated with a simple flag that gets set in in interrupt routine, ISRs are working since tick never stops.
I added a taskYield() in the loop and this did not do anything, much to my surprise.
I juggled around the priorites a little and it started to work as is…Hmmmmm. there is more than sufficient wait time between tasks, fastest one runs every 5ms. So still not sure what is actually controlling the flow here.
Ken

4

taskYIELD() gives control only to tasks of equal priority or higher. If preemption is enabled, then a higher priority task cannot be yielded to (it would already be running). If no other task can run, then control is returned directly back to the caller.

Use vTaskDelay( ticks ) to block the current task and allow lower priority tasks to run for the given number of ticks.
Alternatively, use a FreeRTOS Queue, StreamBuffer, or EventGroup to block the task indefinitely until signaled. These objects can be signaled from inside an interrupt with FromISR functions.

5

Thanks for that advice, that explains what I’m seeing. I do use vTaskDelay in every task since none of them need to run at speed. I think part of the issue is a high speed spi interface, 590khz which generates tight interrupts for a short period affecting the timing. Might try moving this to DMA to see if issue goes away. The other ISRs seem to be fine, but none of these run this fast.
Ken