Why are all the pointers to peripheral structure definitions in MKE06Z4.h marked Volatile in MKE06Z4.h?

[seanbeatty]

I'm using version 1.3 of MKE06Z4.h, which is what's generated when I build a new bareboard project with Codewarrior 10.6. All of the peripheral register structures define a pointer to the structure, and qualify it with the volatile keyword. For example, here's the definition of the ADC:

/** ADC - Peripheral register structure */

typedef struct ADC_MemMap {

  uint32_t SC1;                                    /**< Status and Control Register 1, offset: 0x0 */

  uint32_t SC2;                                    /**< Status and Control Register 2, offset: 0x4 */

  uint32_t SC3;                                    /**< Status and Control Register 3, offset: 0x8 */

  uint32_t SC4;                                    /**< Status and Control Register 4, offset: 0xC */

  uint32_t R;                                      /**< Conversion Result Register, offset: 0x10 */

  uint32_t CV;                                     /**< Compare Value Register, offset: 0x14 */

  uint32_t APCTL1;                                 /**< Pin Control 1 Register, offset: 0x18 */

  uint32_t SC5;                                    /**< Status and Control Register 5, offset: 0x1C */

} volatile *ADC_MemMapPtr;

This defines the pointer ADC_MemMapPtr as volatile. Why? There's only one ADC on the device - once that pointer is initialized, it won't likely be changed to point at anything else.

On the other hand, the individual registers in the ADC_MemMap structure likely will change without the compiler knowing about it (for example, the Conversion_Complete flag). Shouldn't the volatile keyword be applied to the structure members, not the pointer to the structure?

I noted that this was not the case in version 1.0 of this file, which is used by many of example projects. The volatile keyword doesn't appear in MKE06Z4.h version 1.0.

Any thoughts?

Sean

[seanbeatty]

You're right, Mark - the whole structure inherits the volatile qualification in this code:

/** ADC - Peripheral register structure */

typedef struct ADC_MemMap {

  uint32_t SC1;                                    /**< Status and Control Register 1, offset: 0x0 */

  uint32_t SC2;                                    /**< Status and Control Register 2, offset: 0x4 */

  ...

  uint32_t SC5;                                    /**< Status and Control Register 5, offset: 0x1C */

} volatile *ADC_MemMapPtr;

I decided to go with:

typedef volatile struct ADC_MemMap_tag {

  uint32_t SC1;                                    /**< Status and Control Register 1, offset: 0x0 */

  uint32_t SC2;                                    /**< Status and Control Register 2, offset: 0x4 */

  ...

  uint32_t SC5;                                    /**< Status and Control Register 5, offset: 0x1C */

} ADC_MemMap;    //This is the type definition

This makes any use of the new type, ADC_MemMap, volatile. It also eliminates the need to use "struct ADC_MemMap" everywhere I referenced the type, as was necessary using the original generated1.3 version of MKE06Z4.h.

Sean

[mjbcswitzerland]

Sean

I don't know the C standards well enough to be sure but it may be that the complete struct content inherits the volatile attribute - there looks to be a similar question here http://stackoverflow.com/questions/2044565/volatile-struct-semantics

although I don't know whether the answer is correct or not.

When in doubt, always use the simplest form that is known to work as intended without needing a PHD in compiler workings and rules; therefore, to be sure, I would indeed redeclare the members individually as volatile, which leaves no questions open, unless you experiment with the compiler in question to prove that it handles the individual members as volatile (which may even be compiler dependent at an edge-case where the interpretation could even have been misunderstood by the implementors).

When the case tools regurgitate code snippets and headers you may save some time to get lots of bits and pieces but I don't think that there is any guarantee that they will always work or don't have bugs which will keep you busy for months sorting them out - they also change (without any version management) between releases (as you have seen).

Regards

Mark