tasks, interrupts and stack

Kernel
1

hooverphonique wrote on Friday, September 19, 2008:

Hi,

I’m having trouble with an application with (currently) 3 tasks on an ATMega32 and FreeRTOS 5.

one is servicing usart communications and the other 2 are currently only flashing their own individual LED.

when adding all 3 tasks, the application crashes (no tick, causing the wdt to reset)… adding only any 2 of the 3 tasks, all works fine… i’m suspecting stack overflows are the cause of this, but can’t find any pattern in the behaviour…

am i correct in saying that a tasks stack usage is not affected by other tasks, only interrupts? because then if a task works, adding in new tasks (that do not cause interrupts and have sufficient stack) should not affect existing ones…

the strange thing is, it is always the 3rd task (last one added), that does not work, but this task sits highest in memory, so it can’t get its stack overwritten by the other tasks, only itself can overwrite its TCB…

on a side note: the idle task default stack size of 85, where does that come from? is it the stack used by the task itself, so adding interrupts to the system may make this stack too small?

2

rtel wrote on Monday, September 22, 2008:

> am i correct in saying that a tasks stack usage is not affected by other tasks, only interrupts?

Yes.

> because then if a task works, adding in new tasks (that do not cause interrupts and have
> sufficient stack) should not affect existing ones…

Have you checked the return value of the xTaskCreate() function, maybe the task is not getting started at all.  Does vTaskStartScheduler() return?

> on a side note: the idle task default stack size of 85, where does that come from? is it
> the stack used by the task itself, so adding interrupts to the system may make this stack
> too small?

The size is determined as a ‘safe minimum’ for the demo application, which includes at least one interrupt (UART) so this is taken into account.

Take a look at http://www.freertos.org/Stacks-and-stack-overflow-checking.html and http://www.freertos.org/uxTaskGetStackHighWaterMark.html but note on 8bit machines you might get funny results if the return values are >255.

Regards.