Volatile vs Memory Barriers — When Volatile Isn't Enough

Every embedded developer learns about volatile early on — it tells the compiler not to optimize away reads or writes to a variable. But there is a persistent misconception that volatile guarantees memory ordering at the hardware level. It does not. On an ARM Cortex-M processor — even though the core itself executes instructions in order — the memory system (write buffers, bus bridges, and interconnects) can reorder or buffer memory accesses so that external observers see them in a different order than the program specified. volatile is only half the story. The other half is memory barriers.

What Volatile Actually Does

volatile solves exactly two problems:

1. Prevents the compiler from caching a value in a register — every read goes to memory.
2. Prevents the compiler from reordering or eliminating accesses — the generated instructions appear in source order from the compiler’s perspective.

That second point is critical: the compiler respects volatile ordering only at the compiler level. Once the instructions are emitted, the hardware memory system is free to buffer or reorder them depending on the memory type of the target region.

The scope of volatile can be visualized as a layer that only covers the compiler’s transformation:

+================================================================+
|C SOURCE CODE                                                   |
|                                                                |
|buffer[0] = payload;  dma_flag = 1;                             |
+----------------------------------------------------------------+
|                                v                               |
|             volatile prevents compiler reordering              |
|                                v                               |
+================================================================+
|COMPILER OUTPUT (ASM)                                           |
|                                                                |
|str r0, [buffer]   ; str r1, [dma_flag]                         |
+----------------------------------------------------------------+
|                                v                               |
|      NO volatile protection! Memory system can reorder         |
|      (for Normal memory — see "ARM Memory Types" below)        |
|                                v                               |
+================================================================+
|HARDWARE EXECUTION                                              |
|                                                                |
|[dma_flag] may reach memory BEFORE [buffer] if both are         |
|in Normal (SRAM) memory and no barrier is used                  |
+================================================================+

The compiler faithfully emits the store to buffer before the store to dma_flag. But between the compiler output and actual hardware execution, the memory system’s write buffer can reorder the two stores — if they target Normal memory (such as SRAM). This is precisely the gap dmb fills.

Consider a scenario where the CPU prepares data in SRAM for a DMA controller:

volatile uint32_t dma_flag;         // in SRAM at 0x20001000
uint32_t payload_buffer[64];        // in SRAM at 0x20002000

void prepare_for_dma(uint32_t value) {
    payload_buffer[0] = value;   // Write data to Normal memory
    __DMB();                     // Ensure the data write is observed before the flag
    dma_flag = 1;                // Signal the DMA that data is ready
}

Without the __DMB(), the write buffer could reorder the SRAM stores, and the DMA controller might see dma_flag == 1 while payload_buffer still holds stale data. The __DMB() ensures that any observer (the DMA controller, another core) sees the data write before the flag write.

Note: If both addresses were in the peripheral region (0x40000000–0x5FFFFFFF), which the default Cortex-M memory map marks as Device memory, the hardware already guarantees ordering. See the ARM Memory Types section below.

ARM Memory Types

Before discussing the barrier instructions, it is essential to understand the ARM memory type system. This is the foundation for deciding when barriers are actually needed.

The ARM architecture defines several memory types, each with different ordering and buffering rules. On Cortex-M, the default memory map assigns these types automatically:

Key rules from the ARM Architecture Reference Manual:

• Normal memory allows the memory system to reorder, merge, and speculatively read. This is where barriers are most critical.
• Device memory (non-gathering, non-reordering) guarantees that accesses to the same peripheral are observed in program order. Accesses to different peripherals may still be reordered relative to each other.
• Strongly-Ordered memory guarantees both ordering and completion before the next access proceeds.

The practical consequence: writes to peripheral registers within the same Device memory region do not require a DMB for ordering. Barriers become necessary when:

1. You need ordering between Normal memory and Device memory (e.g., writing data to SRAM, then triggering a DMA via a peripheral register).
2. You need ordering between different Device memory regions (e.g., configuring peripheral A, then enabling peripheral B that depends on A).
3. You need completion guarantees — knowing a write has physically reached the peripheral, not just been ordered (DSB).
4. You need pipeline synchronization after changing system configuration registers (ISB).

The Three ARM Barriers

ARM Cortex-M provides three distinct memory barrier instructions:

The critical distinction is ordering vs. completion: DMB ensures writes are seen in order by other observers, while DSB ensures writes have actually finished at the destination.

In embedded C, you typically access these via compiler intrinsics or CMSIS wrappers:

#include <cmsis_gcc.h>  // or <cmsis_armcc.h>

__DMB();  // Data Memory Barrier
__DSB();  // Data Synchronization Barrier
__ISB();  // Instruction Synchronization Barrier

When to Use Each Barrier

DMB — Ordering Between Memory Regions

Use dmb when you need to ensure one memory write is observed before another, particularly when the writes target different memory types or different Device regions. The classic example is preparing data in Normal memory (SRAM) before signaling a peripheral or DMA controller:

uint32_t tx_buffer[64];  // Normal memory (SRAM)

void start_uart_dma(const uint32_t *data, size_t len) {
    // Copy data into the DMA source buffer (Normal memory)
    memcpy(tx_buffer, data, len * sizeof(uint32_t));

    __DMB();  // Ensure SRAM writes are observed before peripheral writes

    // Configure and trigger the DMA (Device memory)
    DMA1_Channel4->CMAR = (uint32_t)tx_buffer;
    DMA1_Channel4->CNDTR = len;
    DMA1_Channel4->CCR |= DMA_CCR_EN;
}

dmb is the lightest barrier — it only orders explicit memory accesses. It does not wait for them to complete and does not flush the pipeline.

DSB — Completion Guarantee

Use dsb when you need to know that a memory access has fully completed before proceeding. The most common case is waiting for a peripheral write to take effect before entering a low-power state or checking status:

// Trigger a DMA transfer
DMA1_Channel1->CCR |= DMA_CCR_EN;
__DSB();  // Wait until the enable write has physically reached the peripheral

// Now it's safe to check status or trigger another operation
while (!(DMA1->ISR & DMA_ISR_TCIF1)) { /* wait */ }

dsb is heavier than dmb — it stalls the processor until all preceding memory accesses have completed. On Cortex-M7, this also covers cache maintenance operations. Use it when the completion of a write matters, not just its ordering relative to other writes.

ISB — After System Configuration Changes

Use isb after modifying system configuration that affects instruction execution — for example, after changing the vector table offset, modifying MPU regions, or writing to the CONTROL register:

// Relocate vector table
SCB->VTOR = new_vector_table_addr;
__DSB();  // Ensure the write completes
__ISB();  // Ensure subsequent instructions use the new vector table

Without the isb, the processor pipeline might still contain instructions fetched under the old configuration. The isb flushes the pipeline so all subsequent instructions are fetched with the new settings.

A Practical Pattern: DMA Completion in Shared Memory

Consider a shared flag between the CPU and a DMA controller, both operating on Normal memory (SRAM):

+----------------------------------------------------------+
|CPU                   Shared SRAM                         |
|+----------+          +------------------+                |
||          | <------> |  (flag, data)    |                |
|+----------+          +--------+---------+                |
|                               |                          |
|                        +------v------+                   |
|                        |     DMA     |                   |
|                        | Controller  |                   |
|                        +-------------+                   |
+----------------------------------------------------------+

The DMA writes a completion flag in shared SRAM. The CPU polls it:

volatile uint32_t done_flag;     // in SRAM — Normal memory
uint32_t rx_data[256];           // in SRAM — Normal memory, filled by DMA

// Start DMA transfer...
start_dma_transfer();

// Poll for completion
while (done_flag == 0) {
    // Spin — volatile ensures the compiler re-reads from memory each iteration
}
__DMB();  // Ensure subsequent reads see the data the DMA wrote
process_data(rx_data);

Here, volatile ensures the compiler actually reads done_flag from memory each iteration rather than caching it in a register. The __DMB() after the loop ensures that when process_data() reads from rx_data, all the memory writes the DMA made are observed in the correct order — the data writes are guaranteed to be visible after the flag write.

Without the __DMB(), the memory system could satisfy a read of rx_data with data that was buffered or fetched before the flag read completed, resulting in stale data.

Common Mistake: Missing Barriers Across Memory Types

The most common barrier mistake in embedded code is not between writes to the same peripheral (those are ordered by the Device memory type), but between writes to different memory types. Consider configuring a DMA descriptor in SRAM and then enabling the DMA peripheral:

// BROKEN: no barrier between Normal memory write and Device memory write
void start_transfer(uint32_t *src, uint32_t len) {
    // These writes target Normal memory (SRAM) — can be buffered/reordered
    dma_descriptor.src_addr = (uint32_t)src;
    dma_descriptor.length = len;
    dma_descriptor.control = DMA_DESC_VALID;

    // This write targets Device memory (peripheral register)
    DMA1_Channel1->CCR |= DMA_CCR_EN;  // Enable DMA
}

The compiler emits the descriptor writes before the enable, but the memory system may reorder the Normal memory writes relative to the Device memory write. The DMA controller could start reading the descriptor before all fields are written. The fix:

// CORRECT: barrier between Normal and Device memory writes
void start_transfer(uint32_t *src, uint32_t len) {
    dma_descriptor.src_addr = (uint32_t)src;
    dma_descriptor.length = len;
    dma_descriptor.control = DMA_DESC_VALID;

    __DMB();  // Ensure all SRAM writes are observed before the peripheral write
    DMA1_Channel1->CCR |= DMA_CCR_EN;
}

Another subtle case: clearing an interrupt flag in a peripheral and then immediately returning from the ISR. Without a DSB, the write to clear the flag may still be in the write buffer when the processor unstacks the exception, causing the ISR to fire again spuriously:

void TIM2_IRQHandler(void) {
    TIM2->SR &= ~TIM_SR_UIF;  // Clear the update interrupt flag
    __DSB();                   // Ensure the flag-clear write completes before ISR return
    // ... handle the interrupt
}

Barrier Cheat Sheet

Summary

volatile and memory barriers solve different problems. volatile prevents the compiler from optimizing away or reordering memory accesses. Memory barriers (dmb, dsb, isb) control the order and completion of those accesses at the hardware level.

The decision of whether to use a barrier depends on the ARM memory type of the regions involved:

• Same peripheral (Device memory): volatile alone is sufficient for ordering — the hardware guarantees that accesses to the same Device region are observed in program order.
• Normal memory to Device memory (e.g., writing a buffer in SRAM, then triggering a DMA peripheral): you need volatile and __DMB() to ensure the Normal memory writes are observed before the Device memory write.
• Completion-sensitive operations (e.g., clearing an interrupt flag before ISR return, entering low-power mode): you need __DSB() to guarantee the write has physically reached the destination.
• System configuration changes (e.g., VTOR, MPU, CONTROL): you need __DSB() + __ISB() to ensure the new configuration takes effect for subsequent instructions.

When in doubt, consult the ARM memory type of your target addresses and the ARM Architecture Reference Manual’s ordering rules for that type.

Related Reading

• Understanding Volatile Keyword in Embedded C — the foundation that this post builds on
• DMA Programming in Embedded C for High-Throughput Data Transfer — where barriers are essential for correct DMA operation
• Lock-Free Ring Buffers for ISR-to-Task Communication — another concurrency pattern where ordering matters

References

• ARM Cortex-M Programming Guide to Memory Barrier Instructions (Application Note AN321) — ARM Ltd. The definitive guide on when and how to use DMB, DSB, and ISB on Cortex-M processors.
• ARMv7-M Architecture Reference Manual (ARM DDI 0403) — ARM Ltd. Defines the memory model, memory types (Normal, Device, Strongly-Ordered), and barrier instruction semantics.
• ARM Cortex-M7 Technical Reference Manual — ARM Ltd. Details on write buffers, speculative accesses, and cache behavior specific to Cortex-M7.
• ARM Cortex-M4 Technical Reference Manual — ARM Ltd. Pipeline and memory system details for Cortex-M4.
• ARM Learn: Memory Ordering in the ARM Architecture — ARM Ltd. Accessible introduction to ARM memory ordering concepts.
• A Guide to Undefined Behavior in C and C++ (Part 1–3) — John Regehr, University of Utah. Explains why volatile is not a synchronization primitive and how compilers treat it.
• Memory Barriers: A Hardware View for Software Hackers — Linux Kernel Documentation. Comprehensive explanation of memory barriers from the Linux kernel perspective, applicable to understanding hardware ordering.
• STM32 Cortex-M4 Programming Manual (PM0214) — STMicroelectronics. Covers the Cortex-M4 memory model and barrier usage in the context of STM32 microcontrollers.
• CMSIS Core Documentation — ARM Ltd. (open-source). Documents the __DMB(), __DSB(), and __ISB() intrinsic wrappers used throughout this article.