LPC1768: binary file is 524Mbyte

[lpcware]

Content originally posted in LPCWare by stevenQS on Mon Dec 13 05:49:42 MST 2010
hi LPC gurus!

When creating a binary from the .afx file, we get a .bin of 524MEGAbyte.
We assume this has to do with the linker file because we added an extra RAM section, according to http://support.code-red-tech.com/CodeRedWiki/PlacingData.

We want to allocate memory in the RamAHB32 section.

* device: LPC1768
* debugger: LPCexpresso
* suite: Red Suite 3.4.6, 256K license

Linker memory description:

MEMORY
{
  /* Define each memory region */
  MFlash512 (rx) : ORIGIN = 0x00000, LENGTH = 0x80000 /* 512k */
  RamLoc32 (rwx) : ORIGIN = 0x10000000, LENGTH = 0x8000 /* 32k */
  RamAHB32 (rwx) : ORIGIN = 0x2007c000, LENGTH = 0x8000 /* 32k */
  CANAccFilterRAM (rwx) : ORIGIN = 0x40038000, LENGTH = 0x800 /* 2k */

}

Linker description:

...
.AHBsection :
    {
        *(.AHBsection)
    } > RamAHB32
...

in the code:

__attribute__ ((section(".AHBsection"))) unsigned char dataset0[4096*2]; //2 bytes per value (signed short)
__attribute__ ((section(".AHBsection"))) unsigned char dataset1[4096*2]; //2 bytes per value (signed short)

Running the debugger works fine but generating a binary yields the large file. It has to be related with the AHB section because 0x2007c000 = 524Mbyte. Is the linker trying to initialize all memory regions up to 0x2007c000 as FLASH code? Or how do you explicitly tell the linker this AHB section is RAM data and not FLASH code.

Thank you!
Steven

Original Attachment has been moved to: 1100907_LPCXpresso.zip

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Tue Dec 14 08:08:38 MST 2010
You might want to take a look at LPCXpresso 3.6.0, which we have just released:

http://knowledgebase.nxp.com/showthread.php?t=909

The enhanced managed linker scripts mechanism included in this release makes placing data in the second RAM bank much easier. More information on this at:

http://support.code-red-tech.com/CodeRedWiki/EnhancedManagedLinkScripts

Regards,
CodeRedSupport

[lpcware]

Content originally posted in LPCWare by stevenQS on Mon Dec 13 08:09:12 MST 2010
That solved the issue!
Thank you for the fast and clear response.

Mind: the section had to be declared after the .bss section or else it didn't work.

/* zero initialized data */
        .bss :
{
_bss = .;
*(.bss*)
*(COMMON)
_ebss = .;
} > RamLoc32

.AHBsection (NOLOAD) :
        {
            *(.AHBsection)
        } > RamAHB32

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Mon Dec 13 06:09:25 MST 2010
A binary file contains no address information, only binary data. Therefore, by definition, it cannot contain 'holes', so it has to contain data for every address between your lowest loadable address and your highest loadable address.

You have defined your AHBSection to contain loadable data, therefore you lowest address is 0x0 and your highest is 0x2008000. The tool therefor has no option but to create a binary file of that size...

To fix this, you need to ensure you AHBsection is not loadable:

.AHBsection (NOLOAD):     
{         
      *(.AHBsection)    
} > RamAHB32