Access to global variables in the external SDRAM

My guess is that the linker command file for the old project explicitly specifies where the ".external" section goes in memory, and the linker command file for the new project has no specification for ".external".  Please inspect the linker command file for the new project.  If I'm right, ".external" is not mentioned anywhere.  If that is the case, you need to add a specification for .external.  This wiki article will help you do that.

Thanks and regards,

-George

Hi George

I  could see the address of ".external" in "linklnfo.xml" :

 <object_component id="oc-5ea">
         <name>.cinit..external.load</name>
         <load_address>0x2d28</load_address>
         <run_address>0x2d28</run_address>
         <size>0x8</size>
      </object_component>

         <cprec>
            <name>.external</name>
            <load_address>0x2d28</load_address>
            <load_size>0x8</load_size>
            <run_address>0x60000000</run_address>
            <run_size>0x50</run_size>
            <compression>zero_init</compression>
         </cprec>

Also, I could see the below as well in ".map":

__TI_cinit_table @ 00002d30 records: 3, size/record: 8, table size: 24
	.data: load addr=00002cc8, load size=00000047 bytes, run addr=2002a5ac, run size=000000b0 bytes, compression=rle
	.bss: load addr=00002d20, load size=00000008 bytes, run addr=20000000, run size=000265ac bytes, compression=zero_init
	.external: load addr=00002d28, load size=00000008 bytes, run addr=60000000, run size=00000050 bytes, compression=zero_init

Thanks,

Jin

Please attach the entire map file to your next post.  You might need to add a ".txt" extension to it so it will be accepted.  

Based on what I see here, there is a section named ".external", and it is located at address 0x60000000.  Given what you know about the system, does this address make sense?  Would accessing that address cause some kind of HW fault?

Thanks and regards,

-George

Hi George,

Here is my .cmd :

#define APP_BASE 0x00000000
#define RAM_BASE 0x20000000
#define SDRAM_BASE 0x60000000

/* System memory map */

MEMORY
{
    /* Application stored in and executes from internal flash */
    FLASH (RX) : origin = APP_BASE, length = 0x00100000
    /* Application uses internal RAM for data */
    SRAM (RWX) : origin = 0x20000000, length = 0x00040000
    /* Application uses external RAM for large data arrays */
    SDRAM (RWX) : origin = SDRAM_BASE, length = 0x00800000
}

/* Section allocation in memory */

SECTIONS
{
    .intvecs:   > APP_BASE
    .text   :   > FLASH
    .const  :   > FLASH
    .cinit  :   > FLASH
    .pinit  :   > FLASH
    .init_array : > FLASH

    .vtable :   > RAM_BASE
    .data   :   > SRAM
    .bss    :   > SRAM
    .sysmem :   > SRAM
    .stack  :   > SRAM
    .external : > SDRAM
}

__STACK_TOP = __stack + 16384;

As you see, the address of 8MB SDRAM starts at 0x60000000 and ends at 0x003FFFFF since (4Meg*16).

Attached: linkinfo.xml and .map

linkinfo_xml.txt

map.txt

As I ran the example of "sdram.c" to write/read values correctly. That's why I thought the external sdram on the custom board works fine.

#define SDRAM_START_ADDRESS 0x00000000
#define SDRAM_END_ADDRESS   0x003FFFFF

g_pui16EPISdram = (uint16_t *)0x60000000;

g_pui16EPISdram[SDRAM_START_ADDRESS] = 0xabcd;
    g_pui16EPISdram[SDRAM_START_ADDRESS + 1] = 0x1234;
    g_pui16EPISdram[SDRAM_END_ADDRESS - 1] = 0xdcba;
    g_pui16EPISdram[SDRAM_END_ADDRESS] = 0x4321;

Regards,

Jin

Hi George,

Thank you for commenting on my question.

I took a look at "Stellaris library" and found a couple of lib codes related with sdram.

There is a initializing function( SDRAMInit() ) in /drivers/extram.c. It is quite similar with the example codes( sdram.c) in Tiva C except one thing below:

bpool((void *)g_pusEPIMem, SDRAM_SIZE_BYTES);

bpool() is defined in "bget.c" in Stellaris (third_party/bget).

Is this needed to add on?

Thanks,

Jin

Your question is beyond my expertise.  I recommend you start a new thread in the TM4C device forum.  Or, if you prefer, I can move this thread into that forum.

Thanks and regards,

-George

Hi George,

I resolved the issue by activating EPI SDRAM before calling  _c_int00. Also

bpool()

has nothing to do with in this issue.

Thank you for your support.

Jin