Compiler/TMS320F28377S: Need to initialize large arrays

Paul Berneis

Part Number: TMS320F28377S

Tool/software: TI C/C++ Compiler

I need to embed large arrays (12 arrays of 500 const unsigned int each) containing random data into a program. The program builds without error, but the arrays are not initialized. I have tried numerous variations in the .cmd link file but I have not found a combination that works. I am using CCS v6.2. Any help would be appreciated, or if CCS does not support this I would like to know so that I can begin looking for an alternate way to make my program work..

over 7 years ago

0 George Mock over 7 years ago

TI__Guru**** 249900 points

Please show the first few lines of the code you use the define and initialize one of these arrays. Also attach your linker command file to your next post. So the forum will accept it, add the file extension .txt to it.

Thanks and regards,

-George

0 Paul Berneis over 7 years ago

Prodigy 170 points

The code that creates and initializes the array looks like:

const unsigned char SerialBoot[] =

{

0x08, 0xAA, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, … 0x01

0xFF, 0xFF, 0x0A, 0x0B, 0x0C, 0x0D, 0x00, … 0x00

…

0xFF, 0xC2, 0x00, 0x00, 0xFF, 0xC3, 0x00, … 0x00

};

const unsigned int ARRAY_SIZE = 5414;

I have tried to attach a file named: 28377S_RAM_lnk.cmd.txt, which resulted in the large gray object below. Can you tell me how to insert the file properly?

Thank you.

Regards,

Paul

Fullscreen 28377S_RAM_lnk.cmd.txt Download

MEMORY
{
PAGE 0 :
   /* BEGIN is used for the "boot to SARAM" bootloader mode   */

   BEGIN           	: origin = 0x000000, length = 0x000002
   RAMM0           	: origin = 0x000122, length = 0x0002DE
   RAMD0           	: origin = 0x00B000, length = 0x000800
   RAMLS0          	: origin = 0x008000, length = 0x000800
   RAMLS1          	: origin = 0x008800, length = 0x000800
   RAMLS2      		: origin = 0x009000, length = 0x000800
   RAMLS3      		: origin = 0x009800, length = 0x000800
   RAMLS4      		: origin = 0x00A000, length = 0x000800
   RAMGS14     		: origin = 0x01A000, length = 0x001000
   RAMGS15     		: origin = 0x01B000, length = 0x001000
   RESET           	: origin = 0x3FFFC0, length = 0x000002

PAGE 1 :

   BOOT_RSVD       : origin = 0x000002, length = 0x000120     /* Part of M0, BOOT rom will use this for stack */
   RAMM1           : origin = 0x000400, length = 0x000400     /* on-chip RAM block M1 */
   RAMD1           : origin = 0x00B800, length = 0x000800


   RAMLS5      : origin = 0x00A800, length = 0x000800

   RAMGS0      : origin = 0x00C000, length = 0x001000
   RAMGS1      : origin = 0x00D000, length = 0x001000
   RAMGS2      : origin = 0x00E000, length = 0x001000
   RAMGS3      : origin = 0x00F000, length = 0x001000
   RAMGS4      : origin = 0x010000, length = 0x001000
   RAMGS5      : origin = 0x011000, length = 0x001000
   RAMGS6      : origin = 0x012000, length = 0x001000
   RAMGS7      : origin = 0x013000, length = 0x001000
   RAMGS8      : origin = 0x014000, length = 0x001000
   RAMGS9      : origin = 0x015000, length = 0x001000
   RAMGS10     : origin = 0x016000, length = 0x001000
   RAMGS11     : origin = 0x017000, length = 0x001000
   RAMGS12     : origin = 0x018000, length = 0x001000
   RAMGS13     : origin = 0x019000, length = 0x001000

}


SECTIONS
{
   codestart        : > BEGIN,     PAGE = 0
   
/* #ifdef __TI_COMPILER_VERSION__
   #if __TI_COMPILER_VERSION__ >= 15009000 */
    .TI.ramfunc : {} > RAMM0,      PAGE = 0
 /*  #else */
   ramfuncs         : > RAMM0      PAGE = 0   
 /*  #endif
#endif */

   .text            : >>RAMM0 | RAMD0 |  RAMLS0 | RAMLS1 | RAMLS2 | RAMLS3 | RAMLS4,   PAGE = 0
   .cinit           : > RAMM0,     PAGE = 0
   .pinit           : > RAMM0,     PAGE = 0
   .switch          : > RAMM0,     PAGE = 0
   .reset           : > RESET,     PAGE = 0, TYPE = DSECT /* not used, */

   .stack           : > RAMM1,     PAGE = 1
   .ebss            : > RAMLS5,    PAGE = 1
   .econst          : > RAMLS5,    PAGE = 1
   .esysmem         : > RAMLS5,    PAGE = 1

   ramgs0           : > RAMGS0,    PAGE = 1
   ramgs1           : > RAMGS1,    PAGE = 1

   ImageFile1       : > RAMGS2,    PAGE = 1
   ImageFile2       : > RAMGS2,    PAGE = 1
   ImageFile3       : > RAMGS2,    PAGE = 1
   ImageFile4       : > RAMGS2,    PAGE = 1
   ImageFile5       : > RAMGS2,    PAGE = 1
   ImageFile6       : > RAMGS2,    PAGE = 1
   ImageFile7       : > RAMGS2,    PAGE = 1
   ImageFile8       : > RAMGS2,    PAGE = 1

   ImageFile9       : > RAMGS3,    PAGE = 1
   ImageFile10      : > RAMGS3,    PAGE = 1
   ImageFile11      : > RAMGS3,    PAGE = 1
   ImageFile12      : > RAMGS3,    PAGE = 1
   ImageFile13      : > RAMGS3,    PAGE = 1

#if 0
   ImageFile14      : > RAMGS3,    PAGE = 1
   ImageFile15      : > RAMGS3,    PAGE = 1
   ImageFile16      : > RAMGS3,    PAGE = 1

   ImageFile17      : > RAMGS4,    PAGE = 1
   ImageFile18      : > RAMGS4,    PAGE = 1
   ImageFile19      : > RAMGS4,    PAGE = 1
   ImageFile20      : > RAMGS4,    PAGE = 1
   ImageFile21      : > RAMGS4,    PAGE = 1
   ImageFile22      : > RAMGS4,    PAGE = 1
   ImageFile23      : > RAMGS4,    PAGE = 1
   ImageFile24      : > RAMGS4,    PAGE = 1

   ImageFile25      : > RAMGS5,    PAGE = 1
#endif

}

/*
//===========================================================================
// End of file.
//===========================================================================
*/

0 George Mock over 7 years ago in reply to Paul Berneis

TI__Guru**** 249900 points

Paul Berneis said:
I have tried to attach a file named: 28377S_RAM_lnk.cmd.txt

The attachment made it. I have seen the large gray box before. I'm not sure what the story is with that.

I presume you declare the arrays at file level, and not within a function. If that is the case, then they all go in the .econst section. This section is allocated to the memory range RAMLS5, which is 0x1000 words long. But 12 arrays of 500 words each is 0x1770 words. That's too big. Do you see a link time error?

Another question ... In your system, how does an initialized section like .econst get from the final executable file created by the linker (it usually has the file extension .out) into RAM? Could the problem be in this step?

Thanks and regards,

-George

0 Paul Berneis over 7 years ago in reply to George Mock

Prodigy 170 points

You presume correctly that the arrays are declared at file level.

Neither the compiler nor the linker reports any errors.

Some background: the array is auto generated from a .hex file that turns the input into something I can embed in a program. This is part of a multi stage process to update the firmware in the Delfino. The Delfino is a subsidiary processor to another processor known as the generic processor. All access to the Delfino is through the generic processor. The generic processor has control of the reset signal and the two boot mode inputs to the Delfino. It also has a UART connection for sending and receiving data.

The program that contains the arrays will be downloaded to the Delfino RAM by the generic processor through the UART connection, using the boot load protocol defined in the Delfino manual. Once it has been downloaded it will execute an application that copies the data from the arrays to flash.

When I build the program I observe that the output file (Intel .hex format) is not nearly large enough (2707 words when the data is extracted from the .hex format) to initialize the array data even without the executable program itself.

As an alternate solution the generic program could download the data to an absolute location in RAM and the Delfino program could access it there. I am investigating how to access an absolute location from a C program.

Regards,
Paul

0 George Mock over 7 years ago in reply to Paul Berneis

TI__Guru**** 249900 points

Paul Berneis said:
When I build the program I observe that the output file (Intel .hex format) is not nearly large enough (2707 words when the data is extracted from the .hex format) to initialize the array data even without the executable program itself.

I wonder how that happened. Take a look at the map file created by the linker. It is usually has the file extension .map. Does it show what you expect? If you are confused, you are welcome to attach it to your next post. So the forum will accept it, add the file extension .txt to it.

Thanks and regards,

-George

0 Paul Berneis over 7 years ago in reply to George Mock

Prodigy 170 points

Flash_Test.map.txtThe map file shows that memory has been allocated for each array and none is marked "uninitialized".

I have attached the map file.

Regards,

Paul

0 George Mock over 7 years ago in reply to Paul Berneis

TI__Guru**** 249900 points

I am mostly certain I know what is happening. I cannot tell you how to fix it.

In the map file I can see output sections with names like ImageFile1. They are initialized. Most importantly, they are not page 0, but on page 1. This occurs because these output sections are allocated to a memory range, like RAMGS2, that is on page 1. The hex utility outputs initialized sections for different pages in different output files. This second output file probably has the file extension .i10. To see exactly which output files are created, use the hex utility option --map to create a hex map file, then search that file for lines marked OUTPUT FILES.

For hints on how you might fix it, I suggest you read the section titled Assigning Output Filenames in the C28x assembly tools manual.

Thanks and regards,

-George

0 Paul Berneis over 7 years ago in reply to George Mock

Prodigy 170 points

Thank you for your help. You pointed me in the right direction and now I know how to correct my problem.

Code Composer Studio™︎

Code Composer Studio forum

Compiler/TMS320F28377S: Need to initialize large arrays