FreeRTOS Software Timer

valeriv wrote on Monday, June 05, 2017:

I use CORTEX M4 - with FreeRtos Kernel, in IAR workspace.
I would like to know if I miss timer ticks if my timer callback takes 30 miliseconds.

uint32_t SystemCoreClock = 168000000;
#define configCPU_CLOCK_HZ ( SystemCoreClock )
#define configTICK_RATE_HZ ( ( TickType_t ) 1000 )

So, system tick is 1ms.
How many ticks I will miss (if any) in my case ? And what the longest callback that I can put to timer ?

Thanks a lot


richard_damon wrote on Monday, June 05, 2017:

You have something fundamentally wrong if you want to spend 30ms in a callback that gets called every ms, if that is your question.

First, to be clear, you are talking about a FreeRTOS timer, created with created witth xTimerCreate (called from the Timer/Service Task) and not a ‘TickHook’ (vApplicationTickHook) (called from the Timer Tick interrupt itself)).

Timer Callbacks should be fairly quick, because all Timer Callbacks are executed in a single task, and time spent in one callback will delay any other timer that becomes ready during it execution., but it won’t mess up the basic tick functionality of the system. Often the TImer/Service task is placed at the top software priority so the timer callbacks happen as soon as possible, which means that if your callback takes 30ms of actual CPU usage, and is scheduled every 1ms, you will starve the rest of the system for CPU execution time. If you don’t mean for it to be run every tick, but say once a second, then this might work, BUT, during the 30ms it is running, no other timer callback will get called, but they will be delayed until that callback finishes.

The genearl rule I use is that timer callback should be quick and not (normally) block for things, so that one timer can’t significantly influence another, and any periodic action that might actually take some time, or needs to block for something (like I/O) should get a specific task to run in.

valeriv wrote on Monday, June 05, 2017:

Thanks a lot for your answer.

I understand that timer callback should be fairly quick.

Now I understand that "it won’t mess up the basic tick functionality of the system."
And it means that freertos software timer continue working correctly. At least this is no problem.

Now I can explain the really problem.
Something wrong happens to my system, I see in freertos profiler (in Tracealyzer) that my timer routine that in practice takes 200 micro, sometimes runs 30 miliseconds. I have only 3 timer callbacks and every runs in most of the cases maximum 200 micro. But sometimes the frame takes 30 mili and more, that happens before, after or in the middle of my routine. Also, always in the beginning of this frame I receive message from que, that seems me right.

Timer task in the highest priority and nobody can break it, so I have no idea what can be the problem.

Please help me to understand what really happens here.

Thanks in advance


rtel wrote on Monday, June 05, 2017:

Without seeing the code I would take a first guess as:

a) A bug in your code?
b) A bug in an interrupt service routine that is hogging CPU time and
just preventing the timer task from running?

valeriv wrote on Tuesday, June 06, 2017:

It happens also in the empty timer routines, so I think that it is bug in ISR.

Many thanks to you