Problem occur when assign a ulong value

wfrancis wrote on Monday, September 07, 2009:

The env is LPC2214 and FreeRTOS 5.3.0.
Maybe its not a rtos error, but it’s looks very strange for me.

I defined a struct like this:

#pragma pack(1)

typedef struct
    unsigned char led_busy;                      
    unsigned char led_nua;
    unsigned char led_ua;
    unsigned char led_xe1;
    unsigned char led_b1_err[2];
    unsigned char led_b2_err[2];
    unsigned char led_b3_err[2];
    unsigned char led_g1_err[2];
    unsigned char led_m1_err[2];
    unsigned short es_rs_cur[2];
    unsigned short ses_rs_cur[2];
    unsigned short uas_rs_cur[2];
    unsigned short bbe_rs_cur[2];
    unsigned long cv_rs_cur[2];
    unsigned short es_rs[2];
    unsigned short ses_rs[2];
    unsigned short uas_rs[2];
    unsigned short bbe_rs[2];
    unsigned long cv_rs[2];
    unsigned long cv_rs_threshold[2];
    unsigned char b1_err_led[2];

    unsigned short es_ms_cur[2];
    unsigned short ses_ms_cur[2];
    unsigned short uas_ms_cur[2];
    unsigned short bbe_ms_cur[2];
    unsigned short efs_ms_cur[2];
    unsigned long cv_ms_cur[2];
    unsigned short es_ms[2];
    unsigned short ses_ms[2];
    unsigned short uas_ms[2];
    unsigned short bbe_ms[2];
    unsigned short efs_ms[2];
    unsigned long cv_ms[2];
    unsigned long cv_ms_threshold[2];
    unsigned char b2_err_led[2];
    unsigned short es_hp_cur[2];
    unsigned short ses_hp_cur[2];
    unsigned short uas_hp_cur[2];
    unsigned short bbe_hp_cur[2];
    unsigned short efs_hp_cur[2];
    unsigned long cv_hp_cur[2];
    unsigned short es_hp[2];
    unsigned short ses_hp[2];
    unsigned short uas_hp[2];
    unsigned short bbe_hp[2];
    unsigned short efs_hp[2];
    unsigned long cv_hp[2];
    unsigned long cv_hp_threshold[2];
    unsigned char b3_err_led[2];

    unsigned short m1_err[2];
    unsigned short m1_err_cur[2];
    unsigned short m1_err_threshold[2];

    unsigned short g1_err[2];
    unsigned short g1_err_cur[2];
    unsigned short g1_err_threshold[2];

    unsigned char au_point_threshold[2];
    unsigned char au_point_RPJEP[2];
    unsigned char au_point_RPJEN[2];

    uchar j0_function[2];
    uchar j0_receive[2];
    uchar j0_expect[2];
    uchar j0_insert[2];

    uchar loop[2];

    uchar rmtPowerDet[2];

    uchar j1_function[2];
    uchar j1_mode[2];
    J1STRING j1_expect[2];
    J1STRING j1_insert[2];
    J1STRING j1_receive[2];

    uchar j016_function[2];
    uchar j016_mode[2];
    J0STRING j016_expect[2];
    J0STRING j016_insert[2];
    J0STRING j016_receive[2];

In one of my tasks I just init a structure like:

performance_status  myStatus;
        myStatus.cv_ms_threshold[0] = 0x12345678;
        myStatus.cv_hp_threshold[0] = 0x12345678;
        myStatus.cv_rs_threshold[0] = 0x12345678;

and print the value like:

        pPrintf ("0x%08x\n\r",myStatus.cv_ms_threshold[0]);
        pPrintf ("0x%08x\n\r",myStatus.cv_hp_threshold[0]);
            pPrintf ("0x%08x\n\r",myStatus.cv_rs_threshold[0]);

what I get is:


What’s wrong?


davedoors wrote on Monday, September 07, 2009:

I’ve not had a detailed look but would suggest this is just because you are forcing variables onto bad byte alignment addresses. Looks ok up to cv_ms_cur but cv_ms_cur is 4 bytes and starts on a 2 byte address. If you pack the structure to 1 byte alignment then you are going to have to manage the alignment manually by rearranging the order or manually adding packing bytes.

wfrancis wrote on Monday, September 07, 2009:

Well I changed the pack value to 4 and the print is ok now.
However, the struct is used in such a case that :
When I get an array of data, I convert it to the structure and use it as a structure.
If I set the pack value to 4, using the sizeof method to calc its size I would get a value larger than the array size.What should I do to fulfill this case?

davedoors wrote on Monday, September 07, 2009:

This is just a C problem. You would have the same problem without using the RTOS.

wfrancis wrote on Monday, September 07, 2009:

I manually __packed the vals in the structure, and it looks like everything is ok now.

Thanks very much for Dave’s help!