Need Help Sharing Pointers Between XGATE and S12X

[DaveSubert]

All,

I have read the following threads regarding sharing pointers between S12X and XGATE:
http://forums.freescale.com/freescale/board/message?board.id=CW816COMM&message.id=5241&query.id=111480#M5241

http://forums.freescale.com/freescale/board/message?board.id=CW816COMM&message.id=3870&query.id=1115...
I have attempted to implement the method described in the first forum post. Thus far, I have not had any luck.

I am attempting to create an array of configuration structures that contain pointers to I/O ports.
For convenience, I want this array to be accessed by both cores and would like to avoid creating two copies of the same array of structures.  Here are snippets of my first attempt.

Included by XGATE & S12X source code:
pulseo_private.h
typedef struct
{
 

#ifdef CPU12X /*define structure for CPU12X*/
unsigned char driver_type; /* driver type, pwm/onoff*/
unsigned char driver_type_align; /* alignment padding*/
unsigned char port_address_align; /* alignment padding*/
@far @gpage unsigned char * port_address; /* port address*/
#else /*structure definition for XGATE::allows sharing of pointers*/
unsigned char driver_type; /* driver type*/
unsigned char driver_type_align; /* alignment padding*/
unsigned char port_address_align; /* alignment padding for port address*/
unsigned char port_address_pg; /*page for global pointer port_address*/
@far @gpage unsigned char * port_address /*port address*/
#endif

 

} pulseo_init_port_map_t;

Compiled by S12X compiler:
pulseo_mod_globals.c
const pulseo_init_port_map_t pulseo_chan_map[] =
{
 

/*Init CHANNEL_01*/
0,
0,
0,
(@far @gpage unsigned char *)&PORTP,
 

};

Compiled by XGATE compiler:
unsigned char temp;
unsigned char * temp1;
temp = *(pulseo_chan_map[driver_index].port_address); //deference for test
temp1 = (hal_u08_t*)(pulseo_chan_map[driver_index].port_address); //get address for test

The array address appears correctly to the XGATE, but I am unable to access structure members correctly.   I find both the pointer address and data value are incorrect. Please note, this is built using the COSMIC S12X and XGATE compilers with the MC9S12XEQ384 controller.

Any advice would be greatly appeciated (except to switch from Cosmic to Codewarrior

Thanks in Advance,

Dave

[CompilerGuru]

What is "sizeof(@far @gpage unsigned char *)" for the cosmic compiler? Does the cosmic compiler reserve 3 or 4 bytes for far pointers?

Are the offsets (and sizes) of all the structs members the same for the S12X and the XGATE compiler? You could check that at compile time by computing it with the ANSI offsetof macro and comparing it to the expected value.

What address values do you get in the structure when reading them from the S12X or from the XGATE? What is in memory? What do you expect, what do you find?

Is the explicit cast in the initialization necessary?

I'm also not sure what you refer to with "the array address", which appears correct to the XGATE, you mean the address from which the port_address field is read from?

In the end, if the goal is to point to different port addresses, then the simplest solution is probably just to use S12X near pointers as the addresses of all peripherials are the same for the XGATE and the S12X (for any pointer type...). Only addresses of RAM or FLASH locations are different in between the two cores and need the special handling.

Daniel

[DaveSubert]

Thanks for your reply.  Here are the answers to your questions:

>>What is "sizeof(@far @gpage unsigned char *)" for the cosmic compiler? Does the cosmic >>compiler reserve 3 or 4 bytes for far pointers? 

I think we have a winner!  Cosmic defines them as 4 bytes.  I dropped the ball here, in other forum posts, I read far pointers are 3 bytes, but that's for CodeWarrior....not COSMIC.

This also further explains why the definition of hal_pulseo_chan_map was messed up in the list file.  There was an additional byte I could not account for.

Today I learned something extremely valuable about compilers.  I was under the impression that the pointer definitions would be the same since the generated code is for the same processor.  Not

the case.  I obviously have a lot to learn about compilers.

>>Are the offsets (and sizes) of all the structs members the same for the S12X and the XGATE >>compiler? You could check that at compile time by computing it with the ANSI offsetof macro and >>comparing it to the expected value.

    No point in answering this question.....I'll have to change the definitions anyway.

>>What address values do you get in the structure when reading them from the S12X or from the >>XGATE? What is in memory? What do you expect, what do you find?

S12X

    temp = 0x00  (correct/expected/verified location in memory by using debugger) 

    temp1 =  0x258 (correct/expected/verified location in memory by using debugger)

XGATE

    temp = 0xFF  (incorrect)

    temp1 = 0x0002 (incorrect)

>>Is the explicit cast in the initialization necessary?

I've tried this code with and without the cast and it doesn't work.  Also, the compiler manual calls    out the requirement for declaring a global pointer as @far @gpage when accessable via the GPAGE register.

>>I'm also not sure what you refer to with "the array address", which appears correct to the XGATE, >>you mean the address from which the port_address field is read from?

Actually no.  Let me explain.  I set a pointer in the XGATE code to point to the array pulseo_chan_map (just to test the address).  The XGATE code reads the pulseo_chan_map address as 0x0F4E.  This value is correct, since the output *.MAP file shows the address of pulseo_chan_map as 0x780F4E.

>>In the end, if the goal is to point to different port addresses, then the simplest solution is probably >>just to use S12X near pointers as the addresses of all peripherials are the same for the XGATE and >>the S12X (for any pointer type...). Only addresses of RAM or FLASH locations are different in >>between the two cores and need the special handling.

I have tried this approach before beginning this forum post.  On the S12X side I created the pulseo_chan_map array without defining a separate definition for the XGATE and also without forcing the global pointer via @far @gpage.  The XGATE code was also unable to access the structure members properly.  I was observing very similiar results.

What's interesting, however; is in other portions of my code I am able to correctly access an array of structures defined on the S12X side with the XGATE (by using the #pragma align on/off).  The only difference is that the structures I am able to share do NOT contain pointers.  As such, I began this approach as a slick way to allow for pointers in these structures.

I'll take another STAB at my proposed solution (I couldn't resist the HC11/12 humor), but now assuming the correct pointer size.

If you have any other thoughts, please let me know.  I will also update this thread with what happens.

Dave

Message Edited by Dave Subert on 2009-05-08 01:22 AM

[DaveSubert · Accepted solution]

THANK YOU!  THANK YOU!  THANK YOU! 

Works great for 2 array entries.  Will be adding more and will follow up if any more problems/lessons encountered.

There were two problems:

1.  Cosmic represents far pointers in 4 bytes instead of 3 so my structure had to be re-defined taking this into account.

2.  This problem was a mistake on my part.  I changed include directories without updating the path in my makefile.  As a result, the XGATE code was not recognising the alternate definition of pulseo_chan_map.

Hints that lead me to this conclusion:

1.  Pointer representation is defined by the compiler and can vary independent of hardware.

2.  Never thought of using the sizeof() C function.  I instead created listing files for everthing which was not as an efficient test.

Thanks So Much for Your Help! 

I'm a part-time EE graduate student roughly 5 days days from the end of my semester.  I had already spent roughly a week on this problem.  Due to the time involved, I couldn't afford to loose more time.

[DaveSubert]

Success!

I wanted to say thanks again and provide an update on the results of my project.  Through the use of the XGATE I was able to effectively double the capabilty of the ECU I am designing.

Without the XGATE in a simulated application environment the CPU was 70% utilized and 30% free.

By using the XGATE, the CPU is now 30% utilized and 70% FREE!!

To say the least, this is a very sobering result.  The XGATE is not a toy or product of marketing.  It is an extremely useful tool when applied correctly.  Interestingly enough, the development investment was not all that significant.  These results were achieved through a solid 3 months worth of research.

Thanks again.

Dave