Why volatile Matters for Memory‑Mapped Registers in Embedded C

The problem: silent register optimisation

When a compiler sees a plain pointer to a hardware address it assumes the memory behaves like ordinary RAM. At -O2 or higher it may cache the value in a register, combine consecutive writes, or even delete a write that appears to have no side‑effect. The result is a peripheral that never toggles, a sensor that returns stale data, or a watchdog that never gets kicked – all without a single compiler warning.

What volatile actually does

The volatile qualifier tells the compiler: "this object can change at any time without the program’s knowledge, so every read and write must be emitted as a real load/store instruction." It does not insert hardware memory barriers, nor does it guarantee atomicity for multi‑byte accesses. It simply prevents the optimiser from assuming the value is stable.

Worked example – toggling an LED

Assume a Cortex‑M4 where the GPIO port output register lives at 0x40020014. The minimal, correct declaration is:

#include <stdint.h>

#define PORT_ADDR 0x40020014U
volatile uint32_t * const PORT = (volatile uint32_t *)PORT_ADDR;

void toggle_led(void) {
    *PORT ^= (1U << 5);   // toggle bit 5
}

Without volatile the optimiser could rewrite the function to a no‑op if it decides the write has no observable effect. With volatile each call produces a distinct str instruction.

Verifying the generated code

1. On the build host (Linux/macOS/Windows with the ARM toolchain installed) compile with optimisation enabled:

   arm-none-eabi-gcc -O2 -c main.c -o main.o

2. Inspect the assembly for the register access:

   arm-none-eabi-objdump -d main.o | grep -A2 -B2 "PORT"

   You should see a ldr/str pair referencing the absolute address 0x40020014 for every call to toggle_led.
3. Run the binary on the target board or an instruction‑set simulator (e.g., QEMU qemu-system-arm -M nucleo-f401re -kernel firmware.elf) and observe the LED toggling at the expected rate.
4. As a sanity check, temporarily remove volatile, rebuild, and repeat step 2. The load/store will disappear or be merged, confirming the qualifier’s effect.

Trade‑offs and limitations

• Performance: Each volatile access forces a memory transaction. In tight loops this can reduce throughput and prevent loop unrolling or vectorisation.
• Not a memory barrier: On weakly ordered architectures (ARMv7‑M, RISC‑V) a volatile write may be reordered with respect to other non‑volatile accesses. Use __DMB() / __ISB() or the C11 atomic_thread_fence when ordering matters.
• Atomicity: A 32‑bit volatile write is atomic only if the bus supports single‑cycle 32‑bit accesses. For 64‑bit registers on a 32‑bit core you still need a lock‑free atomic type or a critical section.
• Over‑use: Applying volatile to ordinary variables (counters, flags) degrades performance and obscures intent. Reserve it for objects that truly map to external state – memory‑mapped registers, shared memory with DMA, or variables modified by an ISR.

Actionable checklist

1. Identify every pointer or variable that refers to a hardware register address.
2. Declare it as volatile (preferably volatile uint32_t * const for a fixed address).
3. Compile with your production optimisation level and verify the assembly contains a load/store for each access.
4. Test on hardware or a cycle‑accurate simulator; confirm the peripheral behaves as specified.
5. Document any required memory barriers or atomic operations alongside the volatile declaration.

Following these steps turns a class of silent, optimisation‑induced bugs into a visible, verifiable part of the build process.