Kai Liu

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

9 years, 10 months ago.

Over 32KB RAM usage?

I have tried both programs, UDPSocket_Helloworld & TCPSocket_Helloworld.

Both programs has used up to 35KB RAM. I knew LPC1768 has 64KB, but it is splitted into 2 32KB RAM areas. Since I have no idea how the code is arranged from online compiler.

Does anyone know about its RAM arrangement?

Question relating to:

Last updated: 30 Apr 2020

4 Answers

Andy A
9 years, 10 months ago.

The second 32k block is used by the Ethernet and CAN libraries as data buffers. Since these buffers are in that second block of RAM they don't get in the way of the normal user memory and unless you want to dig into it you don't need to worry about how this happens. However they do get counted when calculating RAM usage and so seeing a memory usage of over 32k (and over 100%) is normal when using the ethernet interface.

Diego Garcia
9 years, 6 months ago.

Hi all, I compiled UDPEchoServer code on the online compiler without problem, but when I export and try to compile on LPCxpresso 7.7.2 I get an overflowed region RamLoc32 error as if it trying to fit all RAM in the first 32kb of RAM. Does anyone know why this happen?

linucos linucos
9 years, 6 months ago.

Can online compiler compile you codes well?

Yes, I imported the "UDP Echo Server" code from de mbed site as is it, without modification to on-line compiler and works fine, but when I export it to my LPCXpresso stand-alone compiled IDE have a "RamLoc32" overflowed error

posted by Diego Garcia 21 May 2015
gary belcaster
9 years, 6 months ago.

so can we access that second block for routine use ??

Yes. With some limitations. You can use it for globals and (presumably) static variable. However I'm not sure if it's possible to use it for variables on the stack or heap. So its fine for buffers and data storage but not so good for working variables.

It is split into 2 16k sections, AHBSRAM0 and AHBSRAM1. However these are next to each other in memory so if you are careful you can treat them as a single 32k block.

You access them using attribute compiler directives to tell the compiler which ram block to use for a variable.

e.g. to put an array of 4096 floats (4096 * 4 = 16k) into AHBSRAM0 use the line:

float bigBuffer[4096] __attribute__((section("AHBSRAM0")));

You could then use that variable in your code in exactly the same way as any other variable.

Since this is a compiler specific directive your mileage may vary for offline builds.

posted by Andy A 21 May 2015