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.

Different behavior when .stack in DDR and L2RAM

I am working at DM6437. Something about CMD file puzzled me.

Take led.prj for example. It consist of two source files: main.c and led.c

 main.c

#include "stdio.h"

#include "mk6437.h"

extern Int16 led_test( );

void main( void )

{

    /* Initialize BSL */

    MK6437_init( ); 

    led_test();

}

 

led.c

#include "mk6437_gpio.h"

Int16 led_test( )

{

    Int16 i;

         MK6437_GPIO_init();

         MK6437_GPIO_setDir(GPIO00,0);

         MK6437_GPIO_setDir(GPIO01,0);

         MK6437_GPIO_setDir(GPIO02,0);

         MK6437_GPIO_setDir(GPIO03,0);

         for(i=0;i<1000;i++)

         {

                   MK6437_GPIO_setOutput(GPIO00,1);

                   MK6437_GPIO_setOutput(GPIO01,1);

                   MK6437_GPIO_setOutput(GPIO02,1);

                   MK6437_GPIO_setOutput(GPIO03,1);

                   _waitusec( 125000 );

                   MK6437_GPIO_setOutput(GPIO00,0);

                   MK6437_GPIO_setOutput(GPIO01,0);

                   MK6437_GPIO_setOutput(GPIO02,0);

                   MK6437_GPIO_setOutput(GPIO03,0);

                   _waitusec( 125000 );

         }

    return 0;

}

 

link.cmd

/*

*  Linker command file

*/ 

-l rts64plus.lib

-l ../../lib/mk6437bsl.lib

-stack          0x00001000      /* Stack Size */

-heap           0x00001000      /* Heap Size */

MEMORY

{

    L2RAM:      o = 0x10800000  l = 0x00020000

    DDR2:       o = 0x80000000  l = 0x10000000

}

SECTIONS

{

    .bss        >   L2RAM

    .cinit      >   L2RAM

    .cio        >   L2RAM

    .const      >   L2RAM

    .data       >   L2RAM

    .far        >   L2RAM

    .stack      >   DDR2

    .switch     >   L2RAM

    .sysmem     >   L2RAM

    .text       >   DDR2

    .ddr2       >   DDR2

}

 

Please note the section in red.

When place the .stack at L2RAM, it works well. LEDs on boards wink at the frequency of 4Hz. But when place the .stack at DDR2, something is wrong. LEDs on boards wink at the frequency of about 1Hz.

At the second case, we can find the contents in “led.map” showing like these:

led.map 

******************************************************************************

          TMS320C6x COFF Linker PC v6.0.8                     

******************************************************************************

>> Linked Sun Dec 30 20:49:00 2012

OUTPUT FILE NAME:   <./Debug/led.out>

ENTRY POINT SYMBOL: "_c_int00"  address: 80002300

MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill

----------------------  --------  ---------  --------  --------  ----  --------

  L2RAM                 10800000   00020000  00000208  0001fdf8  RWIX

  DDR2                  80000000   10000000  00003460  0fffcba0  RWIX

SECTION ALLOCATION MAP

 output                                  attributes/

section   page    origin      length       input sections

--------  ----  ----------  ----------   ----------------

.ddr2      0    80000000    00000000     UNINITIALIZED

.text      0    80000000    00002460    

                  80000000    00000660     mk6437bsl.lib : mk6437_pll.obj (.text)

                  80000660    00000520                   : mk6437.obj (.text)

                  80000b80    00000460                   : mk6437_flash_id.obj (.text)

                  80000fe0    00000340                   : mk6437_i2c.obj (.text)

                  80001320    000002e0                   : mk6437_psc.obj (.text)

                  80001600    00000240                   : mk6437_gpio.obj (.text)

                  80001840    000001e0                   : mk6437_flash.obj (.text)

                  80001a20    000001c0                   : mk6437_ddr.obj (.text)

                  80001be0    000001a0     rts64plus.lib : mpyd.obj (.text:__mpyd)

                  80001d80    00000160     led_test.obj (.text)

                  80001ee0    00000100     rts64plus.lib : frcmpyd.obj (.text:__frcmpyd)

                  80001fe0    00000100                   : exit.obj (.text:_exit)

                  800020e0    000000e0                   : autoinit.obj (.text:__auto_init)

                  800021c0    000000a0                   : fixdu.obj (.text:__fixdu)

                  80002260    000000a0                   : memcpy64.obj (.text:_memcpy)

                  80002300    00000060                   : boot.obj (.text:_c_int00)

                  80002360    00000040     main.obj (.text)

                  800023a0    00000040     rts64plus.lib : args_main.obj (.text:__args_main)

                  800023e0    00000040                   : fltud.obj (.text:__fltud)

                  80002420    00000020                   : _lock.obj (.text:__nop)

                  80002440    00000020                   : exit.obj (.text:_abort)

.stack     0    80002460    00001000     UNINITIALIZED

                  80002460    00000008     rts64plus.lib : boot.obj (.stack)

.cio       0    10800000    00000000     UNINITIALIZED

 

Obviously, .stack is placed into DDR2 following the instruction in link.cmd. But, by the contents above, only the boot section from rts64plus.lib exits in .stack section.

Would anyone interpret this behavior?

  • Hello Kaishuang,


    I am not sure why you have a problem with this, and I am not necessarily an expert on this subject matter. However, I will give it a shot.


    I am assuming that you are wondering if you really have a stack - since only boot.obj was linked to it. This seems pretty normal to me. Stack is represented by linker symbols; as opposed to C compiler symbols. Check out this thread for more information on that: http://e2e.ti.com/support/development_tools/compiler/f/343/t/92002.aspx.


    If you were to write create code to fill the stack, for example in the case of a stack checker, you might create a C compiler symbol to access and fill the stack space. If you did that, you would see that symbol in your map file.


    Hope that helps,

    Brock