Unable to reconfigure the stack size

[Fabricio de Novaes Kucinskis]

Hello everybody,

I have an application that has blown the stack, tried a lot of things to fix 
it, and up to now nothing worked. In fact, nothing that I've tried so far had 
any effect on the stack size. 

It's clear to me that I'm missing or misunderstanding something. In order to 
discover what, follows a detailed description (sorry for the length) of my 
problem, and what I've tried - my hope is that, by describing in detail, I 
expose what I'm doing wrong and allow you to point it.

I'm using RTEMS 4.10.0 for the SIS BSP.

I have a task that demands more than the RTEMS default stack size for the 
ERC32 (I'm using SIS to try it, but I think this should not be an issue). At 
some point a local variable is overwritten by a memcpy applied to a large 
array in the .bss area, and the application falls in an infinite loop.

Follows the stack report taken immediatelly before the blow:

Stack usage by thread
    ID      NAME    LOW          HIGH     CURRENT     AVAILABLE     USED
0x09010001  IDLE 000205E2D0 - 000205F2DF 000205F0A0      4096        752
0x0A010002  ISIS 0002060BB0 - 0002061BBF 00020617C8      4096       4036
0xFFFFFFFF  INTR 000205C5D0 - 000205D5CF 0000000000      4080        576
Memory exception at 2cbe13c (illegal address)
Unexpected trap ( 9) at address 0x02014228
data access exception at 0x02CBE13C

Note: the "Memory exception" error only happens when I enable the stack 
checker, but I assume this is expected.

"Ok", I thought, "the default stack is not enough, so let's change it" - and 
that's what I've been trying to do for the last couple of days, with no 
success.

The first thing I tried was to change the stack size for the application, 
setting CONFIGURE_MINIMUM_STACK_SIZE to 8 kbytes, and changing the creation of 
the task, using RTEMS_CONFIGURED_MINIMUM_STACK_SIZE. But as a 
new stack report has shown, it seems to have no effect on the stack size. The 
same goes for the CONFIGURE_EXTRA_TASK_STACKS #define.

Starting to be worried, I've tried to change the start address of the RTEMS 
work area by using CONFIGURE_EXECUTIVE_RAM_WORK_AREA, just to see what 
happens. Again, nothing different.

To illustrate, follows the configuration with everything I tried. The 
corresponding stack report is exactly the same as above.

#define CONFIGURE_MINIMUM_STACK_SIZE 		(1024 * 8)
#define CONFIGURE_EXTRA_TASK_STACKS 		(1024 * 8)
#define CONFIGURE_EXECUTIVE_RAM_WORK_AREA	0x02100000
#define CONFIGURE_STACK_CHECKER_ENABLED

Now a little bit desperate, I went into the ERC32 BSP code. There is a 
STACK_SIZE defined in the start.S file, but not used there. The same is 
redefined in bspgetworkarea.c. But the way it is used suggests to me that the 
RTEMS work area shall not touch into this area:

void bsp_get_work_area(...) {
  /* must be identical to STACK_SIZE in start.S */
  #define STACK_SIZE (16 * 1024)
  *work_area_start      = &end;
  *work_area_size       = (void *)rdb_start - (void *)&end - STACK_SIZE;
  
Being "end" a symbol set at linkcmds.base, pointing to the end of the .bss 
area, and "rdb_start" pointing to the end of RAM, I assumed that RTEMS sets 
the ERC stack pointer to work_area_start + work_area_size, but this seems not 
to be the case. 

Digging deeper into the BSP code, I saw that _CPU_Context_switch saves the 
registers, including the stack pointer (not touched by RTEMS yet). At the 
first call to _CPU_Context_restore_heir, the stack pointer is "restored" to an 
address that I couldn't relate to anything:

- work_area_start = 0x205c150 (end of the .bss section)
- work_area_size = 0x39feb0 (last RAM address - first free RAM address - 
STACK_SIZE)
- restored stack pointer at _CPU_Context_restore_heir = 0x20606f0 (???)

That's when I, already dizzy, stopped trying and decided to ask the list. It 
shall be something (maybe elementary) that I'm doing wrong, but I don't know 
what it could be, nor where to look at anymore.

Thanks for your time and best regards,

Fabrício Kucinskis.