StackDepth for xTaskCreate, why so big values?

Posts: 10
Joined: Mon Dec 19, 2016 10:18 am

StackDepth for xTaskCreate, why so big values?

Postby Espagnole » Sat Jan 07, 2017 5:16 pm

xTaskCreate has 3rd argument const uint16_t usStackDepth. It is the number of words to allocate for use as the task's stack.
configMINIMAL_STACK_SIZE is 1024, and it is lots of memory.
Nevertheless it is minimum: it isn't enough to start a task and allocate anything inside.
Why? What this memory is used for?

User avatar
Posts: 132
Joined: Fri Nov 13, 2015 4:27 pm

Re: StackDepth for xTaskCreate, why so big values?

Postby martinayotte » Sun Jan 08, 2017 3:02 pm

The name is self-explained. It is for the stack. Size 1024 seems to be big for a LED blinking task, but not for some other kind of tasks.

User avatar
Posts: 1683
Joined: Mon Nov 16, 2015 4:43 pm
Location: Texas, USA

Re: StackDepth for xTaskCreate, why so big values?

Postby kolban » Sun Jan 08, 2017 10:23 pm

There appears to be a FreeRTOS FAQ entry on sizing the stack which can be found here:

It seems to describe a number of characteristics which go into sizing the stack. It also suggests a function to get the high water mark of stack depth actually used during some runs. While that should not be used as the gauge for "all runs", it does seem to provide an indication that could be used to gain some insight into how much stack might actually be used in common cases.
Free book on ESP32 available here:

Posts: 1897
Joined: Sun May 08, 2016 4:11 am

Re: StackDepth for xTaskCreate, why so big values?

Postby ESP_Angus » Mon Jan 09, 2017 12:18 am

In a slight variation from the standard FreeRTOS convention, StackType_t on esp-idf is uint8_t, so the stack size is specified in bytes not words. So passing 1024 for usStackDepth yields a 1KB stack not a 4KB stack. I'll make sure we document this somewhere.

As far as I know (I'm sure Jeroen can explain this properly if I'm wrong), the main reason that even simple tasks need some stack space is that exception handlers (ie interrupt handlers) use the running task's stack, both for saving context and for executing the ISR. It may be possible to rework this in the future so that all exception handlers share a stack region, however as exceptions can be configured in various ways (multiple levels, preemption, etc.) this may be quite complex to get right.

Who is online

Users browsing this forum: Google [Bot] and 29 guests