topic Re: CW4.5 Compiler or Linker Trouble? The same code without any problem in other OS compiler... in CodeWarrior for MCU

CW4.5 Compiler or Linker Trouble? The same code without any problem in other OS compiler and linker.

Pang — Tue, 31 Jul 2007 23:20:22 GMT

Environment: CW4.5, S12XDP512, C.

I have a structure declaration as follows:

typedef struct w4MsgWindowUDT_t
{
   W4PositionUDT curxy; /* the cursor current coordinates*/
   W4PositionUDT orgxy; /* the orginal coordinates, when scrolling, it will change*/
   W4WindowUDT DispWin; /* the window location and size*/
    W4WindowUDT MsgWin;  /* the window location and size*/
   unsigned char IsActive ;       /* the tag of Active*/
   unsigned char IsVisible ;      /* the tage of visible*/
    unsigned char UnitLength;
    unsigned char Refresh;
    unsigned char IsAllRowDisplayed;
    unsigned char IsAllColDisplayed;
    unsigned char IsEditable;
    unsigned char IsMsgDataDirty;
    unsigned char IsDispDataDirty;
    unsigned char IsPhaseData;
    unsigned char IsKeyEntered;
    unsigned char PageNo;
    unsigned char PageID;
    u_int8 (*pt2Get)(void);
    u_int8 (*pt2Put)(void);
    u_int8 (*pt2KeyProc)(void);
   struct w4MsgWindowUDT_t *hw; /* horizontal window*/
    struct w4MsgWindowUDT_t *vw; /* vertical window*/
    struct w4MsgWindowUDT_t *nw; /* next chained display window*/
    struct w4MsgWindowUDT_t *ow; /* overlaped active window*/
    struct w4MsgWindowUDT_t *np; /* next chained page window for data display*/
    unsigned char *msg;
}W4MsgWindowUDT;

Then, I define a variable initialized with default data:

/* cur , org, Disp win Msg Win Ac, Vi,UL,RF,RD,CD,ED,MD,DD,PD,KE,PN,PI,Get Put Key Hw Vw Nw Ow Np*/
W4MsgWindowUDT Table6DW = {{1,16},{0,0},{{2,25},{8,40}},{{1,1},{31,16}},1, 1, 16, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0,&GetDataT6,&SaveDataT6,TableDataKeyProc,&Table6HW,&Table6VW,&Table6VW,NULL, NULL,NULL};

The problem is that one of the members "np" should be pointed to NULL according to declaration. However, it is pointed to a non-null data after having a check in Debug mode. It will have it right value unitl I explicitly re-assign it as NULL in my iniitial routine like this:

Table6DW.np = NULL;

I guess this CW compiler or linker cause me a lot of trouble. Since I have the samiliar code running on the Operating System OS-9 without any problem, in which I am using Radisys Hawk.

Any inputs will be appreciated greately.

Pang

Re: CW4.5 Compiler or Linker Trouble? The same code without any problem in other OS compiler...

CompilerGuru — Wed, 01 Aug 2007 00:24:59 GMT

Without having some real reproducible sample, I guess this issue is hard to diagnose. So let me ask for some more details.
What is your memory setup (memory model), prm file?
At which address is W4MsgWindowUDT allocated? (check the map file)
Which compiler options do you use?

Does it work when you just do a
W4MsgWindowUDT Table6DW = {0};
instead?
Do you use the default startup code?

Does the initialization of some fields work?

Is Table6DW a global or a local variable?

I cannot count (no types for a lot of fields (and don't want to too)), but when I guess that TableDataKeyProc matches to pt2KeyProc, then there is no value for np & msg. Does it help when you add two additional NULL's at the end for those?

Anyway, the only real way to see what is wrong would be to have a complete compilable sample.

Re: CW4.5 Compiler or Linker Trouble? The same code without any problem in other OS compiler...

Pang — Wed, 01 Aug 2007 01:12:15 GMT

Please see my answers below. since the .map .prm is sizeable, I could not attach them here. Could I forward them to you by email? (I need your email address) Thanks.

Without having some real reproducible sample, I guess this issue is hard to diagnose. So let me ask for some more details. ( I totally agree with you on this point)

What is your memory setup (memory model), prm file? (Far)

At which address is W4MsgWindowUDT allocated? (check the map file)
(no memory assigned for this structure definition)

Which compiler options do you use?

-CpDPAGE=0x34 -CpEPAGE=0x36 -CpGPAGE=0x10 -CpPPAGE=0x35 -CpRPAGE=0x16 -CPUHCS12X -D__FAR_DATA -Ml -OnB=b -PSegNonDef -TuC -WmsgSd1420 -WmsgSd12056

Does it work when you just do a
W4MsgWindowUDT Table6DW = {0};
instead? (I never try this, since I am going to assign the other member in the global variable definition)

Do you use the default startup code? Yes.

Does the initialization of some fields work? NO.

Is Table6DW a global or a local variable? Global.

I cannot count (no types for a lot of fields (and don't want to too)), but when I guess that TableDataKeyProc matches to pt2KeyProc, then there is no value for np & msg. Does it help when you add two additional NULL's at the end for those? Yes, You're correct. However, if I do not assign "np" to NULL in a statement instead of declaration, It will not be NULL in the memory which is pointed to the wrong place and cause my problem crash. After I assign it in a statement, I will get rid of the problem.

Anyway, the only real way to see what is wrong would be to have a complete compilable sample.

Re: CW4.5 Compiler or Linker Trouble? The same code without any problem in other OS compiler...

CompilerGuru — Wed, 01 Aug 2007 02:03:01 GMT

>Please see my answers below. since the .map .prm is sizeable, I could not attach them here. Could I >forward them to you by email? (I need your email address) Thanks.
Well can you not just add it to this thread?
If the size is too big, add it in a zip file. I guess there is a lot of air in the prm/map file.
Also at least the prm file is hopefully not that big :smileywink:

>At which address is W4MsgWindowUDT allocated? (check the map file)
>(no memory assigned for this structure definition)
Ups. I did not intend to ask for the address of the type. I wanted to ask for the address of the Table6DW variable :smileywink:.
So what's the address (and size) of Table6DW?

I would check that the variable is not allocated across a global page, well as there is just one for RAM, that's probably not the case, but something is odd. Also check in the prm file that the _COPY is not allocated banked too.
Also check in the prm file into what kind of section Table6DW is allocated, there is a segment type NO_INIT (or PAGED) for variables which are intentionally not initialized.

>Which compiler options do you use?

>-CpDPAGE=0x34 -CpEPAGE=0x36 -CpGPAGE=0x10 -CpPPAGE=0x35 -CpRPAGE=0x16 -CPUHCS12X >-D__FAR_DATA -Ml -OnB=b -PSegNonDef -TuC -WmsgSd1420 -WmsgSd12056

So it's large memory model for a HCS12X. Not sure if you need all those options, but none of them should hurt.

>Does it work when you just do a
>W4MsgWindowUDT Table6DW = {0};
>instead? (I never try this, since I am going to assign the other member in the global variable definition)

Not sure I can follow. I just meant to check if the Table6DW variable is zero initialized that way. So if it is a problem with what kind of values are initialized versus if the problem is if the variable is initialized at all. Can you try?
Just check at the start of main if the complete Table6DW is 0. Don't run your app this way :smileywink:.

Does the initialization of some fields work? NO.
So not a single field of your variable is initialized?
Suspicious. Are other global variables initialized?
Is any global variable initialized?

>I cannot count (no types for a lot of fields (and don't want to too)), but when I guess that TableDataKeyProc matches >to pt2KeyProc, then there is no value for np & msg. Does it help when you add two additional NULL's at the end for >those? Yes, You're correct. However, if I do not assign "np" to NULL in a statement instead of declaration, It will not >be NULL in the memory which is pointed to the wrong place and cause my problem crash. After I assign it in a >statement, I will get rid of the problem.

I got that, but assigning NULL in main does not mean not to assign NULL in the definition too.
Actually you are assigning NULL in the definition too, just not explicitly. Given your explanation I assume that explicitly adding NULL in the initialization list does not change anything. Well it should not change anything, it should be zero initialized either way.

What I would check is how _COPY is allocated in your prm and how the segment you place Table6DW in is defined.

Same as before, in the end a reproducible sample would be the best way to understand this. Second best, I guess would be the map and prm file, maybe there is something problematic in there too.

Also do you get any warnings from the linker or compiler? (the two you did disable in the compiler options -WmsgSd1420 -WmsgSd12056 are not problematic)

Daniel

Re: CW4.5 Compiler or Linker Trouble? The same code without any problem in other OS compiler...

Pang — Wed, 01 Aug 2007 03:39:47 GMT

Please check the attachements and my answers in RED. Thanks a lot.

>Please see my answers below. since the .map .prm is sizeable, I could not attach them here. Could I >forward them to you by email? (I need your email address) Thanks.
Well can you not just add it to this thread?
If the size is too big, add it in a zip file. I guess there is a lot of air in the prm/map file.
Also at least the prm file is hopefully not that big :smileywink: (Got it, )

>At which address is W4MsgWindowUDT allocated? (check the map file)
>(no memory assigned for this structure definition)
Ups. I did not intend to ask for the address of the type. I wanted to ask for the address of the Table6DW variable :smileywink:.
So what's the address (and size) of Table6DW? (102D3A'G)

I would check that the variable is not allocated across a global page, well as there is just one for RAM, that's probably not the case, but something is odd. Also check in the prm file that the _COPY is not allocated banked too.
Also check in the prm file into what kind of section Table6DW is allocated, there is a segment type NO_INIT (or PAGED) for variables which are intentionally not initialized. (Please check this for me, I am not clear about this part)

>Which compiler options do you use?

>-CpDPAGE=0x34 -CpEPAGE=0x36 -CpGPAGE=0x10 -CpPPAGE=0x35 -CpRPAGE=0x16 -CPUHCS12X >-D__FAR_DATA -Ml -OnB=b -PSegNonDef -TuC -WmsgSd1420 -WmsgSd12056

So it's large memory model for a HCS12X. Not sure if you need all those options, but none of them should hurt.

>Does it work when you just do a
>W4MsgWindowUDT Table6DW = {0};
>instead? (I never try this, since I am going to assign the other member in the global variable definition)

Not sure I can follow. I just meant to check if the Table6DW variable is zero initialized that way. So if it is a problem with what kind of values are initialized versus if the problem is if the variable is initialized at all. Can you try?
Just check at the start of main if the complete Table6DW is 0. Don't run your app this way :smileywink:. (not all zeros,)

Does the initialization of some fields work? NO.
So not a single field of your variable is initialized?
Suspicious. Are other global variables initialized?
Is any global variable initialized?

>I cannot count (no types for a lot of fields (and don't want to too)), but when I guess that TableDataKeyProc matches >to pt2KeyProc, then there is no value for np & msg. Does it help when you add two additional NULL's at the end for >those? Yes, You're correct. However, if I do not assign "np" to NULL in a statement instead of declaration, It will not >be NULL in the memory which is pointed to the wrong place and cause my problem crash. After I assign it in a >statement, I will get rid of the problem.

I got that, but assigning NULL in main does not mean not to assign NULL in the definition too.
Actually you are assigning NULL in the definition too, just not explicitly. Given your explanation I assume that explicitly adding NULL in the initialization list does not change anything. Well it should not change anything, it should be zero initialized either way.

What I would check is how _COPY is allocated in your prm and how the segment you place Table6DW in is defined.

Same as before, in the end a reproducible sample would be the best way to understand this. Second best, I guess would be the map and prm file, maybe there is something problematic in there too.

Also do you get any warnings from the linker or compiler? (the two you did disable in the compiler options -WmsgSd1420 -WmsgSd12056 are not problematic)

Daniel

Re: CW4.5 Compiler or Linker Trouble? The same code without any problem in other OS compiler...

CompilerGuru — Wed, 01 Aug 2007 05:53:34 GMT

Looks like the attached map file was generated with the ={0} value in the code,
Table6DW got allocated in .bss (which means its value is just 0 init).

I think here's the problem (out of the prm):
      GLOBAL_CS2    = READ_WRITE 0x100000'G TO 0x1FFFFF'G;

That is not working as with this, global areas are crossing GPAGE page boundaries.
Split that up into 64k chunks, each with its own distinct and fixed GPAGE value.
E.g.:

      GLOBAL_CS2_0    = READ_WRITE 0x100000'G TO 0x10FFFF'G;
      GLOBAL_CS2_1    = READ_WRITE 0x110000'G TO 0x11FFFF'G;
      GLOBAL_CS2_2    = READ_WRITE 0x120000'G TO 0x12FFFF'G;
      GLOBAL_CS2_3    = READ_WRITE 0x130000'G TO 0x13FFFF'G;
....

DEFAULT_RAM       INTO GLOBAL_CS2_0,GLOBAL_CS2_1,GLOBAL_CS2_2,GLOBAL_CS2_3...

The actual problem why the initialization does not work in your particular case is because the linker is defining one zero out area of 205836 bytes (out of the map file):

extern struct _tagStartup {
unsigned nofZeroOut     1
_Range   pZeroOut       0x100000'G     205836
_Copy    *toCopyDownBeg 0xCC7F
} _startupData;

That size is cutted to 16 bits when it is written into the startup information. I would expect the linker to issue a warning for that cut operation, id you get any?

Here's BTW also the variable crossing the page boundary. This LCDRxdBuffer buffer does not work this way.

     LCDRxdBuffer                            10FFC4'G      64     100      16   .common
     LCDRxdBufferPtr                         110028'G       3       3      14   .common

See also http://forums.freescale.com/freescale/board/message?board.id=CW816COMM&message.id=2565
about why there is this 64k limitation.

Daniel

Re: CW4.5 Compiler or Linker Trouble? The same code without any problem in other OS compiler...

Pang — Thu, 02 Aug 2007 03:36:23 GMT

After I changed it to smalll chuncks, there is no cutting value warning issued. All the initializations works fine. Thanks a lot for your help.

One question, If I want to allocate these three variables into .common.

unsigned short rtcSecondOld; // last second record when power surge occurs

unsigned short ResumeTimer; // Flag to identify power surge

unsigned short ResumeTimeC; // as one's compliment of ResumeTimer.

I use these two variables to monitor what time power surge happens and how it lasts. I deal with these values in one XIRQ, then when RESET signal restart my appplication, it will check if the flag is set and it lasts more than 2 seconds, it will return to where it was. Therefore, I want to keep them intact when startup. How can I declare them in .common?

By the way, where to get documentation about .prm for details?

Thanks a lot again

Pang

Re: CW4.5 Compiler or Linker Trouble? The same code without any problem in other OS compiler...

CompilerGuru — Thu, 02 Aug 2007 15:48:12 GMT

The not init at reset question has been answered by CrazyCat
in this thread.
http://forums.freescale.com/freescale/board/message?board.id=CW816COMM&message.id=3045

The prm file syntax is described in the linker manual, for CW HC12 V4.5, I guess that was in its own linker/smartlinker pdf manual (inside CodeWarrior\Help\pdf), for more recent version the content has been combined into the Build_Tools_Utilities.pdf (same folder).

Also I'm not aware of any special semantics of .common, when it comes to initialization.
Well, actualy we are not using that section name AFAIK, but I can guess what it is supposed to mean.

Daniel

Re: CW4.5 Compiler or Linker Trouble? The same code without any problem in other OS compiler...

CrasyCat — Thu, 02 Aug 2007 16:06:14 GMT

Hello

To close the loop here, according to my understanding here is how the HC08/HC12 compiler allocates the data in default segments.

.data : Contains the initialized global variables.

e.g. int a = 1, b= 2;

.bss : Contains the static un-initialized global variables.

e.g. static int c, d ;

.common : Contains the un-initialized global variables (not static).

e.g. int e, f;

.rodata : Contains the constant variables .

e.g. const int c1=2, c2=4 ;

.rodata1

: Contains all the string constants.

e.g. #define mystr = “

Hello world”

I hope it clarifies things a bit.

CrasyCat