H8 port: increase task stack size

Kernel
1

nobody wrote on Thursday, December 21, 2006:

is it possible to increase the task’s stack size - more than specified in freertosconfig.h?
i know that it depends on sizeof(size_t).
255 bytes stack is not enough.

2

rtel wrote on Thursday, December 21, 2006:

The size of the stack allocated to a task is passed in as a parameter to the xTaskCreate() function.  You can set it to any value you like (within the limits of the RAM available to you).

FreeRTOSConfig.h contains a definition configMINIMAL_STACK_SIZE - the only place this is used in the scheduler code is to size the stack allocated to the idle task.

The demo applications also use configMINIMAL_STACK_SIZE when the demo tasks are created but this is just that - a demo - and not part of the scheduler code per se.

Regards.

3

nobody wrote on Thursday, December 21, 2006:

thanks for the fast repsonse!

the problem is that xtaskcreate only supports a stack depth of maximal 255.

see the function header:

signed portBASE_TYPE xTaskCreate( pdTASK_CODE pvTaskCode, const signed portCHAR * const pcName, unsigned portSHORT usStackDepth, void *pvParameters, unsigned portBASE_TYPE uxPriority, xTaskHandle *pxCreatedTask )

stackdepth is of size short (one byte).

best regards,
johannes

4

nobody wrote on Thursday, December 21, 2006:

Are you sure short is one byte?  I would assume it is two bytes.  Maybe this is a compiler switch you can set.  Alternatively, in FreeRTOS\Source\portable\GCC\H8S2329\portmacro.h, change the #define for portSHORT to be another type (integer?).

5

nobody wrote on Thursday, December 21, 2006:

yes you are right - short is 2 bytes long.
but i can’t increase the stack depth more than 255. that’s why i thought it’s one byte.

6

nobody wrote on Thursday, December 21, 2006:

there is no compiler warning/error when i want to increase the stack size but the board will crash because the calculated top of stacks are far beyond the RAM addresses. even if i use 256 instead of 255 for the stack size.
what could be the problem???

7

nobody wrote on Thursday, December 21, 2006:

Try changing portBASE_TYPE to short instead of char, assuming it is char that is.  If chars are used to calculate the top of stack then maybe there is an overflow occurring and the larger data type would prevent it.