FreeRTOS v 7.3.7 Timers Problem

gstenos wrote on Tuesday, May 24, 2016:

I was having an issue where one of my timers was never hitting its TimerCallBack function. I made that task the highest priority that the timer was tied to, still nothing would work. Even though it had the highest priority, it would not execute. I changed all timer values to make sure none would ever be released at the same time, the timer would still never hit its TimerCallBack function.

I verified with xTimerIsTimerActive that the timer was never active, it was being created exactly the same as all the other timers save its name and interval, I would check it with configAssert just like all the other timers, no errors or anything that seemed out of place.

timer_a = xTimerCreate((const signed char * const) “TIMER_A”,100/portTICK_RATE_MS,pdTRUE,NULL,TA_TimerCallback);


The main difference is that it is the last timer to be started. Out of curiosity and to make sure I covered all angles, I put it as the first timer to be started, and as luck would have it, it was working all of a sudden. However, now the other timer that is started last does not work, does not matter which timer it is, the last timer is never started.

xTimerStart(timer_a, 0);
xTimerStart(timer_b, 0);
xTimerStart(timer_c, 0);
xTimerStart(timer_d, 0);
xTimerStart(timer_e, 0);
xTimerStart(timer_f, 0); <----Will never be active once the scheduler starts


I have 6 timers in total in this project, all 6 have their own TimerCallBack functions.I’ve also had all timers use the same TimerCallBack function.

I know I do not have too many timers or else I would receive an error message regarding memory issues. This is the first time I’ve had more than 5 timers running, the error has not appeared before. Is there by chance a crucial step I am missing that would make the last timer not activate properly?

richard_damon wrote on Wednesday, May 25, 2016:

The timer functionality uses a queue to send the information to the timer task. You are likely filling that queue, and since this is before the scheduler is running, the task can’t take the data from the queue. (Note, you are not checking the return status from the xTimerStart calls). The Create worked, but the Start didn’t.

I think there may be a parameter you can add/adjust if FreeRTOSConfig.h, or you can move the xTimerStart calls to the beginning of some task that starts with the system.

rtel wrote on Wednesday, May 25, 2016:

A couple of links in support of Richard D’s post:

gstenos wrote on Wednesday, May 25, 2016:

Thank you Richard for your advice and to the support team for the links. Not sure how I missed this parameter when I was setting everything up initially. Everything is up and running now as intended.