Reserved structure member in CMSIS device peripheral access file - arm

Question

Why in the CMSIS device file "TM4C123GH6PM.h" there are reserved structure members declared in some of the peripheral's structures for example in TIMER0_Type structure there are two reserved members.
does it have something to do with the microcontroller itself or is it concerned with word alignment and how the structure is going to be allocated in the memory?
typedef struct { /*!< TIMER0 Structure */
__IO uint32_t CFG; /*!< GPTM Configuration */
__IO uint32_t TAMR; /*!< GPTM Timer A Mode */
__IO uint32_t TBMR; /*!< GPTM Timer B Mode */
__IO uint32_t CTL; /*!< GPTM Control */
__IO uint32_t SYNC; /*!< GPTM Synchronize */
__I uint32_t RESERVED;
__IO uint32_t IMR; /*!< GPTM Interrupt Mask */
__IO uint32_t RIS; /*!< GPTM Raw Interrupt Status */
__IO uint32_t MIS; /*!< GPTM Masked Interrupt Status */
__O uint32_t ICR; /*!< GPTM Interrupt Clear */
__IO uint32_t TAILR; /*!< GPTM Timer A Interval Load */
__IO uint32_t TBILR; /*!< GPTM Timer B Interval Load */
__IO uint32_t TAMATCHR; /*!< GPTM Timer A Match */
__IO uint32_t TBMATCHR; /*!< GPTM Timer B Match */
__IO uint32_t TAPR; /*!< GPTM Timer A Prescale */
__IO uint32_t TBPR; /*!< GPTM Timer B Prescale */
__IO uint32_t TAPMR; /*!< GPTM TimerA Prescale Match */
__IO uint32_t TBPMR; /*!< GPTM TimerB Prescale Match */
__IO uint32_t TAR; /*!< GPTM Timer A */
__IO uint32_t TBR; /*!< GPTM Timer B */
__IO uint32_t TAV; /*!< GPTM Timer A Value */
__IO uint32_t TBV; /*!< GPTM Timer B Value */
__IO uint32_t RTCPD; /*!< GPTM RTC Predivide */
__IO uint32_t TAPS; /*!< GPTM Timer A Prescale Snapshot */
__IO uint32_t TBPS; /*!< GPTM Timer B Prescale Snapshot */
__IO uint32_t TAPV; /*!< GPTM Timer A Prescale Value */
__IO uint32_t TBPV; /*!< GPTM Timer B Prescale Value */
__I uint32_t RESERVED1[981];
__IO uint32_t PP; /*!< GPTM Peripheral Properties */
} TIMER0_Type;

Answer 1

On that particular part there is a 981 word gap between TIMER0_TBPV and TIMER0_PP, and a 1 word (32bit) gap between TIMER0_SYNC and TIMER0_IMR. From the datasheet:
The "reserved" fields simply force alignment with the hardware register map for which the type is used as an overlay. You certainly should not instantiate an object of this type in memory!

Answer 2

These structs are defined for easier access to memory mapped peripheral registers.
Each register has a fixed absolute address. The struct layout needs to be carefully designed such that the base address of the struct plus the offset of the member within the struct results in the register address.
As the register addresses are only partially contiguous, gaps without registers must be filled with dummy struct members, named RESERVEDxx.

Answer 3

They are a 1:1 map with the hardware. Say that you have only two registers:
A # 0x1000
B # 0x1004
You could define this struct:
struct {
u32* Ar;
u32* Br;
}regs;
And then assign manually the addresses:
struct regs myRegs;
myRegs.Ar = (u32*)0x1000;
myRegs.Br = (u32*)0x1004;
But doing this is error prone and also very long to do. What you can do, and what CMSIS does, is to define a struct with datatypes instead of pointers, knowing that the compiler will treat such structure as contiguous elements in the memory and will do pointer access for you.
struct {
u32 Ar;
u32 Br;
}regs;
struct regs* myRegsPtr = (struct regs*) 0x1000;
Now myRegsPtr holds the base address of the hardware register structure. Since now the C structure mimics the HW layout, accessing a member of the structure does exactly the pointer arithmetic you need for accessing the register you requested.
myRegs->Br; //This does 0x1000 + sizeof(all members before Br), reaching the correct offset.
Now back to your question. When we look at the datasheet we see this particular HW structure:
Can you spot the jump of 981*4 bytes? That is where you RESERVED area in your struct come from. In order to access the last register, the compiler must know that there are this amount of bytes to "jump".