cancel
Showing results for 
Search instead for 
Did you mean: 

Data mismatch with structure pointer

Michal Dubovsky
Associate II
Posted on May 18, 2017 at 16:09

Hello, I recently migrated from 8 bit processors and something that has always worked for me is showing some unexpected behavior. Clearly I am missing something very obvious to you 32 bit guys

// define a structure somewhere in header file

typedef struct

{

char first[2];

char second[2];

char third;

char fourth;

uint8_t fifth;

uint16_t sixth;

uint8_t seventh;

char eight;

} my_struct;

// create a field

uint8_t my_field[11]={0x2D, 0x43, 0x30, 0x30, 0x52, 0x75, 0x01, 0x0D, 0x00, 0x01, 0x21}; 

my_struct *p_to_mystruct=(void *)my_field;

now if I look into contents of p_to_mystruct i get this:

p_to_mystruct->first[0] = 0x2D

p_to_mystruct->first[1] = 0x43

p_to_mystruct->second[0] = 0x30

p_to_mystruct->second[1] = 0x30

p_to_mystruct->

third

= 0x52

p_to_mystruct->

fourth

= 0x75

p_to_mystruct->fifth = 0x01

p_to_mystruct->sixth = 0x0100 // NOTICE A PROBLEM HERE

p_to_mystruct->seventh = 0x21 // ALSO WRONG

p_to_mystruct->eight = 0xb5   // ALSO WRONG

It looks as if there happened some kind of shift when referencing to the sixth member of my_struct.

Data in SRAM @ the location where p_to_mystruct is pointing to is as follows:

Address0-34-78-B

00000000200000002D4330305275010D000121B5

I guess it has something to do with the fact that the program somehow can't stitch the uint16_t tohether from the end of one word and the begenning of the other one but I have no idea why and how to avoid this kind of behavior.
1 ACCEPTED SOLUTION

Accepted Solutions
Posted on May 18, 2017 at 16:33

32-bit compilers typically align elements of structures on 4-byte boundaries, so you don't get alignment faults, and it is more efficient. The Cortex-M3/4 are more tolerant of alignment issues than the ARM7/9 previously, but will still fault on 64-bit reads (ie a double read into two Rx registers via LDRD/STRD). The Cortex-M0 is intolerant of misaligned variables.

Different compilers have slightly different methods but using #pragma pack(1) typically creates a structure in the form you are familiar with. Check your compiler documentation.

Code that might have worked on x86 machines often requires attention when porting. Where there are issues of alignment you'd typically memcpy() a portion of the structure into a local/auto variable of the same type where the alignment is guaranteed.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..

View solution in original post

3 REPLIES 3
Posted on May 18, 2017 at 16:33

32-bit compilers typically align elements of structures on 4-byte boundaries, so you don't get alignment faults, and it is more efficient. The Cortex-M3/4 are more tolerant of alignment issues than the ARM7/9 previously, but will still fault on 64-bit reads (ie a double read into two Rx registers via LDRD/STRD). The Cortex-M0 is intolerant of misaligned variables.

Different compilers have slightly different methods but using #pragma pack(1) typically creates a structure in the form you are familiar with. Check your compiler documentation.

Code that might have worked on x86 machines often requires attention when porting. Where there are issues of alignment you'd typically memcpy() a portion of the structure into a local/auto variable of the same type where the alignment is guaranteed.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Posted on May 18, 2017 at 16:36

https://en.wikipedia.org/wiki/Data_structure_alignment

 

http://www.geeksforgeeks.org/structure-member-alignment-padding-and-data-packing/

 
Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Posted on May 19, 2017 at 08:50

Works like a magic  This was a very valuable lesson. Thank you!