Effect of stack size and heap size value in the linker script (Xilinx Zynq SDK)

Hi, I am trying to learn FreeRTOS on Zynq platform. I have created a project by modifiying the example project found in FreeRTOS. My project uses FreeRTOS 9.0.0. I have some difficulties understanding stacks and heap.. I created standalone SDK project and added source files of FreeRTOS with my files. When I click on linkerscript, there are two fields: Stack Size and Heap Size. As far as I understand this stack size isn’t related to the stack size parameter given in xTaskCreate(). When a task is created, its stack is allocated from the heap. But this heap is different from the heap mentioned in linker script. I am using heap_4.c as in example project and as heap region, an array is allocated by FreeRTOS. So, how the sizes given in linker script are used?

Effect of stack size and heap size value in the linker script (Xilinx Zynq SDK)

The stack size in the linker script will be the stack given to the ‘main’ program (what runs pre-scheduler) and will be reused as the interrupt stack when the scheduler starts. The heap size in the linker script will be the amount of heap available via the standard C malloc function (as opposed to the heap that heap4.c provides)

Effect of stack size and heap size value in the linker script (Xilinx Zynq SDK)

So, if my code doesn’t use standard malloc() or call a library function which calls malloc(), I can set heap size to 0, right? And for the stack size, “…which for many RTOS ports is zero as the RTOS will switch to use a dedicated interrupt stack on entry to an interrupt service routine.” (http://www.freertos.org/FAQMem.html#StackSize), the dedicated interrupt stack is part of stack that is specified in the linker script. Thank you.

Effect of stack size and heap size value in the linker script (Xilinx Zynq SDK)

So, if my code doesn’t use standard malloc() or call a library function which calls malloc(), I can set heap size to 0, right?
Make sure that malloc() is not being called indirectly, e.g. by localtime(). You can catch this by defining a malloc() function which calls some undefined function: ~~~ extern void* mallocisbeingcalled( void ); void* malloc (sizet size) { /* Call an undefined function to provoke a linker error. */ return malloc_is_being_called(); } ~~~ Some people define a task-safe version of malloc() / free() that use pvPortMalloc() and vPortFree().
And for the stack size, …, the dedicated interrupt stack is part of stack that is specified in the linker script.
True. When your application starts up, the stack from the linker-script is being used to store local variables and to call functions. Interrupts are disabled until vTaskStartScheduler() is called. At that moment, the interrupts may use the stack space and every task has its own stack.