Task gets blocked by calling higher-priority timer function

Kernel
1

I’m having an issue with timers and priorities.

I have a task that is responsible for flashing an LED according to a preset scheme: the task creates a one-shot timer, which in turn invokes a call-back function. This call-back function calls xTimerChangePeriod() on the timer with different timeouts, and so gets called back again at varying intervals. This part seems to work fine, and other tasks are running as intended, too. I’m using cooperative scheduling.

However, when I call xTimerChangePeriod() from the task the very first time, the function call never returns–that is, the task stays blocked regardless of the timeout I specify in xTimerChangePeriod(). (The timer nonetheless gets started, and the call-back does exactly what it’s supposed to do.)

It turned out that I had set the configTIMER_TASK_PRIORITY above that of the task that calls xTimerChangePeriod(). Lowering the timer priority allows the task to become unblocked after the function call, and so the system works as intended.

But … I wouldn’t expect the task to become permanently blocked by calling xTimerChangePeriod() simply because the task has a lower priority. What am I missing?

2

I agree the behaviour you see seems anomalous - can you post the smallest amount of code that exhibits this behaviour so we can try it. Also, which port are you using and which version of FreeRTOS?

3

Thanks for your reassurance that it doesn’t seem right. I was basically asking if this was an intended feature before venturing on to narrow down the behavior to a few lines of code.

I’m using the most recent version of FreeRTOS as of this writing: 10.4.1. The port GCC/ATmega (on an ATmega1284). It’s a third-party port but I don’t expect my issue to be caused by a buggy port.

My code has grown somewhat large by now so my best bet at the moment is that the task somehow gets blocked while xTimerChangePeriod() is called, not because it is called. Like a queue getting filled because of a mishandled interrupt. It feels like a case where interrupts should be suspected.