Does the addresses of an arbitrary peripheral register can be used to store data randomly during code execution?

Question

I need to make sure of the concept of volatile qualifier in C-language. so volatile is used when we don't want the compiler to optimize the variable being identified as a volatile or in other words volatile tells the compiler not to care when or where the variable may change and just change it. So when we define a peripheral address we use define for example #define PORTA_DATA_R (*((volatile unsigned long *)(0x4000.000))) if I initialized it to a certain value in my code and made some operations then completed with my code can the compiler randomly uses this address for example to store other data in it if it was needed or this address is only specific for the data register of the port and can't be used except for this purpose.

Answer 1

The compiler will not use the address of a peripheral register for "random" data storage. The compiler will only use the address range that has been specified as a data storage area in the linker map file, which is typically the range of addresses that correspond to RAM. The volatile qualifier is not really relevant here.

Having said that, it may be possible for you to use those registers for data storage if you write your own code to access them. If there was some peripheral register that provided read/write access but didn't have any actual affect on processor function then you might be able to store data in it. As a hypothetical example, if a GPIO port is configured as an input port then the "output" register for that port may have no affect on the processor's function, so you could use it as a storage location.

Answer 2

The volatile qualifier on a variable tells the compiler that it can never make any assumptions about it. In a sense, you are telling the compiler not to apply any optimizations to this variable; just do exactly what the statement say. If you say to write into a volatile variable, the compiler must write to it, even if it thinks it knows that value is already there. If you say read from one, it must read it, even if it has seen no way for the variable to have changed. Finally, it must never do anything to such a variable that it has not been explicitly instructed to do, including using the memory location for other purposes.

On the other hand, in optimized code, the compiler could do anything it wants with a non-volatile variable, so long as the result of the operations (assuming normal conditions) is unchanged. This includes, if there are two variables in the same scope who's usage doesn't overlap, using the same memory location for both (an implied union).

So, to directly answer your last question, no, the compiler cannot reuse a volatile variable for other purposes but can do this with non-volatile variables.

Answer 3

can the compiler randomly uses this address for example to store other data in it if it was needed or this address is only specific for the data register of the port and can't be used except for this purpose.

The compiler isn't even involved, it uses the addresses it has been told to use. What matters is the linker script, where you have the memory mapping of the whole MCU. Variables will get allocated in the segments listed there. The various segments used by the compiler/linker are explained here. It will only use those mentioned segments for storing data, never custom segments.

Regarding memory-mapped hardware registers specifically, there's two options:

• Either the tool chain provides a register map with some non-standard syntax (like @) to allocate registers at specific addresses. If so, you have to use that register map instead of #define as in your example. There will be some manner of "no init" directive, so that the start-up code doesn't touch these registers, which wouldn't make sense.
• Or this is handled with macros only. The linker (and compiler) will be unaware that the register area even exists. There is nothing allocated at all.

The former has the advantage that registers will be available in the debugger just like any variable. This allows bad debuggers with no MCU support to still display hardware registers. This is why crappy tool chains are keen to provide non-standard, trashy register maps - it is less work for them than to make the debugger aware of registers for a certain MCU.

The latter has the advantage that it is 100% standard C and 100% portable between tool chains. With the disadvantage that you have to peek directly into the memory map during debugging, rather than having the registers appear as variables in a watch window.