passing a volitile address from function to function

[NZ_Design]

My secound problem is I have a table of addresses I need to look up and pass the resault to a function.

The addresses are to external memory mapped locations.

      OC_L1_CS          INTO  NO_INIT     0x40000B'G TO 0x40000B'G;   // Output Card 1 CS;

#pragma DATA_SEG __GPAGE_SEG OC_L1_CS
  volatile uchar pOC_L1_CS;
#pragma DATA_SEG DEFAULT

typedef struct {
  volatile uchar* pSol;
  volatile uchar* pAD;
} LCS_SOL_ADDR;

  LCS_SOL_ADDR const Sol_Addr[] = {{&pOC_L1_CS,  &pOC_AD1_CS},
                                   {&pOC_L2_CS,  &pOC_AD2_CS},
                                   {&pOC_L3_CS,  &pOC_AD3_CS},
                                   {&pOC_L4_CS,  &pOC_AD4_CS},
                                   {&pOC_BAT_CS, &pOC_BATAD_CS}};

my function is decleared as

  extern void  MAX7301_Init     (CARDSETTINGS const* Layout, SPI_PORT Port, volatile uchar* pAddr);

and called as

     MAX7301_Init(OC_Layout,Sol_Port,Sol_Addr[cCard].pSol);

Sol_addr[cCard].pSol is the address I are trying to pass.

At the rutine in get the value 255 and it is not correct.

What are I decearing wrong here

[Lundin]

To be able to use addresses larger than 16-bit on a 16-bit computer, you must use the non-standard "far" keyword, or a similar one. Otherwise the address will be truncated to a 16-bit one when you pass it as a parameter to that function.

To do it with ANSI C/C++, you'd need two parameters. One that is the 16-bit base address, and one that is the extention/page.

Note that on most Freescale micros, you will get problems if you set the page register manually while you run the code from paged memory. All code working with page registers must be located in a non-paged 16-bit area.

[NZ_Design]

I thought that was ment to be the great thing about codewarrier. It was ment to be able to take care of all that for me. I know to much about motorola and there page registers with haveing to use the MC9S12DP256 processor. I are know using the MC9S12XDP512 and it is a hole lot better.

But why is this any different to calling a structured array in program memory. They are still both in paged memory just I is using the GPAGE and one is using PPAGE.

[Lundin]

Good question. Now if you ask this question to Freescale, they say that it won't be a problem. You are supposed to be able to use the compiler option -CpPPAGE, edit some value in a file called datapage.c and link it to your program. As far as I know this has worked poorly in every CW version, the value you write together with the compiler option is ignored, and which value it picks from datapage.c seems to be arbitrary: it might pick the PPAGE setting from a 68HC12 or if you're lucky, from a HCS12.

I never trusted this so I wrote my own routines for it, doing the same thing as the compiler library code would do. That is, put the code in non-banked flash, put PPAGE on the stack, set PPAGE manually, read the memory cell, and then restore PPAGE.

[CompilerGuru]

As I'm from Freescale: it's not a problem :smileywink:.

Note that the handling of datapage.c is V4.6 (V4.5) is not the same as for older versions.
That version does take the values passed in the -Cp options, it also uses the -Cpu option to determine the right addresses if -Cp is not given, so especially for the HCS12X it does take the right addresses automatically.

Anyway, I would also not touch PPAGE with a HCS12X (manually). Those chips have the access via GPAGE and those accesses can be made without necessarily having to jump to a non banked runtime routine first, no need to store/restore the old page value.

What did not change is that you have to pass the full address of a object :smileywink:.
If this needs a __far qualifier (which means GPAGE access for the HCS12X BTW) depends on the memory model. In the large memory model all pointers except the ones explicitly qualified with __near are 24 bit pointers already. In small/banked, you have to qualify the pointer.

Daniel