Linker Command Files - Getting Segments to Concatenate

[mjkaras]

It is typical on a Coldfire setup, particularly when using an embedded part with both internal FLASH and RAM, to want the memory layout definition in the LCF to be such that the read only parts and the read/write parts to be separate and mapped to separate regions according to memory type and usage.

I like being able to test code using the internal RAM only mode but since RAM is small and of limited quantity it would be nice to get the Linker to simply append the read/write data sections directly after the read only code and constants section. I have read the Linker on-line documentation and cannot figure out just how this would be done. Of course there is also the desire to keep the areas separate for the FLASH usage mode and also not have there be a difference in the source code itself. Below is the first part of my RAM mode linker command file (.lcf). How would this be changed so that the "userram" part of the memory map is specified to start directly after the end of the "code" part and not have to hard specify the ORIGIN of "userram" to 0x20006000 as shown below?

Thanks
Michael Karas

# Sample Linker Command File for CodeWarrior for ColdFire


# Memory ranges   

MEMORY {
   vectorram   (RWX) : ORIGIN = 0x20000000, LENGTH = 0x00000500
   code        (RX)  : ORIGIN = 0x20000500, LENGTH = 0
   userram     (RWX) : ORIGIN = 0x20006000, LENGTH = 0
}

SECTIONS {
 
# Heap and Stack sizes definition
    ___heap_size      = 0x400;
    ___stack_size     = 0x400;

# MCF5213 Derivative Memory map definitions from linker command files:
# __IPSBAR, __RAMBAR, __RAMBAR_SIZE, __FLASHBAR, __FLASHBAR_SIZE linker
# symbols must be defined in the linker command file.

# Memory Mapped Registers (IPSBAR= 0x40000000)
   ___IPSBAR         = 0x40000000;

[mjkaras]

Some Added Information

I am using the CodeWarrior Development Studio Version 6.4 Build 6
My target platform is the Coldfire MCF5213 device with 256K FLASH / 32K RAM

Thanks
Michael Karas

[mjkaras]

Please note that I am already aware of the linker's supposed capability to support the AFTER clause in the specification of the memory layout. It would seem logical that simply changing the beginning part of the linker command file to something like the following would work (& note that I have tried this several times):

# Memory ranges   

MEMORY {
   vectorram   (RWX) : ORIGIN = 0x20000000, LENGTH = 0x00000500
   code        (RX)  : ORIGIN = AFTER(vectorram), LENGTH = 0
   userram     (RWX) : ORIGIN = AFTER(code), LENGTH = 0
}

SECTIONS {
 
# Heap and Stack sizes definition
    ___heap_size      = 0x400;
    ___stack_size     = 0x400;

The above does not work for some reason and the Linker outputs a series of error messages that appears to imply that either the AFTER clause is useless or there is some other thing that needs to be done to get it to work correctly.

Link Error   : Cannot write into segment code
The section .code appears in an AFTER clause
Link Error   : Cannot write into segment vectorram
The section .vectorram appears in an AFTER clause
Link Error   : Cannot write into segment vectorram
The section .vectors appears in an AFTER clause
Link Error   : Cannot write into segment code
The section .text appears in an AFTER clause
Link failed.

Any help on this appreciated.
Thanks
Michael Karas

[CrasyCat]

Hello

I can use the AFTER command in a linker command file without any issue.

There might be something wrong with your project.

I would recommend you to submit a service request for that.

Click here to submit a service request.

Make sure to attach a reproducible project and installed product information to the service request.
To generate the required information:
- Start CodeWarrior
- Open the project
- Select "Help" -> "Pack and Go" and follow instructions on the screen.

Attach the generated .zip file to the SR.

CrasyCat

[mjkaras]

Hi,

Cool cat avitar.   =^..^=

Did you use the AFTER in the MEMORY definition section with the Length set to a value as opposed to zero to permit the auto size feature?

One thing I have learned is that using Length=0 has a problematic issue in that it keeps the linker from being able to compute and check for segment overflows. Particulary with the RAM build configuration it is a pain to have to compile link and then look in the MAP file each time to see if there has been segment overflow.

I am in the process of trying another approach to this issue. For the RAM configuration mode I am trying out a scheme to place all of the compiled sections into a single RAM memory section. Like this:

# Sample Linker Command File for CodeWarrior for ColdFire


# Memory ranges   

MEMORY {
   vectorram   (RWX) : ORIGIN = 0x20000000, LENGTH = 0x00000500
   code        (RWX)  : ORIGIN = 0x20000500, LENGTH = 0x00007B00
##   userram     (RWX) : ORIGIN = AFTER(code), LENGTH = 0
}

SECTIONS {
 
# Heap and Stack sizes definition
    ___heap_size      = 0x400;
    ___stack_size     = 0x400;

# MCF5213 Derivative Memory map definitions from linker command files:
# __IPSBAR, __RAMBAR, __RAMBAR_SIZE, __FLASHBAR, __FLASHBAR_SIZE linker
# symbols must be defined in the linker command file.

# Memory Mapped Registers (IPSBAR= 0x40000000)
   ___IPSBAR         = 0x40000000;

# 32 Kbytes Internal SRAM
   ___RAMBAR         = 0x20000000;
   ___RAMBAR_SIZE    = 0x00008000;

# 256 KByte Internal Flash Memory
   ___FLASHBAR       = 0x00000000;
   ___FLASHBAR_SIZE  = 0x00040000;

##  .userram      : {} > userram       
  .code        : {} > code       
  .vectorram    : {} > vectorram       
              
    .vectors :
    {
        vectors.s (.text)   
        . = ALIGN (0x4);       
    } >> vectorram
   
    .text :
    {
        *(.text)
        . = ALIGN (0x4);
        *(.rodata)
        . = ALIGN (0x4);       
##    } >> code
##
##
##    .data :
##    { 
        ___DATA_ROM = .;
        ___DATA_RAM = .;
        . = ALIGN(0x4);
        *(.exception)   
        . = ALIGN(0x4);   
        __exception_table_start__ = .;
        EXCEPTION
        __exception_table_end__ = .;
       
        ___sinit__ = .;
        STATICINIT
        __START_DATA = .;

        *(.data)
        . = ALIGN (0x4);
        __END_DATA = .;

        __START_SDATA = .;
        *(.sdata)
        . = ALIGN (0x4);
        __END_SDATA = .;

        ___DATA_END = .;
        __SDA_BASE = .;
        . = ALIGN (0x4);       
##    } >> userram
##
##    .bss :
##    {
        ___BSS_START = .;
        __START_SBSS = .;
        *(.sbss)
        . = ALIGN (0x4);
        *(SCOMMON)
        __END_SBSS = .;

        __START_BSS = .;
        *(.bss)
        . = ALIGN (0x4);
        *(COMMON)
        __END_BSS = .;
        ___BSS_END = .;

        . = ALIGN(0x4);
##    } >> userram
##
##    .custom :
##    {
        ___HEAP_START    = .;
        ___heap_addr    = ___HEAP_START;
        ___HEAP_END        = ___HEAP_START + ___heap_size;
        ___SP_END        = ___HEAP_END;
        ___SP_INIT        = ___SP_END + ___stack_size;

        . = ALIGN (0x4);
##    } >> userram
    } >> code
     
    ___VECTOR_RAM        = ADDR(.vectorram);

    __SP_INIT        = ___SP_INIT;

    __S_romp         = 0x0;

}

I commented out lines that used to specify section splits with the ## symbols.
Mike Karas

[CrasyCat]

Hello

Yes I did create a project from a stationery and I modified the MEMORY block as follows (AFTER command with length)

MEMORY {
 TEXT (RX) : ORIGIN = 0x00030000, LENGTH = 0x6000 # using External DRAM
 DATA (RW) : ORIGIN = AFTER(TEXT), LENGTH = 0x1000
}

The trouble you are facing seems to be related to your application.

I would recommend you to log an Service request through our on-line support web site to get a support engineer to look at that.

Do not forget to attach a reproducible project to the SR.

CrasyCat