LCF & Memory maps, can anyone explain this?

[FridgeFreezer]

Micro is MCF52259, CodeWarrior 7.2, C code on our own board (based on M52259EVB).

I've been struggling with getting a modified version of the Freescale MCF5225x USB Bootloader running, our version reads data directly from an external SPI Flash chip and burns it to flash, but we trip over when jumping back to the main code for some reason and the debugger has showed the code wandering off creating variables at addresses outside of the addressable RAM (eg 0x20014000) for no obvious reason, and reading back different values from flash than are actually in there.

I have used the modified .lcf from the example code but expanded the sram size to allow the full 64k of the M52259 to be used.

There are a few things confusing me about the setup though, and LCF's seem to be very poorly documented (if the results of my searches round this forum are anything to go by, most people who try to work with them https://community.freescale.com/message/83256#83256 / lack of info). Although the basics are described in the "Targeting_Coldfire" manual, they seem to assume a level of prior knowledge of the whole thing (a fault with a lot of documentation in fact) which is infuriating.

The original lcf (mcf52259EVB_FLASH.lcf) is:

MEMORY{ vectorflash(RX) : ORIGIN = 0x00000000, LENGTH = 0x00000418 bootcode    (RX): ORIGIN = 0x00000420, LENGTH = 0x00003BE0    #flash   (RX)   : ORIGIN = 0x00000420, LENGTH = 0x0007FC00    flash   (RX)   : ORIGIN = 0x00004010, LENGTH = 0x0007BFF0 vectorram(RWX) : ORIGIN = 0x20000000, LENGTH = 0x00000400 sram (RWX)  : ORIGIN = 0x20000400, LENGTH = 0x00005C00 ipsbar  (RWX)  : ORIGIN = 0x40000000, LENGTH = 0x0}SECTIONS { .ipsbar  : {} > ipsbar     .vectorflash : {  mcf5225x_vectors.s (.text)    } > vectorflash      .bootcode: {   ___Boot_START   = .;    . = ALIGN (0x4);  ___Boot_END     =.;  } > bootcode .flash : {  *(.text)  .       = ALIGN(0x10);  *(.rodata)  ___DATA_ROM    = .;    } > flash        .data : AT(___DATA_ROM)  {  ___DATA_RAM    = . ;        *(.exception)   .              = ALIGN(0x10);   __exception_table_start__ = .;     EXCEPTION  __exception_table_end__   = .;  ___sinit__     = .;     STATICINIT        *(.data)        *(.relocate_code)  .              = ALIGN (0x10);  ___DATA_END    = .;  __START_SDATA  = .;        *(.sdata)  .              = ALIGN (0x10);  __END_SDATA    = .;  __SDA_BASE     = .;  .              = ALIGN(0x10); } > sram .bss : {  . = ALIGN(0x10);  __START_SBSS = .;  *(.sbss)  *(SCOMMON)  __END_SBSS   = .;  . = ALIGN(0x10);  __START_BSS  = .;  *(.bss)  *(COMMON)  __END_BSS    = .;         ___BSS_START = __START_SBSS;        ___BSS_END   = __END_BSS;        . = ALIGN(0x10); } >> sram ___FLASH  = ADDR(.vectorflash); ___FLASH_SIZE = 0x00080000; ___SRAM  = 0x20000400; ___SRAM_SIZE = 0x00005A00;  ___VECTOR_RAM = 0x20000000; ___IPSBAR  = ADDR(.ipsbar);    ___SP_SIZE      = 0x0800; ___HEAP_START = .; ___HEAP_END  = ___SRAM + ___SRAM_SIZE - ___SP_SIZE; ___SP_END  = ___HEAP_END; ___SP_INIT  = ___SP_END + ___SP_SIZE;    ___heap_addr  = ___HEAP_START; ___heap_size  = ___HEAP_END - ___HEAP_START ; __SP_INIT   = ___SP_INIT;}

In our .LCF we have:

MEMORY{ vectorflash(RX) : ORIGIN = 0x00000000, LENGTH = 0x00000418 bootcode    (RX): ORIGIN = 0x00000420, LENGTH = 0x00003BE0        flash   (RX)   : ORIGIN = 0x00004010, LENGTH = 0x0007BFF0 vectorram(RWX) : ORIGIN = 0x20000000, LENGTH = 0x00000400 sram (RWX)  : ORIGIN = 0x20000400, LENGTH = 0x0000FC00 // Full 64k (FC00+400) ipsbar  (RWX)  : ORIGIN = 0x40000000, LENGTH = 0x0}

 ___FLASH  = ADDR(.vectorflash); ___FLASH_SIZE = 0x00080000; ___SRAM   = 0x20000400; ___SRAM_SIZE = 0x0000FC00; ___VECTOR_RAM = 0x20000000; ___IPSBAR  = ADDR(.ipsbar);    ___SP_SIZE      = 0x2000; // 8k ___HEAP_START = .; // Store after sections above (.bss) ___HEAP_END  = ___SRAM + ___SRAM_SIZE - ___SP_SIZE; ___SP_END  = ___HEAP_END; ___SP_INIT  = ___SP_END + ___SP_SIZE;    ___heap_addr  = ___HEAP_START; ___heap_size  = ___HEAP_END - ___HEAP_START ; __SP_INIT   = ___SP_INIT;  # http://forums.freescale.com/freescale/attachments/freescale/CWCFCOMM/3435/1/TN268.pdf ___mem_limit = ___HEAP_END; ___stack_safety = 16;

In our .xMAP file we see:

#>20004E0C          __END_BSS (linker command file)#>20000520          ___BSS_START (linker command file)#>20004E0C          ___BSS_END (linker command file)#>00000000          ___FLASH (linker command file)#>00080000          ___FLASH_SIZE (linker command file)#>20000400          ___SRAM (linker command file)#>0000FC00          ___SRAM_SIZE (linker command file)#>20000000          ___VECTOR_RAM (linker command file)#>40000000          ___IPSBAR (linker command file)#>00002000          ___SP_SIZE (linker command file)#>20004E10          ___HEAP_START (linker command file)#>2000E000          ___HEAP_END (linker command file)#>2000E000          ___SP_END (linker command file)#>20010000          ___SP_INIT (linker command file)#>20004E10          ___heap_addr (linker command file)#>000091F0          ___heap_size (linker command file)#>20010000          __SP_INIT (linker command file)#>2000E000          ___mem_limit (linker command file)#>00000010          ___stack_safety (linker command file)# Memory map:  v_addr   p_addr   size     name  00004000 00004000 00000004 .abs__UserEntry abs__UserEntry  00004004 00004004 00000004 .abs__UserEntry2 abs__UserEntry2  00000000 00000000 00000418 .vectorflash vectorflash  00000420 00000420 00001700 .bootcode  bootcode  00004010 00004010 0003EBEC .flash     flash  20000000 20000000 00000400            vectorram  20000400 00042BFC 00000120 .data      sram // <<<Why is the p_addr different?  20000520 20000520 000048F0 .bss       sram  40000000 40000000 00000000 .ipsbar    ipsbar

So, the things I don't fully understand are:

Why do Freescale define:

sram (RWX)  : ORIGIN = 0x20000400, LENGTH = 0x00005C00

And then:

___SRAM_SIZE = 0x00005A00;

Especially on a micro with 64k of ram? Does this mean that the stack/heap are allocated outside of the __SRAM range (if so, how is the memory limit imposed?) and that I should define a smaller SRAM size?

I can find no documentation on the #Memory map section, or what v_addr/p_addr mean, and I am keen to understand what this line means:

20000400 00042BFC 00000120 .data      sram // <<<Why is the p_addr different?

As 0x00042BFC seems like a wrong value no matter what it means - if it's an address, a size or an offset from somewhere it doesn't make any sense to me.

Another question is that I'm not using malloc() at all, so do I still need HEAP or can I remove it?

Something I came across while investigating is the linker file from the M52259EVB when using the MRAM on the board, they use a different style of defining the stack/heap, and place it inside the sram (>ram), so again I would like to understand what they're doing and why, and if one way is better than the other?

(mcf52259EVB_MRAM.lcf)

#/*# * File:  mram.lcf# * Purpose: Linker file for the M52259EVB# *# * Notes:  Project running in external MRAM# *# */MEMORY {    rom      (RX) : ORIGIN = 0x00000000,  LENGTH = 0x00080000    ram      (RW) : ORIGIN = 0x20000000,  LENGTH = 0x00010000    vector_mram (RW) : ORIGIN = 0x80000000,  LENGTH = 0x00000418    mram     (RWX): ORIGIN = 0x80000420,  LENGTH = 0x0007FBE0}SECTIONS {    ___IPSBAR           = 0x40000000;    ___MRAM             = 0x80000000;    ___MRAM_SIZE        = (512 * 1024);    ___SRAM             = 0x20000000;    ___SRAM_SIZE        = (64 * 1024);    ___FLASH            = 0x00000000;    ___FLASH_SIZE       = (256 * 1024);   .vectors : {  . = ALIGN (0x4); } > vector_mram    ___VECTOR_RAM   = ADDR(.vectors);        .text :    {        .               = ALIGN(0x10);        mcf5225x_vectors.s (.text)        *(.text)        *(.rodata)         .              = ALIGN(0x10);        ___DATA_ROM     = .;    } > mram    .data_bss : AT(___DATA_ROM)    {        ___DATA_RAM     = .;        *(.data)        *(.sdata)        ___DATA_END     = .;        .               = ALIGN(0x10);        ___BSS_START    = .;        *(.sbss)        *(SCOMMON)        *(.bss)        *(COMMON)        ___BSS_END      = .;        /* Buffer descriptor base address           shall be aligned to 512 byte boundary.           Size shall be 512 bytes. */        .    = ALIGN(512);        __BDT_BASE  = .;        .               = . + 512;        __BDT_END       = .;                 .               = ALIGN(0x10);        ___SP_END       = .;        .               = . + (0x800);        ___SP_INIT      = .;        .               = . + (4);        ___HEAP_START   = .;        ___HEAP_END     = ___SRAM + ___SRAM_SIZE;    } > ram ___heap_addr = ___HEAP_START; ___heap_size = (___HEAP_END - ___HEAP_START - 4) & 0x0FFFFF00; ___STACK_SIZE = ___SP_INIT - ___SP_END;}

Any help gratefully appreciated!

[FridgeFreezer]

Well I just answered a bit of my question (why do I always find new search results just *after* I hit "post"?)

v_addr stands for virtual address , p_addr stands for physical address.Usually p_addr is similar to v_addr. Only case where they can differ is if you decide to copy data (or code) from ROM to RAM at startup. If you wish to do that you have to adjust your .lcf file.If you are using CodeWarrrior for Coldfire V6.3, refer to {Install\Help\PDF\ColdFire_Build_Tools_Reference.pdf, Chapter "Coldfire Linker", section "LCF Syntax" -> "ROM-RAM Copying" for more information.

 https://community.freescale.com/message/23834#23834

[j___]

2011 post, now in 2016 I was looking for the same information, "What is v_addr & p_addr." Luckily I found your post.

I really can NOT believe how POORLY the documentation for the map file and the linker control file is. Texas Instruments' coverage of those topics is just as dismal.

Also, cannot get a global variable in the LCF to work as documented (oh poorly documented).

Thanks for this forum post. 5 years later and still being referenced.

Jim

[j___]

Oh and I am working with CW 8.3 on the DSP56F8345.

[FridgeFreezer]

Well I've traced part of the problem to errors with writing the CFM, so I've started a new thread on that subject here:

New thread in Coldfire forum (all help gratefully received!)

Still interested to hear any answers/opinions on my other questions