URGENT Issue: Distinct global variables overlapping in memory

stevenh

Guru 20045 points

Other Parts Discussed in Thread: TMS320F28335

Hello,

I have this issue where setting an array element in a global unsigned int array is clearing a bit field in a bitfield of a global structure variable. I looked at the map file and found the memory of the array overlaps with the struture variable, i.e the 128 element array is at 0xD000 and the structure variable is at 0xD00A. I also noticed another unsigned int variable is at the same address of the global unsigned int array, i.e the unsigned int variable is at 0xD000 and the array starts at 0xD000.

What could be causing this issue?

Update: I am developing for a TMS320F28335 (compiler version 6.1.4) and using code composer 5.4.0.00091.

Stephen

over 12 years ago

0 Archaeologist over 12 years ago

TI__Guru* 84285 points

Are you using any pragmas or gcc-style attributes on the (struct or array) (type or variable)?

0 stevenh over 12 years ago in reply to Archaeologist

Guru 20045 points

I am using the following pragma for the array.

#pragma DATA_SECTION(ramData, "DMARAML5")

Stephen

0 Archaeologist over 12 years ago in reply to stevenh

TI__Guru* 84285 points

Hm.. That should not be a problem. I think I will need to see the source code for the definition of these objects, including the definition of the types involved.

0 stevenh over 12 years ago in reply to Archaeologist

Guru 20045 points

Hello,

I think what might be the issue is the way I set up the RAM sections in the Linker Command file. In the command file I specified one named RAM area for all of page 0 and 1 RAM while at the same time I specified the array go into the same RAM area that has a different name.

Please take a look at the attached command file.

Stephen

Fullscreen 5852.F28335.txt Download

/*
// TI File $Revision: /main/10 $
// Checkin $Date: July 9, 2008   13:43:56 $
//###########################################################################
//
// FILE:	F28335.cmd
//
// TITLE:	Linker Command File For F28335 Device
//
//###########################################################################
// $TI Release:$
// $Release Date:$
//###########################################################################
*/

/* ======================================================
// For Code Composer Studio V2.2 and later
// ---------------------------------------
// In addition to this memory linker command file, 
// add the header linker command file directly to the project. 
// The header linker command file is required to link the
// peripheral structures to the proper locations within 
// the memory map.
//
// The header linker files are found in <base>\DSP2833x_Headers\cmd
//   
// For BIOS applications add:      DSP2833x_Headers_BIOS.cmd
// For nonBIOS applications add:   DSP2833x_Headers_nonBIOS.cmd    
========================================================= */

/* ======================================================
// For Code Composer Studio prior to V2.2
// --------------------------------------
// 1) Use one of the following -l statements to include the 
// header linker command file in the project. The header linker
// file is required to link the peripheral structures to the proper 
// locations within the memory map                                    */

/* Uncomment this line to include file only for non-BIOS applications */
/* -l DSP2833x_Headers_nonBIOS.cmd */

/* Uncomment this line to include file only for BIOS applications */
/* -l DSP2833x_Headers_BIOS.cmd */

/* 2) In your project add the path to <base>\DSP2833x_headers\cmd to the
   library search path under project->build options, linker tab, 
   library search path (-i).
/*========================================================= */

/* Define the memory block start/length for the F28335  
   PAGE 0 will be used to organize program sections
   PAGE 1 will be used to organize data sections

    Notes: 
          Memory blocks on F28335 are uniform (ie same
          physical memory) in both PAGE 0 and PAGE 1.  
          That is the same memory region should not be
          defined for both PAGE 0 and PAGE 1.
          Doing so will result in corruption of program 
          and/or data. 
          
          L0/L1/L2 and L3 memory blocks are mirrored - that is
          they can be accessed in high memory or low memory.
          For simplicity only one instance is used in this
          linker file. 
          
          Contiguous SARAM memory blocks can be combined 
          if required to create a larger memory block. 
 */


MEMORY
{
PAGE 0:    /* Program Memory */
           /* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE1 for data allocation */

   ZONE0       : origin = 0x004000, length = 0x001000     /* XINTF zone 0 */
   RAML0L1L2L3L4L5L6L7 : origin = 0x008000, length = 0x008000
//  RAML0       : origin = 0x008000, length = 0x001000     /* on-chip RAM block L0 */
//  RAML1       : origin = 0x009000, length = 0x001000     /* on-chip RAM block L1 */
//  RAML2       : origin = 0x00A000, length = 0x001000     /* on-chip RAM block L2 */
//  RAML3       : origin = 0x00B000, length = 0x001000     /* on-chip RAM block L3 */
   ZONE6       : origin = 0x0100000, length = 0x100000    /* XINTF zone 6 */ 
   ZONE7A      : origin = 0x0200000, length = 0x00FC00    /* XINTF zone 7 - program space */ 
   FLASHH      : origin = 0x300000, length = 0x008000     /* on-chip FLASH */
   FLASHG      : origin = 0x308000, length = 0x008000     /* on-chip FLASH */
   FLASHF      : origin = 0x310000, length = 0x008000     /* on-chip FLASH */
   FLASHE      : origin = 0x318000, length = 0x008000     /* on-chip FLASH */
   FLASHD      : origin = 0x320000, length = 0x008000     /* on-chip FLASH */
   FLASHC      : origin = 0x328000, length = 0x008000     /* on-chip FLASH */
   FLASHA      : origin = 0x338000, length = 0x007F80     /* on-chip FLASH */
   CSM_RSVD    : origin = 0x33FF80, length = 0x000076     /* Part of FLASHA.  Program with all 0x0000 when CSM is in use. */
   BEGIN       : origin = 0x33FFF6, length = 0x000002     /* Part of FLASHA.  Used for "boot to Flash" bootloader mode. */
   CSM_PWL     : origin = 0x33FFF8, length = 0x000008     /* Part of FLASHA.  CSM password locations in FLASHA */
   OTP         : origin = 0x380400, length = 0x000400     /* on-chip OTP */
   ADC_CAL     : origin = 0x380080, length = 0x000009     /* ADC_cal function in Reserved memory */
   
   IQTABLES    : origin = 0x3FE000, length = 0x000b50     /* IQ Math Tables in Boot ROM */
   IQTABLES2   : origin = 0x3FEB50, length = 0x00008c     /* IQ Math Tables in Boot ROM */  
   FPUTABLES   : origin = 0x3FEBDC, length = 0x0006A0     /* FPU Tables in Boot ROM */
   ROM         : origin = 0x3FF27C, length = 0x000D44     /* Boot ROM */        
   RESET       : origin = 0x3FFFC0, length = 0x000002     /* part of boot ROM  */
   VECTORS     : origin = 0x3FFFC2, length = 0x00003E     /* part of boot ROM  */

PAGE 1 :   /* Data Memory */
           /* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE0 for program allocation */
           /* Registers remain on PAGE1                                                  */
   
   BOOT_RSVD   : origin = 0x000000, length = 0x000050     /* Part of M0, BOOT rom will use this for stack */
   RAMM0       : origin = 0x000050, length = 0x0003B0     /* on-chip RAM block M0 */
   RAMM1       : origin = 0x000400, length = 0x000400     /* on-chip RAM block M1 */
   RAML4       : origin = 0x00C000, length = 0x001000     /* on-chip RAM block L1 */
   RAML5       : origin = 0x00D000, length = 0x001000     /* on-chip RAM block L1 */
   RAML6       : origin = 0x00E000, length = 0x001000     /* on-chip RAM block L1 */
   RAML7       : origin = 0x00F000, length = 0x001000     /* on-chip RAM block L1 */
   ZONE7B      : origin = 0x20FC00, length = 0x000400     /* XINTF zone 7 - data space */
   FLASHB      : origin = 0x330000, length = 0x008000     /* on-chip FLASH */
}

/* Allocate sections to memory blocks.
   Note:
         codestart user defined section in DSP28_CodeStartBranch.asm used to redirect code 
                   execution when booting to flash
         ramfuncs  user defined section to store functions that will be copied from Flash into RAM
*/ 
 
SECTIONS
{
 
   /* Allocate program areas: */
   .cinit              : LOAD = FLASHA, PAGE=0
   .cio                : > RAML0L1L2L3L4L5L6L7, PAGE = 0
   .sysmem             : > RAML0L1L2L3L4L5L6L7, PAGE = 0
   .text               : > FLASHA, PAGE = 0 //LOAD = FLASHA, PAGE=0, RUN =  RAML0L1L2L3L4L5L6L7, PAGE = 0
   codestart           : > BEGIN,       PAGE = 0
   ramfuncs            : LOAD = FLASHA, PAGE = 0
                         RUN = RAML0L1L2L3L4L5L6L7, PAGE = 0
                         LOAD_START(_ramfuncs_loadstart),
                         LOAD_SIZE(_ramfuncs_loadsize),
                         RUN_START(_ramfuncs_runstart)

   csmpasswds          : > CSM_PWL     PAGE = 0
   csm_rsvd            : > CSM_RSVD    PAGE = 0
   
   /* Allocate uninitalized data sections: */
   .stack              : > RAMM1       PAGE = 1
   .ebss               : > RAML0L1L2L3L4L5L6L7     PAGE = 0
   .esysmem            : > RAMM1       PAGE = 1

   /* Initalized sections go in Flash */
   /* For SDFlash to program these, they must be allocated to page 0 */
   .econst             : > FLASHA      PAGE = 0
 //  .econst             : LOAD = FLASHA, RUN = RAML0L1L2L3L4L5L6L7, PAGE = 0
   .switch             : > FLASHA      PAGE = 0      

   /* Allocate IQ math areas: */
   IQmath           : > FLASHC      PAGE = 0                  /* Math Code */
   IQmathTables     : > IQTABLES,  PAGE = 0, TYPE = NOLOAD 
   
   /* Uncomment the section below if calling the IQNexp() or IQexp()
      functions from the IQMath.lib library in order to utilize the 
      relevant IQ Math table in Boot ROM (This saves space and Boot ROM 
      is 1 wait-state). If this section is not uncommented, IQmathTables2
      will be loaded into other memory (SARAM, Flash, etc.) and will take
      up space, but 0 wait-state is possible.
   */
   /*
   IQmathTables2    : > IQTABLES2, PAGE = 0, TYPE = NOLOAD 
   {
   
              IQmath.lib<IQNexpTable.obj> (IQmathTablesRam)
   
   }
   */
   
   FPUmathTables    : > FPUTABLES, PAGE = 0, TYPE = NOLOAD 
         
   /* Allocate DMA-accessible RAM sections: */
   DMARAML4         : > RAML4,     PAGE = 1
   DMARAML5         : > RAML5,     PAGE = 1 
   DMARAML6         : > RAML6,     PAGE = 1
   DMARAML7         : > RAML7,     PAGE = 1
   
   /* Allocate 0x400 of XINTF Zone 7 to storing data */
   ZONE7DATA        : > ZONE7B,    PAGE = 1

   /* .reset is a standard section used by the compiler.  It contains the */ 
   /* the address of the start of _c_int00 for C Code.   /*
   /* When using the boot ROM this section and the CPU vector */
   /* table is not needed.  Thus the default type is set here to  */
   /* DSECT  */ 
   .reset              : > RESET,      PAGE = 0, TYPE = DSECT
   vectors             : > VECTORS     PAGE = 0, TYPE = DSECT
   
   /* Allocate ADC_cal function (pre-programmed by factory into TI reserved memory) */
   .adc_cal     : load = ADC_CAL,   PAGE = 0, TYPE = NOLOAD

/* This did not work*/
     //UNION
     //{
     //   .cinit: > FLASHA      PAGE = 0
     //   .text:  > FLASHA      PAGE = 0
    // } crc_table(table1, algorithm=CRC32_PRIME)



}

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

0 Archaeologist over 12 years ago in reply to stevenh

TI__Guru* 84285 points

I'm sorry, I don't quite follow that. The linker command file has MEMORY specifications and SECTION specifications. A MEMORY specification defines memories such as FLASHA, RAML0, etc. A SECTION specification says which sections should go into which MEMORY.

What are the names of the memories involved, exactly?

You say you specified "the array go into the same RAM area that has a different name." Which section is the array in?

I do not understand what you mean by "same RAM area that has a different name." You cannot create two different MEMORY specifications that overlap; the linker will emit an error message. What did you mean by this?

0 Archaeologist over 12 years ago in reply to stevenh

TI__Guru* 84285 points

Could you please post the linker map file corresponding to that linker command file? (Linker --map_file option)

0 stevenh over 12 years ago in reply to Archaeologist

Guru 20045 points

Sorry about the confusion.

The array is in section DMARAML5 (resides in memory range named RAML5) and most of the rest of variables (including the one that overlaps with the array) are in section .ebss ( resides in "memory range" named RAML0L1L2L3L4L5L6L7).

The orgin and memory range for RAML0L1L2L3L4L5L6L7 is origin = 0x008000, length = 0x008000, which is a concatenation of memory ranges named RAML0, RAML1,RAML2,RAML3,RAML4, RAML5,RAML6,RAML7. Memory ranges named RAML0, RAML1,RAML2,RAML3 are located on Page 0 and Memory ranges named RAML4, RAML5,RAML6,RAML7 are on page 1. Is it ok specify a section that is a concatenation memory ranges located on different pages?

Also, doesn't section .ebss overlap with section DMARAML5. Shouldn't the linker catch this situation or is there a problem with the linker?

Update: I meant to say "Also, doesn't RAML0L1L2L3L4L5L6L7 overlap with RAML5..". I believe there's any issue with creating a named memory range that is a concatenation of two different memory sections because the linker won't be able to catch the overlap.

Stephen

0 Archaeologist over 12 years ago in reply to stevenh

TI__Guru* 84285 points

It's still unclear to me what the symptom is, but I think I'm getting an idea of where the problem may be coming from.

When you tell the linker (using the linker command file) that you have more than one page, it thinks the pages are in separate addressing spaces, which is not true for F28335. The linker cannot detect overlap between RAML0L1L2L3L4L5L6L7 on page 0 and (for instance) RAML4 on page 1. As far as the linker is concerned, these cannot overlap because they are entirely disjoint address spaces. This is not actually true of the hardware, but that is what the linker command file is claiming. Really, for F28335, page 1 should not be used in the linker command file; everything should just be on page 0. Due to the nature of the F28335 hardware, it is not OK to have overlapping MEMORY specifications, even if they are on different pages; however, the linker doesn't know that - it relies strictly on the command file. In short, because page 0 is the same memory as page 1, it's OK to combine MEMORY specifications containing what were once on different pages, but it is not OK to leave any overlapping sections in.

Why do you need to create a larger MEMORY specification? You should only need to do that if you have an object that must go into one of RAMLn but none of them are large enough. If you simply need to automatically distribute things like .cio and .sysmem among RAMLn, use this syntax instead:

   .cio                : > RAML0|RAML1|RAML2|RAML3|RAML4L|RAM5|RAML6|RAML7, PAGE = 0
   .sysmem             : > RAML0|RAML1|RAML2|RAML3|RAML4L|RAM5|RAML6|RAML7, PAGE = 0
   ramfuncs            : > LOAD = FLASHA, PAGE=0, RUN = RAML0|RAML1|RAML2|RAML3|RAML4L|RAM5|RAML6|RAML7, PAGE = 0
   .ebss               : > RAML0|RAML1|RAML2|RAML3|RAML4L|RAM5|RAML6L7PAGE = 0

If you want to split .text into chunks and potentially place in more than one of RAMLn, use the split operator (>>)

   .text               : >> LOAD = FLASHA, PAGE=0, RUN = RAML0|RAML1|RAML2|RAML3|RAML4L|RAM5|RAML6|RAML7, PAGE = 0

Code Composer Studio™︎

Code Composer Studio forum

URGENT Issue: Distinct global variables overlapping in memory