Memory-Mapped Registers and Volatile

C is defined in terms of an abstract machine, and a compiler need only produce the observable behaviour of that machine (§5.1.2.3). Ordinary variables are not observable; if the compiler can prove a value has not changed, it may keep it in a register, read it once instead of a thousand times, or drop a store that is overwritten later. Those are the optimisations that make compiled C fast, and they are all built on one assumption: memory changes only when this program writes to it.

A peripheral register breaks that assumption. Hardware changes it. The volatile qualifier (§6.7.3 ¶7) tells the compiler that every access to the object in the source is a side effect that must actually happen, exactly as many times as written and in the order written relative to other side effects. The compiler may no longer cache the value, hoist a read out of a loop, merge two writes, or delete a read whose result is unused.

↑ This step uses the figure at the top of the page.

Toggle volatile off in the figure. The compiled loop loads the status once and branches to itself. With volatile on, the load is inside the loop, and the fourth read sees READY. Nothing about the source changed except the qualifier; the difference is entirely in what the compiler was permitted to assume.

Two rules of thumb follow. Every pointer to a peripheral register is volatile. Every variable shared between an interrupt handler and the main loop is volatile, because from the main loop’s point of view the handler changes it “on its own”, which is the same situation as hardware.

volatile is about the compiler. It says nothing about the processor, the bus or other code, and three misunderstandings follow from forgetting that.

It is not atomic. counter++ on a volatile uint32_t is still a load, an add and a store. An interrupt between the load and the store loses an update. On an 8-bit processor even a single 16-bit read is two instructions. Atomicity needs the hardware’s help: a single-word aligned load or store on Cortex-M, an atomic alias register, or interrupts disabled around the sequence (lesson 6).

It does not order non-volatile accesses. The compiler keeps volatile accesses in order with each other. A write to an ordinary buffer followed by a volatile write to a DMA “start” register may be reordered so that the start is issued before the buffer is filled, because the buffer is not volatile. GCC’s manual is explicit about this.

It is not a hardware barrier. Even when the instructions are emitted in order, a Cortex-M write buffer may let a store to a peripheral complete after the next instruction runs. Arm’s barrier cookbook (GENC-007826) describes when DSB or DMB is needed: typically after configuring a peripheral and before relying on its effect, and after starting a DMA. CMSIS exposes these as __DSB() and __DMB().

Because a register access is a command, the kind of access matters in ways a variable never shows.

• Read-to-clear: reading a status register clears its flags (common for UART and I²C status). Reading it twice loses the event; reading it for a debugger display loses the event. Read once into a local, then examine the local.
• Write-1-to-clear (W1C): writing a 1 clears a flag, writing 0 does nothing. The idiom REG |= FLAG reads all flags and writes them all back as 1, clearing every pending flag. Write the mask directly: REG = FLAG.
• Write-only set/reset: STM32’s GPIOx_BSRR (RM0090 §8.4.7) sets pins whose bit is 1 in the low half and resets those in the high half, and reads as 0. It exists so that a pin can be changed without a read-modify-write.
• Access width: some registers must be accessed as 32 bits; a byte store to one lane may be ignored or may write all four lanes. The uint32_t in the pointer type is a promise to the hardware, not a convenience.
• Reserved bits: “read as 0, write as 0” or “preserve the read value” is a real instruction; a read-modify-write preserves them, a blind write does not.

The datasheet marks each field with its access type (the RP2040 uses RW, RO, WC, SC and others). Read those letters before writing any idiom.

A timer has a CTRL register at offset 0x00 with bit 0 EN and bits 7:4 PRESC, and a START register at offset 0x04 that starts counting when any value is written. Configure a prescaler of 9 and start it.

TIMER->CTRL = (TIMER->CTRL & ~TIMER_CTRL_PRESC_Msk)
            | (9u << TIMER_CTRL_PRESC_Pos)
            | TIMER_CTRL_EN;
__DSB();
TIMER->START = 1u;

With __IO on the struct members, the first statement compiles to one load of CTRL, the arithmetic, and one store: the read cannot be reused from an earlier read, and the store cannot be deferred past the START write. The __DSB() makes sure the CTRL store has completed on the bus before the START store is issued; on many chips it is unnecessary, but the cost is a few cycles and the failure without it is a timer that starts with the old prescaler on one silicon revision and not another. Without volatile, the compiler could legally keep CTRL in a register across both statements and write it after START, or, if it had read CTRL earlier in the function, reuse that stale value.