Problem occur when assign a ulong value

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]; }performance_status; 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%08xnr",myStatus.cv_ms_threshold[0]);         pPrintf ("0x%08xnr",myStatus.cv_hp_threshold[0]);             pPrintf ("0x%08xnr",myStatus.cv_rs_threshold[0]); what I get is:         0x12345678         0x56781234         0x56781234 What’s wrong? Regards! wFrancis

Problem occur when assign a ulong value

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.

Problem occur when assign a ulong value

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?

Problem occur when assign a ulong value

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

Problem occur when assign a ulong value

I manually __packed the vals in the structure, and it looks like everything is ok now. Thanks very much for Dave’s help!