• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 54 subscribers
  • Views 917 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler: Why the task stack needs to be defined as global?

Carmen Chan
Intellectual 325 points

Tool/software: TI C/C++ Compiler

Good morning,

I have a basic question,  I have seen on everywhere that the task stack is declared outside the main function, if it is declared inside I get this error (I was using the empty_min example):

[CORTEX_M4_0] FSR = 0x0000
HFSR = 0x40000000
DFSR = 0x00000001
MMAR = 0xb048564a
BFAR = 0xb048564a
AFSR = 0x00000000
Terminating execution...

I suspect that if it is declared inside, the task stack is out of the scope for the function and therefore, the error. 

I'd like to verify if this is the case.

Thanks in advance,

Carmen

  • 0
    TI__Guru* 96960 points
    Hi Carmen,

    There are two ways to get a stack for a dynamically created task.
    1. Have the Task_create (or Task_construct) call allocate it for you. This is done by leaving the "stack" field in the parameter structure as NULL (which is the default).
    2. Supply a buffer via the "stack" field. In this case, the supplied buffer must be in a persistent location. When main() is running, it is actually using the system stack. Once BIOS_start is called, the system stack is reset and used by Hwi/Swi. Therefore any local variables in main() are essentially gone (it's really still there, by now both the new task and the system stack are using the same memory as a stack..bad...very bad!).

    Todd
  • 0 in reply to ToddMullanix
    Intellectual 325 points

    Hello Todd,

    Thanks for the answer!

    A couple follow up questions:
    1. if I set the stack field as NULL, the task_create allocates the task with the size according to the "size" parameter, right?  Also, why the user would need to supply the buffer via "stack", I want to know what is the advantage to supply a buffer instead of set it to NULL.
    2. What's the difference of dynamically created task vs statically in terms of memory? I assume that "dynamically" does NOT mean that the task is allocated in the heap memory, right?

    Thanks again!

    :)

  • 0 in reply to Carmen Chan
    TI__Guru* 96960 points

    Carmen Chan said:
    1. if I set the stack field as NULL, the task_create allocates the task with the size according to the "size" parameter, right?

    Close..."stackSize". 

    Carmen Chan said:
    2. What's the difference of dynamically created task vs statically in terms of memory? I assume that "dynamically" does NOT mean that the task is allocated in the heap memory, right?

    From a data perspective, its the same. The build will generate a buffer the size that is requested. It does not get allocated from a heap...it just a global variable (with a long ugly name to avoid namespace collisions). You can save some code space since you don't need to call Task_create (or Task_construct). Statically creating also results in a little faster boot time (since you don't have to call Task_create).

    Todd

  • 0 in reply to ToddMullanix
    Intellectual 325 points

    Thanks!!!

    I did a couple tests and did not set any buffer to the stack field only the "stackSize". Then I noticed in ROV that the total free memory at HeapMem is reduced with respect of the test with the buffer defined. It looks like if the stack field is NULL, the stack will be allocated in the Heap Memory, is this right?

    Thanks (I really promise that is my last question).

    Carmen

  • 0 in reply to Carmen Chan
    TI__Guru* 96960 points

    Yes. If you don't supply the stack on a dynamic creation, the stack is allocated from the heap.

    Note: TI-RTOS has lots of advanced configuration options to denote which heap to use for the allocation for the stacks, kernel objects, etc. which are handy in larger devices with both internal and external memory. For example, you might want a stack in fast internal memory instead of having it in slower DDR3 memory. You also might want some heaps in internal, external and shared memory (for multi-core devices). Of course these advanced options are not usually needed for the smaller MCU devices.

    btw...no problem with the questions:)

    Todd