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:
stopwatchTimer = xTimerCreate(flshTmrStr,DUMMY_TIME_PERIOD,pdFALSE,
(void*)STOPWATCH_TIMER_ID, stopwatchCallback);
and in the task function:
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)
}
in FreeRTOSConfig.h file:
#define configUSE_TIMERS 1
#define configTIMER_TASK_PRIORITY 3
#define configTIMER_QUEUE_LENGTH 10
#define configTIMER_TASK_STACK_DEPTH configMINIMAL_STACK_SIZE
I'm using ATMEGA32 in WinAVR GCC compiler, thanks for your help...
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).
Regards.
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.
Regards.
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)....
Thank you A lot...
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...