> .text [00000000 -> 0000360f] overlaps section .rodata [00000000 -> 00000318]
> .data [0000031c -> 00000333] overlaps section .text [00000000 -> 0000360f]
> .text lma 0x0 overlaps previous sections

See that your .text section occupies the same address space as .rodata
and .data. It is likely that your linker script (AT91SAM7S256-RAM.ld) is
incorrect.

Perhaps you should post the script.

Clifford

Clifford Slocombe wrote:
>> .text [00000000 -> 0000360f] overlaps section .rodata [00000000 -> 00000318]
>> .data [0000031c -> 00000333] overlaps section .text [00000000 -> 0000360f]
>> .text lma 0x0 overlaps previous sections
>
> See that your .text section occupies the same address space as .rodata
> and .data. It is likely that your linker script (AT91SAM7S256-RAM.ld) is
> incorrect.
>
> Perhaps you should post the script.
>
> Clifford

Hi,

I changed CODE and DATA size in "AT91SAM7S256-RAM.ld", it seems OK.
just post the file here:

// Srart of File
--------------------------------------------------------------

/*---------------------------------------------------------------------- 
-----*/
/*-         ATMEL Microcontroller Software Support  -  ROUSSET  -
*/
/*---------------------------------------------------------------------- 
-----*/
/* The software is delivered "AS IS" without warranty or condition of
any    */
/* kind, either express, implied or statutory. This includes without
*/
/* limitation any warranty or condition with respect to merchantability
or   */
/* fitness for any particular purpose, or against the infringements of
*/
/* intellectual property rights of others.             */
/*---------------------------------------------------------------------- 
-----*/
/*- File source          : GCC_RAM.ld
*/
/*- Object               : Linker Script File for RAM Workspace
*/
/*- Compilation flag     : None
*/
/*-
*/
/*- 1.0 11/Mar/05 JPP    : Creation S256
*/
/*---------------------------------------------------------------------- 
-----*/


/*
//*** <<< Use Configuration Wizard in Context Menu >>> ***
*/


/*
// <h> Memory Configuration
//   <h> Code (Read Only)
//     <o>  Start <0x0-0xFFFFFFFF>
//     <o1> Size  <0x0-0xFFFFFFFF>
//   </h>
//   <h> Data (Read/Write)
//     <o2> Start <0x0-0xFFFFFFFF>
//     <o3> Size  <0x0-0xFFFFFFFF>
//   </h>
//   <h> Top of Stack (Read/Write)
//     <o4> STACK <0x0-0xFFFFFFFF>
//   </h>
// </h>
*/

/* Memory Definitions */

MEMORY
{
  CODE (rx) : ORIGIN = 0x00000000, LENGTH = 0x00009000
  DATA (rw) : ORIGIN = 0x00009000, LENGTH = 0x00004000
  STACK (rw) : ORIGIN = 0x000d000,LENGTH = 0x00000000
}


/* Section Definitions */

SECTIONS
{
  /* first section is .text which is used for code */
  . = 0x0000000;
  .text : { *cstartup.o (.text) }>CODE =0
  .text :
  {
    *(.text)                   /* remaining code */

    *(.glue_7t) *(.glue_7)

  } >CODE =0

  . = ALIGN(4);

  /* .rodata section which is used for read-only data (constants) */

  .rodata :
  {
    *(.rodata)
  } >CODE

  . = ALIGN(4);

  _etext = . ;
  PROVIDE (etext = .);

  /* .data section which is used for initialized data */

  .data : AT (_etext)
  {
    _data = . ;
    *(.data)
    SORT(CONSTRUCTORS)
  } >DATA
  . = ALIGN(4);

  _edata = . ;
   PROVIDE (edata = .);

  /* .bss section which is used for uninitialized data */

  .bss :
  {
    __bss_start = . ;
    _bss_start_ = . ;
    *(.bss)
    *(COMMON)
  }
  . = ALIGN(4);
  _bss_end_ = . ;
  _bss_end_ = . ;
  _end = .;
    . = ALIGN(4);
   .int_data :
   {
   *(.internal_ram_top)
   }> STACK

  PROVIDE (end = .);

  /* Stabs debugging sections.  */
  .stab          0 : { *(.stab) }
  .stabstr       0 : { *(.stabstr) }
  .stab.excl     0 : { *(.stab.excl) }
  .stab.exclstr  0 : { *(.stab.exclstr) }
  .stab.index    0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment       0 : { *(.comment) }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the
beginning
     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug          0 : { *(.debug) }
  .line           0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo  0 : { *(.debug_srcinfo) }
  .debug_sfnames  0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges  0 : { *(.debug_aranges) }
  .debug_pubnames 0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info     0 : { *(.debug_info .gnu.linkonce.wi.*) }
  .debug_abbrev   0 : { *(.debug_abbrev) }
  .debug_line     0 : { *(.debug_line) }
  .debug_frame    0 : { *(.debug_frame) }
  .debug_str      0 : { *(.debug_str) }
  .debug_loc      0 : { *(.debug_loc) }
  .debug_macinfo  0 : { *(.debug_macinfo) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames  0 : { *(.debug_varnames) }

}

// End of File -----------------------------------------------------

Min Ge

Min Ge wrote:
> I changed CODE and DATA size in "AT91SAM7S256-RAM.ld", it seems OK.

So long as your memory usage is modest, that will work, but the script
dictates the exact locations and sizes of the STACK, CODE, and DATA
regions. This means that if  either section grows beyond the set length,
the link will fail even if there is otherwise plenty of RAM available.

It is more flexible to simply create a single RAM region and place all
the sections there, the linker will automatically place them
contiguously, so there are no large unused gaps, and the maximum amount
is then available for stack and heap growth. The STACK would normally be
placed as high as possible in RAM (since it grows downward). Unless you
are reserving that upper RAM region for something else, you might
consider placing it higher.

Clifford

Clifford Slocombe wrote:
> It is more flexible to simply create a single RAM region and place all
> the sections there, the linker will automatically place them
> contiguously, so there are no large unused gaps, and the maximum amount
> is then available for stack and heap growth. The STACK would normally be
> placed as high as possible in RAM (since it grows downward).

Could you please tell me how to set RAM as flexible?

Min Ge

Min Ge wrote:
>
> Could you please tell me how to set RAM as flexible?
>
I am reluctant, since I'm not there with you ro debug it when it all
goes wrong! Keep a copy of your current script - just in case.

I am assuming that your sbrk() or sbrk_r() implementation places the
heap above the stack (at _end), so I propose that you place all the code
and data sections starting from zero, place the stack at some defined
position above the last code/data section (fixed size stack) leaving the
rest for heap. You choose the stack size - your current script allows
the data section to grow to the point where there would be little or no
available stack without warning!

Define the memory layout thus:

MEMORY
{
  RAM (rw) : ORIGIN = 0, LENGTH = 64K
}
STACK_LENGTH = 4K ;

Now replace all the instances of >CODE or >DATA with >RAM

To set the stack top change the lines:

   .int_data :
   {
   *(.internal_ram_top)
   }> STACK

to:
   . += STACK_LENGTH ;
   .int_data :
   {
       *(.internal_ram_top)
   } >RAM


I strongly suggest that you create a map file for your build to ensure
that everything is located as expected, and to determine how much heap
you will have available (everything above _end).

If you do not require much heap (used by malloc() and similar functions
as well as the C++ new operators, and internally within C++ container
classes for example), then you might want to make your stack much larger
to minimise the chance of it clashing with your static data or code.
Remember that library functions such as printf() use a considerable
amount of stack space. The 4K I have used in the example is very
conservative, but should just about support printf(). You need to
consider the requirements of your application and set it accordingly.

Clifford

Clifford Slocombe wrote:
> MEMORY
> {
>   RAM (rw) : ORIGIN = 0, LENGTH = 64K
> }
> STACK_LENGTH = 4K ;
>
> Now replace all the instances of >CODE or >DATA with >RAM
>
> To set the stack top change the lines:
>
>    .int_data :
>    {
>    *(.internal_ram_top)
>    }> STACK
>
> to:
>    . += STACK_LENGTH ;
>    .int_data :
>    {
>        *(.internal_ram_top)
>    } >RAM
>
>

I have tried. It works. Thanks a lot.

Min Ge

Min Ge wrote:

>
> I have tried. It works. Thanks a lot.
>

Wow, that's good luck - things usually break when I fiddle with linker
scripts! ;)

If your original script was one supplied as a WinARM sample, then
perhaps Martin might consider making this change to the distribution.
However, there may have been a good reason for it being the way it was.

Clifford

Clifford Slocombe wrote:
> Min Ge wrote:
>
>>
>> I have tried. It works. Thanks a lot.
>>
>
> Wow, that's good luck - things usually break when I fiddle with linker
> scripts! ;)
>
> If your original script was one supplied as a WinARM sample, then
> perhaps Martin might consider making this change to the distribution.
> However, there may have been a good reason for it being the way it was.
>
> Clifford

Hi Clifford,

I am so sad of telling you. The file of "AT91SAM7S256-RAM.ld" I modified
does not work properly all the time. Sometimes it can not run to the
breakpoint I set. I tried on the original RAM file on the same code, it
owrks.
Must be something I have not modified correctly yet. I will check that
later and then tell you.

Thanks.

Min Ge

Min Ge wrote:
> Hi Clifford,
>
> I am so sad of telling you. The file of "AT91SAM7S256-RAM.ld" I modified
> does not work properly all the time. Sometimes it can not run to the
> breakpoint I set. I tried on the original RAM file on the same code, it
> owrks.
> Must be something I have not modified correctly yet. I will check that
> later and then tell you.

Possibly the stack allocation is too small. If this overflows it will
corrupt the code/data space. In the previous script the stack was
probably set much higher.

Clifford