Bit field in structure

[Aswin_5232]

I am using MC9S12DG256 micro controller and codewarrior 5.2 .

typedef union

{

  uint16_t  w;

struct  {                    // Row  Col

uint16_t rc21 : 1;    //  2   1   msbit,msbyte

uint16_t rc22 : 1;    //  2   2

uint16_t rc23 : 1;    //  2   3

uint16_t rc24 : 1;    //  2   4

uint16_t rc25 : 1;    //  2   5

uint16_t rc14 : 1;    //  1   4

uint16_t rc13 : 1;    //  1   3

uint16_t rc12 : 1;    //  1   2

uint16_t rc26 : 1;    // 2   6   msbit,lsbyte

uint16_t rc27 : 1;    // 2   7

uint16_t rc28 : 1;    // 2   8

uint16_t rc29 : 1;    // 2   9

uint16_t unused : 1;  // 

uint16_t rc18 : 1;    // 1   8

uint16_t rc17 : 1;    // 1   7

uint16_t rc16 : 1;    // 1   6

    }b;

}lb_struct; 

Here the structure objects are arranged in LSByte MSbit order so when I use the union w to access the value is not correct. I want it to be arranges as MSByte MS bit order. Instead LS Byte first I need MSByte first and I also dont want the bitfield size reduction to happen. If i give int it should be allocated as int not char. I know about the setting to change the Bit field allocation order but when I do the register bits also getting changed for example instead of BIT7, BIT0 is toggled I don't want that to happen.

[lama]

Hi,

This behaviour is absolutely correct in the case of the S12 family. Higher byte is at the lower address.

The MCU is a big endian so word has always higher byte at lower address. As you can see for this configuration

typedef union

{

  unsigned int w;

  struct 

    {

      unsigned int f15 : 1;//0

      unsigned int f14 : 1;//0

      unsigned int f13 : 1;//0

      unsigned int f12 : 1;//0

      unsigned int f11 : 1;//0

      unsigned int f10 : 1;//0

      unsigned int f09 : 1;//0

      unsigned int f08 : 1;//0

      unsigned int f07 : 1;//0

      unsigned int f06 : 1;//0

      unsigned int f05 : 1;//0

      unsigned int f04 : 1;//0

      unsigned int f03 : 1;//0

      unsigned int f02 : 1;//0

      unsigned int f01 : 1;//0

      unsigned int f00 : 1;//0

    }b;

}attrib2;

Everything is correctly written. The highest bifield flag is written to the highest bit of the registers (word) PORTAB or a variable xx.

Of course, in the window Data1 you can see there is a bit 0 set but it is based on the definition in the device header file. (look into mc9s12dg256.h file in your project window and search for portab definition)

Safe workaround for bitfield ordering issues on MC9S12 (CodeWarrior)

To avoid bitfield ordering problems while keeping hardware register mappings intact on MC9S12 (CodeWarrior), the recommended and robust workaround is not to use C bitfields at all for logical data interpretation.

Bitfield layout (bit order, byte order, and storage unit) is compiler-defined and controlled by global compiler settings. In CodeWarrior, changing the bitfield allocation order affects all bitfields, including those used for hardware register definitions. This results in incorrect hardware access (for example, BIT7 being interpreted as BIT0), which is unacceptable for peripheral register control. Therefore, bitfields cannot be safely used when exact and stable bit positioning is required.

The safe solution is to use a uint16_t value as the single source of truth and access individual bits via explicit masks and shifts. This guarantees correct MSByte / MSBit behavior, is independent of compiler bitfield rules, and does not interfere with hardware register mappings.

For example, instead of a bitfield-based union, define the data and its bit positions explicitly:

typedef uint16_t lb_word;

/* Explicit MSB-first bit definitions */

#define RC21 (1u << 15)

#define RC22 (1u << 14)

#define RC23 (1u << 13)

#define RC24 (1u << 12)

#define RC25 (1u << 11)

#define RC14 (1u << 10)

#define RC13 (1u << 9)

#define RC12 (1u <<

#define RC26 (1u << 7)

#define RC27 (1u << 6)

#define RC28 (1u << 5)

#define RC29 (1u << 4)

#define RC18 (1u << 2)

#define RC17 (1u << 1)

#define RC16 (1u << 0)

The 16‑bit value can then be manipulated safely and unambiguously, for example:

lb_word w = 0;

w |= RC21; /* set RC21 (bit 15) */

w &= ~RC27; /* clear RC27 (bit 6) */

if (w & RC14) {

/* RC14 is set */

}

This approach ensures:

• Full control over exact bit positions (MSByte / MSBit)
• Correct uint16_t representation without implicit byte reordering
• No dependency on compiler-specific bitfield behavior
• No risk of breaking hardware register access
• Suitability for safety‑critical and automotive codebases

In practice, explicit bit masks and shifts are the standard solution in embedded and automotive projects whenever an exact and predictable data layout must be guaranteed.

Best regards,
Ladislav