LPC1517 RAM map

[lpcware]

Content originally posted in LPCWare by gwlindberg on Wed Dec 02 17:43:28 MST 2015
I'm working on a LPC1517 project and in the project properties that are 3 RAM regions defined, Ram0_4, Ram1_4, & Ram2_4. Each of which is 4096 bytes long.  I cannot find any documentation on what each of the regions is used for, can anyone explain?

[lpcware]

Content originally posted in LPCWare by gwlindberg on Thu Dec 10 10:21:24 MST 2015
Here's what I ended up doing.

First I merged the 2nd and third Ram sections, but left them in the same order as originally.

Next I added three linker scripts to move the .data, COMMON, & .bss regions to the 2nd Ram section.

Here are the scripts:
main_bss_section.ldt

Remove COMMON region from here.

    /* MAIN BSS SECTION */
    .bss : ALIGN(${bss_align})
    {
        _bss = .;
<#include "main_bss.ldt">
        . = ALIGN(${bss_align}) ;
        _ebss = .;
        PROVIDE(end = .);
    } > ${DATA}

data.ldt

<#global skipCompare=true> 

<#if memory.alias=="RAM2">
        *(.data*)
</#if>

bss.ldt

<#if memory.alias=="RAM2">
        *(COMMON)
        *(.bss*)
</#if>

I then changed the stack offset under Project->Properties->Managed Linker Script to 288. One of the pages about ram usage said that the IAP code would use 32 bytes for the stack and another 256 bytes for data, so I dropped the stack by 288 bytes to be safe.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Dec 10 02:42:01 MST 2015
So the simplest mechanism would be to carry out the following in the memory configuration Editor:

[list=1]
  [*]Merge the second and third banks of RAM together
  [*]Reorder the RAM banks so that the merged 2nd/3rd block is list first, before the originally default block.
[/list]

You will then end up with data/bss/heap/stack in the merged 2nd/3rd block - as it is listed first.

And the original default block then remains unused, the top 32 bytes of which will be used by the IAP routines (check the user manual for details of this).

Alternatively if you want to put the heap/stack into the originally default block, you can do this by defining a couple of symbols either on the command line (as per the FAQ I pointed you at several posts ago) or in a freemarker linker script template. I've attached an example that does this using a linker script template:

stack_heap.ldt

<#global skipCompare=true>

    __user_heap_base = __base_RAM2;
    __user_stack_top = __top_RAM2 - 32;

<#include "heap.ldt">
<#include "stack.ldt">

_actual${heap_symbol} = ABSOLUTE (${heap_symbol});
_actual_vStackTop  = ABSOLUTE (_vStackTop);

Note the subtraction of 32 in the stack setup to allow space for the IAP routines RAM usage.

When executed the attached example project (a modification of the previous example), prints out:

Initial stack pointer : 2000fe0
Current stack pointer : 2000fb8
Start of heap : 2000000
var0_x  200100c 0
var0_y  2001000 1
var1_x  2001014 0
var1_y  2001004 75
var2_x  2001018 0
var2_y  2001008 42

showing the placement of heap, stack and variables as required.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by gwlindberg on Wed Dec 09 10:58:34 MST 2015
In reply to miccio,

So for the CAN api, the only confusing parts is that the memory area that is passed in is checked to be at least 4 times the size returned as what is needed.

[lpcware]

Content originally posted in LPCWare by gwlindberg on Wed Dec 09 10:46:15 MST 2015
Ok, to answer your first question, Initially I made the assumption that with three distinct banks of ram they were used for the three different ram allocations, data/bss, heap, and stack. I didn't realize that the only one that was used was the first bank of the three. So given my new found understanding (hopefully reasonably accurate) what I would like to accomplish is to put the heap & stack into one of the ram blocks, put the data, common, & bss regions into the other two blocks and then not have anything in the data area used by the IAP flash update code, as we may need to use it.

I guess that this also brings up the question, where is common finally put, if not in the bss region, is it combined into the data region, and therefore not initialized to anything.

It seems to me that the default memory arrangement would leave the top of the stack in the memory that is used by the IAP flash update code.

I could certainly combine the second and third ram sections together into one, and then move the data, common & bss regions to that section. And then limit the stack so that the top of it was less than the amount of memory used by the IAP code.

So, like this?

data.ldt

<#global skipCompare=true> 

<#if memory.alias=="RAM2">
        *(.data*)
< /#if>

bss.ldt

<#if memory.alias=="RAM2">
        *(.bss*)
< /#if>

At this point I would need to know how I set the starting point of the stack so that it starts below the data needed by the IAP code.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Dec 09 03:51:00 MST 2015
Can you explain exactly what you are trying to achieve here??

I'm not sure of the point of moving all of the data/bss into another RAM bank. The simplest way to do that would be to simply reorder the banks of memory in the memory configuration editor. And if the aim is to move the heap/stack into a different block to the data/bss, then that can be achieved by just changing their settings.

But if you are just running out of space with the default placement of data/bss/heap/stack in the first RAM bank, then the simplest solution may be for you to just use the memory configuration editor to merge the 3x 4KB RAM banks into 1 single block of 12KB.

There are two things to be aware of if you do this though:

[list=1]
  [*]If you application makes use of the IAP, then the memory used by this will be at the end of the 1st RAM bank, not the 3rd RAM bank (ie 4KB in, not 12KB in). Thus this would likely trash your data.
  [*]The 3 RAM banks are separately enabled/disabled. Thus if you treat them as a single combined 12KB, make sure that your code doesn't try to disable any of them.
[/list]

But if you don't want to merge the RAM banks, one thing that might be useful for you is to move a number of data/bss items into another RAM bank. If you don't want to manually decorate them with the section macros, then the simplest way to do this is to create one or more subdirectories in your project and place the source files contains these data/bss items into these subdirectories.

You can then place the data/bss from the source files in these subdirectories very easily by providing a couple of Freemarker linker script template files:

[u]data.ldt[/u]

<#global skipCompare=true> 

<#if memory.alias=="RAM2">
        *RAM2/*(.data*)
< /#if>
<#if memory.alias=="RAM3">
        *RAM3/*(.data*)
< /#if>
        *(.data.$${memory.alias}*)
        *(.data.$${memory.name}*)

[u]bss.ldt[/u]

<#if memory.alias=="RAM2">
        *RAM2/*(.bss*)
< /#if>
<#if memory.alias=="RAM3">
        *RAM3/*(.bss*)
< /#if>
       *(.bss.$${memory.alias}*)
       *(.bss.$${memory.name}*)

  

[ Note : due to the way the forum display formatter works, I've had to put a space between the "<" and the "/#if>". Remove these if you cut'n'paste the text (as opposed to extract the files in the attached example project.]

Read the Freemarker FAQ for details on what these files are doing:
https://www.lpcware.com/content/faq/lpcxpresso/freemarker-linker-script-templates

Anyway, I've attached a simple example for LPC1517 that shows this being done. The main routine prints the address and the contents of a number of data/bss items located in the different RAM banks:

var0_x  2000004 0
var0_y  2000000 1
var1_x  2001004 0
var1_y  2001000 75
var2_x  2002004 0
var2_y  2002000 42

One other thing to note here that by default, if you declare a variable thus:

int x;

It will actually go into a section called COMMON, rather than into a BSS section.

For relocating such variables into an alternate RAM bank, then you need to force them into a BSS section. To do this, the simplest way is to add the following command line option:

-fno-common

https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html

But the alternative is to actually set the variable to 0 as you define it:

int x = 0;

Note that for information on the memory requirements for ROM code, you need to consult the MCU user manual. Different MCUs have different requirements and different ways of reserving memory - I'm not that familiar with the exact requirements with LPC15xx parts.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by miccio on Tue Dec 08 16:36:03 MST 2015
in regards to your questions about the ROM APIs, you have to declare an array of a specific size (mentioned in the UM for example page 598 - USART API ROM Driver Routines) so each instance will use its own memory block for storing data etc. The size of this block is returned by the get_mem_size() function. The block itself consists of uint32_t start_of_ram_block[RAMBLOCK_H]; so you can have as many as you want, just call them something less obscure and confusing like "uart_mem_block", "i2c_mem_block" etc :)
Moreover, using different ROM APIs can work almost straight out of the box by combining two or more rom_api examples from the lpcopen codebase.

[lpcware]

Content originally posted in LPCWare by gwlindberg on Tue Dec 08 14:30:01 MST 2015
Thanks for the response, it helps a lot.

It would be nice if there was a way to easily move all of the data or bss blocks to one of the other ram blocks, maybe in the freemarker scripts.

Also, is there anywhere that says how much ram needs to be allocated for the various ROM API's? And how do they not write on top of each other? Do I need to reserve space for all of them if I use any of them?

Are there any samples of re-positioning memory or allocation memory for ROM API's for any processor?

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue Dec 08 02:25:00 MST 2015
By default, only the first bank is used - for data, heap and stack:

Data -> BSS -> Heap  -> ... ...  <- Stack

The Heap and Stack do not by default have fixed sizes - they grow towards each other.

There is lots of information on how to move things around in the FAQs, for example:

[list]
  [*]https://www.lpcware.com/content/faq/lpcxpresso/data-different-ram-blocks
  [*]https://www.lpcware.com/content/faq/lpcxpresso/heap-checking-redlib
  [*]https://www.lpcware.com/content/faq/lpcxpresso/freemarker-linker-script-templates
[/list]

With regards to ROM API memory usage see:
[list]
  [*]https://www.lpcware.com/content/faq/lpcxpresso/reserving-ram-rom-drivers
[/list]

You should also look at the section on the Memory Configuration Editor in the LPCXpresso User Guide.

Regards
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by gwlindberg on Mon Dec 07 10:36:38 MST 2015
Thanks for the information on the fix & newer version of LPCXpresso.

Does anyone have any answers on my previous questions on memory usage?

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Mon Dec 07 01:03:52 MST 2015
Fixed back in LPCXpresso IDE v7.9.2: https://www.lpcware.com/content/forum/lpcxpresso-latest-release

Or else you can manually correct if you can't upgrade using the Memory Configuration Editor.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by gwlindberg on Fri Dec 04 16:54:45 MST 2015
I just noticed something else with the configuration of Ram0_4, Ram1_4, & Ram2_4. In the MCU settings dialog of the Properties, Ram2_4 is set up at a starting location of 0x2004000, but in the LPC15xx User manual the SRAM2 region is shown as having a starting address of 0x2002000.  This looks like the actual properties are wrong, and may be partly why I was seeing the system run out of memory at 4K instead of 8K.

Does anybody know why there is this discrepancy in the ram region starting addresses?

[lpcware]

Content originally posted in LPCWare by gwlindberg on Thu Dec 03 10:04:11 MST 2015
I'm using the tool chain installed with LPCXpresso.

I just looked at the map file and Ram0_4 is mentioned in the definition for the stack.
I was getting an error the other day about running out of memory in .bss. Both Ram1_4 and Ram2_4 are listed as .bss and .data, so there should be 8K for them, but I was running out of room at 4K.

So, my question remains, there are three banks, what are they used for:
bss, heap, stack, something else?

How is data distributed between the regions, Initialized variables, uninitialized variables?

I would like to reduce the size of the heap and the stack, as I won't be using much of either of them, but what do I change?

It would be nice if there was some documentation somewhere that explained this.

While I'm at it, where is the memory that is used by the ROM API routines, do I need to specify something somewhere so my application doesn't stomp on it and vice versa?

[lpcware]

Content originally posted in LPCWare by mc on Thu Dec 03 07:09:00 MST 2015
Hi,
LPC1517 has three separate RAM banks. You can use any of these banks according to your need. Which tool chain are you using? You can always check map file to understand memory layout.