I’m new to FreeRTOS, I got a timer stack overflow caught by vApplicationStackOverflowHook when xTimerChangePeriod called, what could be the reason
I create a stopwatch timer as follows:
stopwatchTimeExpired= pdFALSE;
xTimerChangePeriod(stopwatchTimer,delay*1000/portTICK_RATE_MS,0);
xTimerStart(stopwatchTimer,0);
while(stopwatchTimeExpired == pdFALSE)
{
//do some stuff till time expired (flag set true in timer callback)
}
The ATMega32 does not have much SRAM, but if a task that is calling xTimerChangePeriod() is experiencing a stack overflow you will most likely have to increase the stack allocated to that task when the task is created.
You can also try reducing the stack used by the task by reducing the size of any arrays allocated on the stack, or by moving variables from the stack to instead by static or global (if your application allows).
Dear Richard,
the overflow is not caused by the task, but by the timer service; when monitoring the task name in vApplicationStackOverflowHook it was ‘Tmr Scv’. I checked the remaining byte left for that task by using
leftMem=uxTaskGetStackHighWaterMark(NULL);
and it was 91 byte (out of 200)
in fact the application run fine despite that overflow,
It is possible that on AVR devices the timer stack size needs to be greater than the configMINIMAL_STACK_SIZE setting. configMINIMAL_STACK_SIZE is set for the idle task, which (unless an idle task hook function is defined) does nothing more than call some very small functions.
Yes, we’re right, increasing the timer stack size from 100 to 120 solved the problem.
I think I may consider counting ticks instead (and taking care of 0xFFFF~0 rollover)….
Yes, you’re right, increasing the timer stack size from 100 to 120 solved the problem. I think I may consider counting ticks instead (and taking care of 0xFFFF~0 rollover)…. Thank you A lot…