Skip to content
BoKSA

Memory Systems

Memory Systems

Introduction

Memory holds your program, variables, stack, heap, and memory-mapped peripheral registers. On embedded targets, RAM is scarce and non-volatile storage (flash, EEPROM) has endurance limits. Understanding addressing, memory maps, and decode logic explains linker errors, hard faults on bad pointers, and why 0x40000000 might be GPIO on ARM.

Types of memory

Type Volatile? Typical use Embedded note
SRAM Yes Stack, heap, buffers Fast, limited size
DRAM Yes Main RAM on Linux SBCs Needs refresh controller
Flash No Program storage Erase in sectors; wear limits
EEPROM / FRAM No Calibration, config Byte-erasable (EEPROM)
ROM / mask ROM No Bootloader, constants Factory programmed
Registers Yes Peripheral control Part of memory map

Addressing

Each byte (or word, depending on architecture) has an address — a number the CPU places on the address bus.

Word size vs address space:

  • 32-bit CPU → up to 4 GB addressable (2³² bytes) if flat.
  • Many MCUs use only part of that space for on-chip resources.

Endianness

Multi-byte values stored least-significant byte first (little-endian, ARM default) or MSB first (big-endian). See Data representation.

Memory map

A memory map assigns address ranges to devices:

1
2
3
4
5
6
Example (conceptual Cortex-M style):

0x0000_0000  Flash / vector table
0x2000_0000  SRAM
0x4000_0000  Peripheral bridge (GPIO, UART, timers...)
0xE000_0000  System control (NVIC, SysTick, debug)

Your MCU datasheet memory map is authoritative — never guess peripheral base addresses.

Address decoding

When the CPU drives an address, decode logic asserts chip select on exactly one target (RAM chip, flash, UART register block).

Concept Purpose
Chip select (CS) Enable one device on shared bus
Address lines A0–An Select location within device
Glue logic NAND gates, decoders (74HC138) for CS generation

External parallel SRAM/flash on expansion boards uses decoding; on-chip peripherals are decoded inside the MCU.

ROM, RAM, and boot flow

  1. Reset → CPU reads start address from vector table (often flash).
  2. Startup code copies .data from flash to RAM, zeroes .bss.
  3. main runs from flash or RAM depending on linker script.

Execute-in-place (XIP): code runs directly from flash — slower than RAM but saves SRAM.

Memory protection

Mechanism Where
MPU (Memory Protection Unit) Many Cortex-M3+ — region permissions
MMU (Memory Management Unit) Application processors with OS — virtual memory
Watchdog + stack canaries Detect overflow in firmware

Stack overflow into heap causes subtle bugs — set stack size in linker script with margin.

External storage: SAN vs NAS (context)

For embedded Linux gateways connecting to datacenter storage:

SAN NAS
Access Block-level (iSCSI, FC) File-level (NFS, SMB)
Appears as Disk to OS Network file share
Typical use Databases, VMs Shared files, backups

Relevant when your device uploads logs or firmware images to corporate infrastructure — not on bare-metal MCU projects.

Relevant topics

Starting points

  1. Print &main, stack pointer, and a global from your firmware — map to linker regions.
  2. Open MCU reference manual memory map — label flash, SRAM, one peripheral.
  3. Trigger a hard fault with a bad pointer — read CFSR/BFAR in debugger.
  4. Review linker script MEMORY and SECTIONS blocks.

Focus points

  • Memory map errors cause hard faults — verify base addresses in headers.
  • Flash wear — do not log to flash every millisecond.
  • Alignment — unaligned 32-bit access may fault on some cores.
  • DMA buffers often need alignment and cache coherency on Cortex-A class.

Key points

  • SRAM, flash, and registers serve different roles with different rules.
  • The memory map assigns address ranges to RAM, code, and peripherals.
  • Address decoding selects which chip or peripheral responds to a bus cycle.
  • Linker scripts and startup code place code and data in the correct regions at boot.