C Program Memory Layout in Embedded Systems

E

Elctro1

New Member
Hi,
I’ve been learning about the memory layout in C programs for embedded systems, particularly the Text, Data, BSS, Stack, and Heap sections, and how variables are allocated to each.

However, I’m unsure about one key point:
Is this memory layout universal, or does it vary depending on the microcontroller, compiler?

From my understanding, this should be general concept, but the actual placement, sizes, and even the presence of certain sections may differ across platforms. I’d appreciate confirmation if this interpretation is correct
 
Sort by date Sort by votes
There may be similarities in the layouts, but each hardware architecture will have unique features. For example, some devices begin execution at a low address while others use a high address. There are even examples of beginning addresses the are in between low and high. The operation of stack pointers may decrease when putting items onto a stack and increase when removing them. It could also be the reverse.
 
Upvote 0 Downvote
Thanks. I'm trying to understand how compilers assign different variables to memory sections in these architectures:

For 8051 (Harvard): Keil

  • Where do these typically get placed?
    • const variables
    • Global variables
    • Static variables
      Does the compiler automatically put them in .text, .data, .bss, stack or heap based on their type/size?
For ARM Cortex-M : GCC
Same questions:
  • Where do const, global and static variables usually go?
  • Is the assignment to .text, .data, .bss, stack or heap automatic based on variable type?
Is this mainly controlled by the compiler, or do we need to specify locations manually?
 
Upvote 0 Downvote
Generally, allocation of memory areas is automatic, unless you specifically override it.
If you are using an assembler, they you may have to define some areas.

None of the compilers I've used in the last few years have needed any manual settings for different data areas, though you can override such as the default heap size etc.

In the ones I use, static and const share the same area as global, the difference is in how the compiler treats them or permits access during compilation.

Local variables are usually on the stack. Heap is memory allocated at run-time, eg. malloc()

.bss is the "data" portion of the executable file, constants before they are copied to RAM variables.
.text is, rather unintuitively, the executable / compiled / machine code section.
 
Upvote 0 Downvote
It's pretty difficult to determine.. Most here use Pic's and each structure has a different method.

The stack and heap normally reside in the top of the memory. The 8051 has program AND data space at the same address albeit separated. Pic also has ROM and RAM but addressed differently.

Constants are normally in code space. Unless you specify differently.
Then register variables are normally located in the fast access area if available.

Then Data is split into two, Idata and Udata.

Locals are Udata along with any globals you didn't initialize ( these will be linked in if used )
static's and Volatile will be in the Idata "protected" area. ( these will be linked in for definite )

However linkers are compiler specific not structure specific. so without the linker documentation. Christ knows.

If you have the old MPLABC18 they produce a linker script, you can alter this .

Here is a pic18f4620 linker script.
Code: 
LIBPATH .

FILES c018i.o
FILES clib.lib
FILES p18f4620.lib

CODEPAGE   NAME=page       START=0x0               END=0xFFFF
CODEPAGE   NAME=idlocs     START=0x200000          END=0x200007       PROTECTED
CODEPAGE   NAME=config     START=0x300000          END=0x30000D       PROTECTED
CODEPAGE   NAME=devid      START=0x3FFFFE          END=0x3FFFFF       PROTECTED
CODEPAGE   NAME=eedata     START=0xF00000          END=0xF003FF       PROTECTED

ACCESSBANK NAME=accessram  START=0x0            END=0x7F
DATABANK   NAME=gpr0       START=0x80           END=0xFF
DATABANK   NAME=gpr1       START=0x100          END=0x1FF
DATABANK   NAME=gpr2       START=0x200          END=0x2FF
DATABANK   NAME=gpr3       START=0x300          END=0x3FF
DATABANK   NAME=big           START=0x400          END=0xBFF

DATABANK   NAME=gpr12      START=0xC00          END=0xCFF
DATABANK   NAME=gpr13      START=0xD00          END=0xDFF
DATABANK   NAME=gpr14      START=0xE00          END=0xEFF
DATABANK   NAME=gpr15      START=0xF00          END=0xF7F
ACCESSBANK NAME=accesssfr  START=0xF80          END=0xFFF          PROTECTED

SECTION    NAME=CONFIG     ROM=config
SECTION       NAME=buffer_scn RAM=big   

STACK SIZE=0x100 RAM=gpr14

It was edited by me to to combine 4 databanks for a large data area.. a screen buffer.
Notice the stack is the next to last databank.. the last portion is the fastram
 
Upvote 0 Downvote
You must log in or register to reply here.

Similar threads

J
  • Question Question
Do Embedded Systems log faults with key switch off ?
Replies
1
Views
3K
ahsrabrifat
A
J
  • Question Question
What is the benefit of performing memory leakage test using QAC or PC Lint or any static analysis tool?
Replies
1
Views
1K
jani12
J
@
Need help in programming Zigbee in ESP32C6
Replies
8
Views
478
be80be
Problem with counter in swordfish
Replies
17
Views
495
be80be
P
  • Question Question
PIC KIT 3 not able to program dsPIC
2
Replies
32
Views
4K
be80be
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…