stack overflow when IDLE task is created

Kernel
1

aviasaf wrote on Tuesday, May 12, 2009:

Hello all,

I am working on the IAR workbench, with AT91sam7s256 processor.

I have ported the freertos to this processor based on the relevant docs.

I have a problem with the freertos IDLE task.

When the IDLE task is created by the freertos vTaskStartSchedulervTaskStartScheduler function, its stack and TCB is being allocated, the problem is that it’s run over other tasks that created before by the user.

Then I get "stack overflow" (using freertos hook) on tasks that really not doing anything.

Does any one have a clue what can be the problem?

thanks

2

aturowski wrote on Tuesday, May 12, 2009:

First I would check if there is enough space in your heap memory, which is used for allocation for stacks for all tasks.

I suspect also that one of your task stack size might be set too small and it overruns idle task stack.

Regards,
Adam

3

aviasaf wrote on Tuesday, May 12, 2009:

hi

I saw that when the the IDLE stack is created its overrun others tasks.

I get overflow because the TCB of other tasks is overrun (by the IDLE task) and therefore the overflow-check function of freertos recognize it as stack overflow.

i don’t think that the problem is because of small stack of other tasks.  

4

aturowski wrote on Tuesday, May 12, 2009:

Idle task is created the same way as the other tasks are. First the memory for TCB and task stack is allocated on heap. Maybe there is a problem if allocate function returns wrong pointer. Please have a check if prvAllocateTCBAndStack function call in xTaskCreate works fine.

What heap implementation are you using?

5

aviasaf wrote on Tuesday, May 12, 2009:

hi

i am using heap_2 implementation, I think the allocation works fine, I have set breakpoint if the allocation has failed (memory limitation)

I have got only 2 more tasks which allocation less then 0.5K ram.

how can I check if the address return from the allocation function is valid (alignment problems???)

thanks

6

aviasaf wrote on Tuesday, May 12, 2009:

sorry, i am using heap_3

7

aturowski wrote on Tuesday, May 12, 2009:

xTaskCreate calls prvAllocateTCBAndStack function and this returns the pointer to allocated memory. Suggest set the breakpoint there and check if pointers returned during TCB/stack allocation have values as expected.

P.S. A basic point. Almost all FreeRTOS features (queue/mutexes/semaphores etc.) use heap to allocate needed memory. I assume that you have commented out all of them and still there is an issue. If you haven’t I suggest to have a look in pvPortMalloc function which will be used for all this allocation - please check if pointer returned doesn’t show any unexpected behaviour.

8

aturowski wrote on Tuesday, May 12, 2009:

xTaskCreate calls prvAllocateTCBAndStack function and this returns the pointer to allocated memory. Suggest set the breakpoint there and check if pointers returned during TCB/stack allocation have values as expected.

P.S. A basic point. Almost all FreeRTOS features (queue/mutexes/semaphores etc.) use heap to allocate needed memory. I assume that you have commented out all of them and still there is an issue. If you haven’t I suggest to have a look in pvPortMalloc function which will be used for all this allocation - please check if pointer returned doesn’t show any unexpected behaviour.

9

sotd wrote on Tuesday, May 12, 2009:

using heap3 so heap size is set in the linker script. Probably linker script is the cause.