Volatile keyword with ADC, USB interrupt readings

Question

I was just reading an answer about global variables, it also stated that I should use volatile affix whenever a global is used in an interrupt.

• In my program I am using a 30 byte ADC buffer without interrupt, it just gets regularly updated with DMA transfers.

• There is also a 4 byte USB buffer which gets updated whenever I receive an USB interrupt.

• There is a variable that gets changed every time main while loop starts over, it reads one of the adc values and updates itself with a proper math function, and then gets used in another function frequently to generate something else.

• There is a counter which I increment in every while loop start over, it is used widely in my code ecosystem. Has nothing to do with interrupts or external sources, just gets incremented whenever code finishes a full cycle.

In which of these four situations I should use volatile and would it lead to any memory based side effects in my system?

I wasn't using volatile fix since now and not sure if I ever faced a problem related to this.

I am using cortex M-4, pure C code.

Answer 1

In my program I am using a 30 byte ADC buffer without interrupt, it just gets regularly updated with DMA transfers.

Any DMA buffer needs to be volatile qualified to let the compiler know it cannot make any assumptions about the contents there.

There is also a 4 byte USB buffer which gets updated whenever I receive an USB interrupt.

If it is shared between an interrupt and the main program, you need to volatile qualify it to prevent optimization hiccups. You must also use some means of protection against race conditions.

There is a variable that gets changed every time main while loop starts over, it reads one of the adc values and updates itself with a proper math function, and then gets used in another function frequently to generate something else.

It does not need to be volatile. The memory-mapped ADC register itself needs to be volatile-qualified since it can change at any time.

There is a counter which I increment in every while loop start over, it is used widely in my code ecosystem. Has nothing to do with interrupts or external sources, just gets incremented whenever code finishes a full cycle.

No volatile needed.

More info here.

Answer 2

You need the volatile keyword because a good optimizing compiler will try to reduce memory accesses. If the variable in question can change outside of what the code is doing to it, or if the pertinent memory location is used as an output, then that's not behavior you want.

The volatile keyword tells the compiler "keep the physical memory up to date, and don't assume that the physical memory stays the same". There's some detail about exactly where it reads and writes, which you can find in a longer article about this, but that's the essence.

So, this tells you:

• If it gets updated by hardware, or if it affects hardware, it needs to be volatile.
• If it gets updated or used by an interrupt and used or updated elsewhere, it needs to be volatile. You can think of an interrupt as "looking like" hardware to the compiler, because it's not within the thread of control that the compiler knows about.
• If it's getting used to communicate between threads (as in an RTOS), then it needs to be volatile (and yes, there are RTOS mechanisms for this -- and sometimes they're the right mechanisms. When they aren't, and you need to just write to or read from a global -- use volatile).
• If it's set and read in the same thread of control, it does not need to be volatile, even if it's global.

Answer 3

The rule is that you need volatile whenever memory contents are modified outside of regular program flow:

• hardware registers change contents without the program doing anything
• DMA buffers are modified external to the program
• interrupts change program flow

The compiler's data flow analysis follows normal execution paths and decides when to store data in memory or keep it in registers, based on access frequency and availability of registers.

The obvious example is

int i; // global

…
    while(i == 0); // wait for something to happen

Without optimization, you get

1:
    ldr r0, =i   ; get address
    ldr r0, [r0] ; get value
    tst r0       ; update flags
    beq 1b

The compiler knows that the address of i never changes, so it can move the first ldr out of the loop, and no code path stores anything to this address, so it can also move the second ldr. The remainder is an empty endless loop, so the code becomes

    ldr r0, =i
    ldr r0, [r0]
    tst r0
    bne 2f
1:
    b 1b
2:

This is obviously wrong, but normally the compiler runs out of registers rather quickly, so if the loop isn't empty and doesn't refer to i anymore, it is quite likely that i will be reloaded even if it isn't marked volatile.

As @Evan suggests, volatile isn't used for multithreaded code, even though the compiler cannot see the effects of the other threads. The important bit here: the only way you can be sure to have a consistent view is to hold a lock, and the locking functions are then treated as a barrier by the compiler, forcing a reload.

This is also how the Linux kernel gets away with non-volatile DMA buffers: this is correct because the driver is called only from paths that have locked some data structure (and the compiler can see that call path, DMA buffers are generally not accessed from interrupt code!), and this causes the compiler to emit loads and stores.

Answer 4

The volatile qualifier prevents the optimizer from eliminating or reordering access to a memory address -- every evaluation or assignment will result in its own memory load or store.

a) The buffer should be declared volatile as it is updated by the DMA mechanism which the compiler doesn't know about.

b) The buffer should be declared volatile because it is updated in the interrupt context and the main thread of control.

c) As long as this counter is only manipulated from the main thread of control it does not need to be volatile. The compiler knows that function calls can modify memory.

d) Again, you don't need volatile here.

e) You didn't ask but there is at least one other major reason to use volatile, and that is for memory mapped IO or machine registers. Here, the memory reads or writes have important side effects so need to happen exactly as specified. If you have a hardware RNG that is memory mapped such that each read returns a new random number, that should be volatile otherwise the compiler may coalesce multiple reads. These hardware specific cases are usually handled by the platform SDK assuming you are using it. If you manually declare hardware regions you will need to take care of the volatile qualifier yourself.

f) One place not to use volatile: multi-threading. Superficially this appears to be the same as the interrupt context, and indeed there are some similarities. However, volatile only ensures that memory reads and writes are preserved, it does not enforce that anything in particular is atomic. On a single core CPU interrupts are atomic -- the IRS will finish before the main thread resumes so you don't have to worry about the main thread seeing a partially updated state. The reverse is still a problem: the ISR can generally interrupt the main thread at any time, so the ISR shouldn't make assumptions about the state. If you do, you have to guard changes to that with interrupt disable functions.

For multi-threading you generally want to use concurrency primitives like mutex locks and thread safe queues. These include the appropriate memory barriers to make sure that other threads see the updates. Those concurency primitives may internally use volatile values, but you generally won't need or want to explicitly use volatile qualifications for multi-threading (unless one of the other conditions applies).

For much more detail about why not to use volatile in high-level multi-threaded application see this question and answer:

https://stackoverflow.com/questions/4557979/when-to-use-volatile-with-multi-threading