Enabling SDRAM in CCS/Hercules/HalCoGen

Sarah Weinberger

Expert 1915 points

Other Parts Discussed in Thread: HALCOGEN

Using: RM48L952ZWT with HalCoGen and CCS

I have a custom board, not the Hercules HDK, which adds 128Mb (16MB) SDRAM, which the EE and I configured. We were able to get the SDRAM working. We tested the SDRAM by creating a function, doRamTest()

boolean doRamTest()
{
	uint32 *lpuRam = (uint32 *)0x80000000;
	uint32 uRamCount = 0x1000000 / 4;

	// Write the pattern.
	uint32 uIndex = 0;
	uint32 uData = 0xFFFFFFFF;
	uint32 *lpuIndex = lpuRam;
	for (uIndex = 0; uIndex < uRamCount; uIndex++)
	{
		*lpuIndex = uData;
		uData--;
		lpuIndex++;
	}

	// Verify the pattern.
	uData = 0xFFFFFFFF;
	lpuIndex = lpuRam;
	for (uIndex = 0; uIndex < uRamCount; uIndex++)
	{
		if (uData != *lpuIndex)
			return FALSE;
		uData--;
		lpuIndex++;
	}

	return TRUE;
}

The function successfully returns.

The CCS map file generated for my RM48L952ZWT Hercules chip with HalCoGen only uses the internal memory on the Hercules chip.

******************************************************************************
                  TI ARM Linker PC v5.2.7                      
******************************************************************************
>> Linked Mon May 30 08:27:51 2016

OUTPUT FILE NAME:   <CCMv3.out>
ENTRY POINT SYMBOL: "_c_int00"  address: 0003caa4


MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  VECTORS               00000000   00000020  00000020  00000000     X
  FLASH0                00000020   0017ffe0  0005047b  0012fb65  R  X
  FLASH1                00180000   00180000  00000000  00180000  R  X
  STACKS                08000000   00001500  00000000  00001500  RW  
  RAM                   08001500   0003eb00  000050d8  00039a28  RW

I am half expecting to see 2 RAM regions along with bigger allocations for everything. Here are our HalCoGen settings:

How do I get my development environment to make use of the SDRAM?

over 9 years ago

0 Charles Tsai over 9 years ago

TI__Guru**** 191906 points

Hi Sarah,
Looks like you are working on holiday. :-)

You mentioned that you are able to read/write to SDRAM with your doRamTest() function. What i'm not clear is your statement 'I am half expecting to see 2 RAM regions along with bigger allocations for everything'. Can you please elaborate what you meant here?

0 Chester Gillon over 9 years ago

Guru 92251 points

Sarah Weinberger said:
How do I get my development environment to make use of the SDRAM?

I haven't got a device with external memory to test it, but from looking at HALCoGen 04.05.02 when the EMIF configuration is enabled in a HALCoGen project I can't see anything which automatically adds the memory on the EMIF interface to the TI linker command file. I think you have to manually add MEMORY and SECTIONS entries to the source\HL_sys_link_cmd file in USER CODE blocks.

0 Sarah Weinberger over 9 years ago in reply to Charles Tsai

Expert 1915 points

Hi Charles,

Yeah, I am working today, because the EE can only work with me on weekends and holiday, so means that I am working today. We also need to get this project out the door.

Apologies for the poor wording, but the linker does not know about or use the SDRAM. The linker map file shows that the linker only made use of the 256K internal RAM on the processor. The Hercules HalCoGen did not tell CSS about the SDRAM.

How do I get the SDRAM utilized? That could be because I did not do an extra step in HalCoGen or I need to do something in CSS or whatever.

Sarah
P.S. I am glad that you have to work on a holiday too! :-)

0 Sarah Weinberger over 9 years ago in reply to Sarah Weinberger

Expert 1915 points

Hi Charles/Chester,

I modified HalCoGen as follows:

I modified the sys_link.cmd file as follows:

/*----------------------------------------------------------------------------*/
/* Memory Map                                                                 */

MEMORY
{
    VECTORS (X)  : origin=0x00000000 length=0x00000020
    FLASH0  (RX) : origin=0x00000020 length=0x0017FFE0
    FLASH1  (RX) : origin=0x00180000 length=0x00180000
    STACKS  (RW) : origin=0x08000000 length=0x00021000
    RAM     (RW) : origin=0x08021000 length=0x0001f000

/* USER CODE BEGIN (2) */
    RAM2    (RW) : origin=0x80000000 length=0x01000000
/* USER CODE END */
}

/* USER CODE BEGIN (3) */
/* USER CODE END */


/*----------------------------------------------------------------------------*/
/* Section Configuration                                                      */

SECTIONS
{
    .intvecs : {} > VECTORS
    .text    : {} > FLASH0 | FLASH1
    .const   : {} > FLASH0 | FLASH1
    .cinit   : {} > FLASH0 | FLASH1
    .pinit   : {} > FLASH0 | FLASH1
    .bss     : {} > RAM
    .data    : {} > RAM
	.sysmem  : {} > RAM
	
    FEE_TEXT_SECTION : {} > FLASH0 | FLASH1
    FEE_CONST_SECTION : {} > FLASH0 | FLASH1
    FEE_DATA_SECTION : {} > RAM

/* USER CODE BEGIN (4) */
    .bss     : {} > RAM | RAM2
    .data    : {} > RAM | RAM2
	.sysmem  : {} > RAM | RAM2
/* USER CODE END */
}

Here is the built linker map output: CCMv3.map:

******************************************************************************
                  TI ARM Linker PC v5.2.7                      
******************************************************************************
>> Linked Mon May 30 10:05:39 2016

OUTPUT FILE NAME:   <CCMv3.out>
ENTRY POINT SYMBOL: "_c_int00"  address: 0003caa8


MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  VECTORS               00000000   00000020  00000020  00000000     X
  FLASH0                00000020   0017ffe0  0005047f  0012fb61  R  X
  FLASH1                00180000   00180000  00000000  00180000  R  X
  STACKS                08000000   00021000  00000000  00021000  RW  
  RAM                   08021000   0001f000  000050d8  00019f28  RW  
  RAM2                  80000000   01000000  00000000  01000000  RW  


SEGMENT ALLOCATION MAP

run origin  load origin   length   init length attrs members
----------  ----------- ---------- ----------- ----- -------
00000000    00000000    000504a8   000504a8    r-x
  00000000    00000000    00000020   00000020    r-x .intvecs
  00000020    00000020    0003d8dc   0003d8dc    r-x .text
  0003d900    0003d900    0000ea73   0000ea73    r-- .const
  0004c378    0004c378    00004130   00004130    r-- .cinit
08021000    08021000    000050d8   00000000    rw-
  08021000    08021000    00004718   00000000    rw- .data
  08025718    08025718    00000800   00000000    rw- .sysmem
  08025f18    08025f18    000001c0   00000000    rw- .bss


SECTION ALLOCATION MAP

 output                                  attributes/
section   page    origin      length       input sections
--------  ----  ----------  ----------   ----------------

As you can see .data, .bss, and .sysmem all still use the internal RAM exclusively and from my view the linker still does not use the SDRAM.

My concern is class and malloc allocations.

Thanks,

Sarah

0 Charles Tsai over 9 years ago in reply to Sarah Weinberger

TI__Guru**** 191906 points

Hi Sarah,
The SDRAM is memory mapped at 0x80000000. Once you call the emif_SDRAMInit() the EMIF module will take care of interfacing between the CPU and the external SDRAM. If you are just eading/writing to the SRAM then you shouldn't need to touch the linker command file. If you are going to run code from SDRAM then you need to define MEMORY and SECTION in the linker command file and also define your load and run addresses. if you want to reserve spaces in SDRAM for uninitialized variables you will also define the MEMORY and SECTION in the linker command.

0 Chester Gillon over 9 years ago in reply to Sarah Weinberger

Guru 92251 points

Sarah Weinberger said:
As you can see .data, .bss, and .sysmem all still use the internal RAM exclusively and from my view the linker still does not use the SDRAM.
My concern is class and malloc allocations.

The syntax of RAM | RAM2 allows the linker to allocate from the first memory region which is large enough to satisfy the request, which is why the linker still used the internal RAM. Since you want to use the external SDRAM for dynamic memory allocation try the following which allocates the entire SDRAM for the heap:

/*----------------------------------------------------------------------------*/
/* Memory Map                                                                 */

MEMORY
{
    VECTORS (X)  : origin=0x00000000 length=0x00000020
    FLASH0  (RX) : origin=0x00000020 length=0x0017FFE0
    FLASH1  (RX) : origin=0x00180000 length=0x00180000
    STACKS  (RW) : origin=0x08000000 length=0x00001500
    RAM     (RW) : origin=0x08001500 length=0x0003EB00

/* USER CODE BEGIN (2) */
    RAM2    (RW) : origin=0x80000000 length=0x01000000
/* USER CODE END */
}

/* USER CODE BEGIN (3) */

/* Use the entire 16MB SDRAM for the heap */
--heap_size=0x01000000

#if 0
/* USER CODE END */


/*----------------------------------------------------------------------------*/
/* Section Configuration                                                      */

SECTIONS
{
    .intvecs : {} > VECTORS
    .text    : {} > FLASH0 | FLASH1
    .const   : {} > FLASH0 | FLASH1
    .cinit   : {} > FLASH0 | FLASH1
    .pinit   : {} > FLASH0 | FLASH1
    .bss     : {} > RAM
    .data    : {} > RAM
	.sysmem  : {} > RAM
	

/* USER CODE BEGIN (4) */
#endif

SECTIONS
{
    .intvecs : {} > VECTORS
    .text    : {} > FLASH0 | FLASH1
    .const   : {} > FLASH0 | FLASH1
    .cinit   : {} > FLASH0 | FLASH1
    .pinit   : {} > FLASH0 | FLASH1
    .bss     : {} > RAM
    .data    : {} > RAM
    .sysmem  : {} > RAM2
/* USER CODE END */
}

The linker map shows the RAM2 regions has been used for the heap (.sysmem):

SEGMENT ALLOCATION MAP

run origin  load origin   length   init length attrs members
----------  ----------- ---------- ----------- ----- -------
00000000    00000000    0000879c   0000879c    r-x
  00000000    00000000    00000020   00000020    r-x .intvecs
  00000020    00000020    00008450   00008450    r-x .text
  00008470    00008470    00000281   00000281    r-- .const
  000086f8    000086f8    000000a4   000000a4    r-- .cinit
08001500    08001500    000003c0   00000000    rw-
  08001500    08001500    000001f8   00000000    rw- .data
  080016f8    080016f8    000001c8   00000000    rw- .bss
80000000    80000000    01000000   00000000    rw-
  80000000    80000000    01000000   00000000    rw- .sysmem

Note that I used some #if trickery inside the USER CODE block modification to the sys_link.cmd file to override the automatically generated HALCoGen sections, in such a way that re-generating the project in HALCoGen doesn't loose the changes.

0 Sarah Weinberger over 9 years ago in reply to Chester Gillon

Expert 1915 points

1. What does .bss, .data, and .sysmem do?

2. I noticed that the FEE stuff got removed.

FEE_TEXT_SECTION : {} > FLASH0 | FLASH1
FEE_CONST_SECTION : {} > FLASH0 | FLASH1
FEE_DATA_SECTION : {} > RAM

Why was that? Can that go back?

0 Chester Gillon over 9 years ago in reply to Sarah Weinberger

Guru 92251 points

Sarah Weinberger said:
1. What does .bss, .data, and .sysmem do?

The .bss section is used for uninitialized variables with static storage.

The .data section is used for initialized variables with static storage.

The .sysmem section is used for dynamic memory allocation, i.e. calls to malloc() and new().

Sarah Weinberger said:
2. I noticed that the FEE stuff got removed.

That was my mistake. In my example I didn't enable the FEE driver in HALCoGen.

Arm-based microcontrollers

Arm-based microcontrollers forum

Enabling SDRAM in CCS/Hercules/HalCoGen