Reply by Karsten Obenaus June 16, 20032003-06-16
Hi Daniel,

You are right, the SDD functions are RTS terminated, using near pointers and
the JSR instruction solved the problem, thanks a lot! ----- Original Message -----
From: "Daniel Friederich" <>
To: <>
Sent: Friday, June 13, 2003 1:43 PM
Subject: RE: [68HC12] CodeWarrior type cast objptr->funcptr >
> Hi Karsten,
>
> The compiler does not automatically adapt the layout of a function pointer
to the different layout of a data pointer.
> I don't know you code, but are you sure your routines in NVMInit_C
> do expect the far calling convention? Are they RTC terminated or are they
using a RTS?
> I could imagine that they were written in the small memory model so they
end with a RTS
> and calling them with a CALL will not work, but I'm not sure.
>
> If they end with a RTS, then call them with a near function pointer and it
should work.
> typedef SGF_RESULT (* __near pNVMINIT) ( UINT16 oscClock,
> BOOL BDMEnable,
> UINT16 regBase,
> UINT16 pDescriptor,
> UINT16 funcPtr);
>
> If not, you have to manually convert the data pointer to a function
pointer (a rotate) before calling it.
>
> Bye
>
> Daniel
>
> > -----Original Message-----
> > From: Karsten Obenaus [mailto:]
> > Sent: Friday, June 13, 2003 12:35
> > To:
> > Subject: [68HC12] CodeWarrior type cast objptr->funcptr
> >
> >
> > We're using the Metrowerks Codewarrior for HC12 IDE and have encountered
a
> > problem with the compiler and type casting from an object pointer to a
function pointer.
> > Any help would be greatly appreciated.
> >
> > We'd like to use the HCS12 SGF NVM Standard Software Driver in our
current
> > project (flash/eeprom routines). The SSD consists of various modules
that
> > contain the function code as hex byte tables. Here's an excerpt from the
> > sample code that comes with the SSD:
> >
> > NVMINIT MODULE:
> > const unsigned char NVMInit_C[] = { 0x.., 0x.., ..... };
> >
> > SAMPLE CODE:
> > typedef SGF_RESULT (*pNVMINIT) ( UINT16 oscClock,
> > BOOL BDMEnable,
> > UINT16 regBase,
> > UINT16 pDescriptor,
> > UINT16 funcPtr);
> > extern const unsigned char NVMInit_C[];
> > pNVMINIT NVMInit = (pNVMINIT) NVMInit_C;
> >
> > returnCode = NVMInit(OSC_CLOCK, BDMEnable, REGISTER_BASE_ADDRESS,
> > (UINT16)Descriptor, (UINT16)SIMPLE_RANGE_CHECKING);
> >
> >
> > Basically, the pNVMINIT NVMInit = (pNVMINIT) NVMInit_C; instruction
performs
> > a typecast from an object pointer (NVMInit_C) to a function pointer
> > (NVMInit). This causes a C1805 compiler warning.
> >
> > Let's take a look at the generated code:
> >
> > LEAS -3,SP
> > LDD #NVMInit_C
> > STD 1,SP
> > CLRB
> > STAB 0,SP
> > .
> > now the function parameters are being pushed onto the stack (7 bytes)
> > .
> > CALL [0x0007,SP]
> >
> > As you can see the compiler pushes the address 0x00hhll onto the stack,
hh
> > being high byte of the NVMInit_C address, ll being the low byte, 0x00
being
> > the page. However, the CALL instruction expects the subroutine address
in
> > the format hhllpp (pp being 0x00 in this case). This means the value
> > 0x00hhll turns into a subroutine address 00hh in page ll.
> >
> > In order for the CALL instruction to work properly the compiler should
> > generate this code instead:
> > LEAS -3,SP
> > CLRB
> > STAB 2,SP
> > LDD #NVMInit_C
> > STD 0,SP
> >
> > Is this a compiler error?
> >
> >
> > Karsten Obenaus,
> > ModernDrive Technology GmbH
> > Am Steinacher Kreuz 24
> > 90427 Nuernberg, Germany
> > www.moderndrive.de
> >
> >
> >
> >
> >
> >
> >
> > --------------------
> >
> >
> >
> > ">http://docs.yahoo.com/info/terms/
> >
> > -------------------- >
> ">http://docs.yahoo.com/info/terms/ >




Reply by Daniel Friederich June 13, 20032003-06-13

Hi Karsten,

The compiler does not automatically adapt the layout of a function pointer to the different layout of a data pointer.
I don't know you code, but are you sure your routines in NVMInit_C
do expect the far calling convention? Are they RTC terminated or are they using a RTS?
I could imagine that they were written in the small memory model so they end with a RTS
and calling them with a CALL will not work, but I'm not sure.

If they end with a RTS, then call them with a near function pointer and it should work.
typedef SGF_RESULT (* __near pNVMINIT) ( UINT16 oscClock,
BOOL BDMEnable,
UINT16 regBase,
UINT16 pDescriptor,
UINT16 funcPtr);

If not, you have to manually convert the data pointer to a function pointer (a rotate) before calling it.

Bye

Daniel

> -----Original Message-----
> From: Karsten Obenaus [mailto:]
> Sent: Friday, June 13, 2003 12:35
> To:
> Subject: [68HC12] CodeWarrior type cast objptr->funcptr > We're using the Metrowerks Codewarrior for HC12 IDE and have encountered a
> problem with the compiler and type casting from an object pointer to a function pointer.
> Any help would be greatly appreciated.
>
> We'd like to use the HCS12 SGF NVM Standard Software Driver in our current
> project (flash/eeprom routines). The SSD consists of various modules that
> contain the function code as hex byte tables. Here's an excerpt from the
> sample code that comes with the SSD:
>
> NVMINIT MODULE:
> const unsigned char NVMInit_C[] = { 0x.., 0x.., ..... };
>
> SAMPLE CODE:
> typedef SGF_RESULT (*pNVMINIT) ( UINT16 oscClock,
> BOOL BDMEnable,
> UINT16 regBase,
> UINT16 pDescriptor,
> UINT16 funcPtr);
> extern const unsigned char NVMInit_C[];
> pNVMINIT NVMInit = (pNVMINIT) NVMInit_C;
>
> returnCode = NVMInit(OSC_CLOCK, BDMEnable, REGISTER_BASE_ADDRESS,
> (UINT16)Descriptor, (UINT16)SIMPLE_RANGE_CHECKING); > Basically, the pNVMINIT NVMInit = (pNVMINIT) NVMInit_C; instruction performs
> a typecast from an object pointer (NVMInit_C) to a function pointer
> (NVMInit). This causes a C1805 compiler warning.
>
> Let's take a look at the generated code:
>
> LEAS -3,SP
> LDD #NVMInit_C
> STD 1,SP
> CLRB
> STAB 0,SP
> .
> now the function parameters are being pushed onto the stack (7 bytes)
> .
> CALL [0x0007,SP]
>
> As you can see the compiler pushes the address 0x00hhll onto the stack, hh
> being high byte of the NVMInit_C address, ll being the low byte, 0x00 being
> the page. However, the CALL instruction expects the subroutine address in
> the format hhllpp (pp being 0x00 in this case). This means the value
> 0x00hhll turns into a subroutine address 00hh in page ll.
>
> In order for the CALL instruction to work properly the compiler should
> generate this code instead:
> LEAS -3,SP
> CLRB
> STAB 2,SP
> LDD #NVMInit_C
> STD 0,SP
>
> Is this a compiler error? > Karsten Obenaus,
> ModernDrive Technology GmbH
> Am Steinacher Kreuz 24
> 90427 Nuernberg, Germany
> www.moderndrive.de >
>
> -------------------- >
> ">http://docs.yahoo.com/info/terms/



Reply by Karsten Obenaus June 13, 20032003-06-13
We're using the Metrowerks Codewarrior for HC12 IDE and have encountered a
problem with the compiler and type casting from an object pointer to a function pointer.
Any help would be greatly appreciated.

We'd like to use the HCS12 SGF NVM Standard Software Driver in our current
project (flash/eeprom routines). The SSD consists of various modules that
contain the function code as hex byte tables. Here's an excerpt from the
sample code that comes with the SSD:

NVMINIT MODULE:
const unsigned char NVMInit_C[] = { 0x.., 0x.., ..... };

SAMPLE CODE:
typedef SGF_RESULT (*pNVMINIT) ( UINT16 oscClock,
BOOL BDMEnable,
UINT16 regBase,
UINT16 pDescriptor,
UINT16 funcPtr);
extern const unsigned char NVMInit_C[];
pNVMINIT NVMInit = (pNVMINIT) NVMInit_C;

returnCode = NVMInit(OSC_CLOCK, BDMEnable, REGISTER_BASE_ADDRESS,
(UINT16)Descriptor, (UINT16)SIMPLE_RANGE_CHECKING); Basically, the pNVMINIT NVMInit = (pNVMINIT) NVMInit_C; instruction performs
a typecast from an object pointer (NVMInit_C) to a function pointer
(NVMInit). This causes a C1805 compiler warning.

Let's take a look at the generated code:

LEAS -3,SP
LDD #NVMInit_C
STD 1,SP
CLRB
STAB 0,SP
.
now the function parameters are being pushed onto the stack (7 bytes)
.
CALL [0x0007,SP]

As you can see the compiler pushes the address 0x00hhll onto the stack, hh
being high byte of the NVMInit_C address, ll being the low byte, 0x00 being
the page. However, the CALL instruction expects the subroutine address in
the format hhllpp (pp being 0x00 in this case). This means the value
0x00hhll turns into a subroutine address 00hh in page ll.

In order for the CALL instruction to work properly the compiler should
generate this code instead:
LEAS -3,SP
CLRB
STAB 2,SP
LDD #NVMInit_C
STD 0,SP

Is this a compiler error? Karsten Obenaus,
ModernDrive Technology GmbH
Am Steinacher Kreuz 24
90427 Nuernberg, Germany
www.moderndrive.de