The Cortex-M3 memory map is divided into several regions, each with specific access behaviors. The Code region stores program instructions and is readable but not writable. The SRAM region stores data and is readable and writable. The Peripheral region maps to device registers and has read/write access that depends on the peripheral. The Cortex-M3 implements memory protection to prevent access violations.
The Code region stores the program instructions for the Cortex-M3 application. It is located at the bottom of the memory map from addresses 0x00000000 to 0x1FFFFFFF. The Code region is readable so that instruction fetches can read the opcodes during program execution. However, it is not writable by default to protect the integrity of the program code. Any attempt to write to the Code region will result in a memory access violation error.
The processor loads the application binary into the Code region after reset. The exception vectors like the reset handler and interrupt handlers reside at the bottom of the Code region. The main application code is loaded starting from address 0x00000004. During debugging, it is possible to write to the Code region to set software breakpoints. But during normal operation, the Code region remains read-only.
The SRAM region provides general purpose read/write storage for data. It is located above the Code region starting at address 0x20000000. The size of the SRAM region depends on the particular Cortex-M3 chip and can range from 16KB to 256KB. SRAM provides volatile storage that retains its contents as long as power is applied to the chip.
The processor stack is allocated from the SRAM region. The stack grows downwards from the top of SRAM while the heap grows upwards from the bottom. Global and static variables are also stored in SRAM. SRAM contents are lost when the processor is reset. During debugging, SRAM can be inspected and modified by the debugger.
The Peripheral region maps processor accesses to the registers of on-chip peripherals like timers, UARTs, GPIO etc. The location of the Peripheral region is not fixed and varies between Cortex-M3 implementations. It is typically located above the SRAM region. Accesses to the Peripheral region are used to configure, control and get status from the peripherals.
Each peripheral has a range of reserved addresses that map to its registers. Reads and writes to these addresses allow the processor to communicate with the peripherals. The peripherals may have protection mechanisms to prevent unintended accesses to critical registers. For example, some registers may require writing a key value before they can be modified. This prevents accidental writes from altering peripheral behavior.
Private Peripheral Bus
The Private Peripheral Bus (PPB) provides access to peripherals that are unique and private to the Cortex-M3 core. This includes debug components like the Debug Access Port (DAP) and instrumentation trace macrocell. The PPB region is only accessible by the core itself and is not visible to external DMA agents. This prevents external masters from interfering with debug operations.
Debug registers used for halting debug events and breakpoints are located on the PPB. The PPB is also used to access profiling counters in the Cortex-M3 that can measure clock cycles, interrupts and exceptions. Enabling the cycle count will cause a small reduction in maximum clock speed.
Memory Protection Unit
The Memory Protection Unit (MPU) allows configuring access permissions for different memory regions. It supports setting read, write and execute permissions separately for each region. The MPU helps prevent application bugs or errors from corrupting areas like the Code region or memory allocated to other functions.
The MPU divides the memory map into a maximum of 8 regions. Each region is defined by a start and end address, size, access permissions and enable setting. Overlapping regions are not permitted. The MPU checks every memory access and grants or denies access depending on the configuration. Illegal accesses trigger a memory fault, generating a Memory Management Fault exception.
Memory Attributes and Access Behavior
In addition to the MPU, Cortex-M3 memory regions can have attributes that control access behavior. For example, Code memory can be marked as execute-only which will cause errors on data accesses. Similarly, SRAM can be marked as no-execute to prevent jumping to data addresses.
The optional Memory Protection Extensions add additional memory attributes for higher security. Memory can be marked as non-shared to avoid cache coherency issues in multiprocessor systems. Lockable attributes allow locking down read-only data or code memory to prevent debugging modifications.
Exclusive Access Behavior
The Load-Exclusive and Store-Exclusive instructions implement synchronization primitives for multithreaded applications. A Load-Exclusive returns data from memory but also marks the address as “exclusive access” to the core. A subsequent Store-Exclusive to the same address will succeed only if no other access has occurred to that address.
This provides an atomic conditional write capability. The Load-Exclusive/Store-Exclusive addresses track a single 32-bit word. So atomic 64-bit writes require using the doubleword variant LDREXD/STREXD. Exclusives are commonly used to implement mutexes, semaphores and flags without disabling interrupts.
Tightly Coupled Memory
Some Cortex-M3 systems also support Tightly Coupled Memory (TCM) regions that provide single cycle access speed. These are small high-speed memory blocks located within the processor that do not require accessing the system bus. Instructions and time-critical data can be placed in TCM to improve performance.
The TCM regions are optional and supplement the SRAM regions. They are mapped into a reserved area of the memory map, splitting a SRAM region into SRAM and TCM sections. The processor automatically distinguishes between TCM and SRAM accesses and handles them appropriately. TCM provides fast deterministic access compared to cache systems.
Bus errors can occur when an access violates the access permissions for a memory region. For example, a write to execute-only Code memory would generate a bus error. Similarly, an access to a disabled or non-existent memory region will also create a bus error.
On a bus error, the processor signals the BusFault exception handler. The handler can then take appropriate action to deal with the access violation error. Debug exceptions and faults have higher priority than bus errors to allow debugging in all memory regions when halted.
The Cortex-M3 checks data access alignment and triggers an alignment fault on misaligned accesses. Data accesses must be aligned to their size, such as 4-byte alignment for 32-bit data. This allows simplifying memory hardware by only supporting aligned accesses.
Unaligned accesses require the processor to perform multiple aligned accesses and assemble the result. This takes multiple cycles to complete. The alignment check is performed for loads, stores and instruction fetches. Alignment faults generate the UsageFault exception for handling by the application.
The Cortex-M3 supports bi-endian operation allowing it to work efficiently with both big and little endian memory systems. This avoids the need for software byte swapping. The chip’s endian mode can be configured independently for data and instructions. The reset values for endianness depend on the system design.
For data accesses like loads/stores, the processor handles any required byte-swapping based on the data endianness setting. Instruction fetches also handle swapping code bytes based on the instruction endianness config. Therefore, endianness is transparent to software.
Several regions in the Cortex-M3 memory map are reserved for future use. The locations and sizes of these regions are defined in the ARMv7-M architecture specification. Accesses to reserved regions may be unpredictable and can cause issues. The application should avoid accessing any reserved memory regions.
In particular, reserved regions are commonly used to locate test and debugging infrastructure. Writes to these regions can alter the expected debug behavior since the infrastructure is not implemented there. Reserved regions should only be used as directed for a specific SoC implementation.
Flash Patch and Breakpoint Unit
The optional Flash Patch and Breakpoint (FPB) unit allows breakpoint debugging even in flash memory. Without the FPB, setting breakpoints in flash requires halting the processor and temporarily modifying the flash contents. The FPB avoids this by implementing breakpoints through dedicated hardware.
The FPB also enables patching code in flash to work around bugs without reprogramming. It maintains a shadow copy of flash contents for patching and implements breakpoints through a comparitor. Up to 8 literal address range breakpoints are supported. The FPB makes debugging code in flash much easier.
Flash Memory Access
Embedded flash memory has different access behavior and timing than SRAM. Flash writes must be performed in multiples of the flash programming granularity, which is power-of-two aligned like 256 or 512 bytes. Flash write cycles also take much longer than SRAM accesses.
The Cortex-M3 memory controller transparently handles flash access specifics. The processor performs SRAM-style access cycles while the controller handles aligning writes and implementing flash timing. This simplifies software by avoiding the need to consider flash restrictions.
In summary, the Cortex-M3 memory map regions each have specific access behavior. The Code region is read-only, SRAM is read-write volatile memory, peripherals allow differentiated control and status access. The MPU allows configuring region permissions. Additional access attributes, bus errors, alignment checks and endianness handling all contribute to a flexible and protected memory system.