• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 29 subscribers
  • Views 2145 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

__STACK_TOP symbol in TivaWare 1.0 example projects appears unnecessary

Chester Gillon
Guru 92251 points

The examples\project in TivaWave 1.0 project_ccs.cmd linker command file has the comment:

/* --stack_size=256 */

And symbol definition which implies a stack size of 256 bytes:

__STACK_TOP = __stack + 256;

The __STACK_TOP symbol defined in the linker command file is referenced by the g_pfnVectors table in startup_ccs.c, which sets the initial stack pointer at processor reset.

The stack pointer set by  __STACK_TOP appears not to be used, since before using the stack, the boot.asm code from the ARM compiler run time library sets the stack pointer according to the size set by the CCS project property Build -> ARM Linker -> Basic Options -> Set C system stack size (--stack_size, -stack).

To avoid confusion recommend changing the TivaWare CCS examples such that:

a) Remove the definition of the __STACK_TOP symbol from the project_ccs.cmd linker command file

b) Change the g_pfnVectors table in startup_ccs.c to use __STACK_END instead of __STACK_TOP. Where __STACK_END is already being defined by the ARM compiler linker, based upon the C system stack size CCS project property.

 

(I noticed this issue since had a program crashing due to insufficient stack size, and was checking if the stack size in the linker command file or CCS project properties was the one actually being used)

  • 0
    Prodigy 80 points

    If I'm following you correctly, another way to rectify everything is to instead do: __STACK_TOP = __stack + __STACK_SIZE;   which will then adjust accordingly based on the value for --stack_size in project properties.

  • 0
    Guru 27285 points

    Chester Gillon said:
    (I noticed this issue since had a program crashing due to insufficient stack size, and was checking if the stack size in the linker command file or CCS project properties was the one actually being used)

     Hi, I lost two week to try pinpoint what was happening on my code, before do an analysis to map files I measured stack deep from IRQ and finally I discovered stack get set from project property and this linker directive is ignored.

  • 0 in reply to Roberto Romano
    Guru 92251 points

    Roberto Romano said:
    Hi, I lost two week to try pinpoint what was happening on my code, before do an analysis to map files I measured stack deep from IRQ and finally I discovered stack get set from project property and this linker directive is ignored.

    The default L4MF linker command file in CCS 5.4 has the following SECTIONS for RAM:

       .vtable : > 0x20000000
        .data : > SRAM
        .bss : > SRAM
        .sysmem : > SRAM
        .stack : > SRAM

    This means the .stack section may be placed at a higher address in RAM than other variables, and thus if a stack overflow occur the code continues to run and corrupts other variables, which makes the cause of the stack overflow harder to detect; since the code fails sometime after the stack overflow occurs.

    To detect a stack overflow at the point it occured I changed the SECTIONS in the linker command file to place the .stack section at the lowest memory address:

     .vtable : > SRAM
        .data : > SRAM
        .bss : > SRAM
        .sysmem : > SRAM
        .stack : > 0x20000000

    This means that as soon as a stack overflow occurs a hard fault is generated when the code attempts to write to an unmapped memory address.

    The side effect of this linker command file change is that the .vtable section is no longer aligned which means a RAM based interrupt vector table can't be used; but the default TivaWare project setup uses a flash based interrupt vector table in startup_ccs.c so not a problem.