flash app vs banked flash app

Started by Bernie Boos July 26, 2005
Hi everyone,
I'm using an MC9S12A256B ucontroller and have working code when I
compile and run in a regular flash application. But my code has gone
above the ~32.6kB and I have to switch to the Banked flash app. My
code is compiling (after making sure my interrupts were in non-banked
flash) and downloads to the ucontroller. But when i run the code and
try to initialize using the NVM (non-volatile memory) SSD (standard
software driver) in Metrowerks IDE it jumps to a part of memory where
it doesn't belong.
If I step through the assembly code, it looks like instead of jumping
to the proper 0x004C67 location, it's going to the 0x004C location...
it's not reading all 3 bytes in the location, only the first 2. Maybe
I have an incorrect value in the settings? I'm not sure.

Thanks in advance,
Bernie



--- In 68HC12@68HC..., "Bernie Boos" <bernie_boos@h...> wrote:

> If I step through the assembly code, it looks like instead of jumping
> to the proper 0x004C67 location, it's going to the 0x004C location...
> it's not reading all 3 bytes in the location, only the first 2. Maybe
> I have an incorrect value in the settings? I'm not sure.
>
> Thanks in advance,
> Bernie

I don't see how you are implementing a 24-bit address, which is what
it looks like you are saying. What is the instruction that jumps wrong?



I wish I understood this better, but I'll try.
I'm using the EEPROM NVM functions.
typedef SGF_RESULT (*pNVMINIT) ( UINT16 oscClock,
BOOLEAN BDMEnable,
UINT16 regBase,
UINT16 pDescriptor,
UINT16 funcPtr);
//I declare the function pointers
pNVMINIT NVMInit;
// then initialize to the beginning of the function
NVMInit = (pNVMINIT) NVMInit_C;
//so NVMInit points to 0x4C00 (as seen in the debugger)
//Then I call the function
NVMInit(NVM_CLOCK, FALSE, REGISTER_BASE_ADDRESS, (UINT16)Descriptor,
(UINT16)RangeCheck_C);
// and I expect the program to jump to address 0x4C00, but it jumps
// to 0x004C instead

Sorry I can't be more descriptive, but I have never used the banked
flash application before and I don't entirely understand how it all
works.

Bernie

--- In 68HC12@68HC..., "Jefferson Smith" <imajeffs@h...> wrote:
> --- In 68HC12@68HC..., "Bernie Boos" <bernie_boos@h...>
wrote:
>
> > If I step through the assembly code, it looks like instead of
jumping
> > to the proper 0x004C67 location, it's going to the 0x004C
location...
> > it's not reading all 3 bytes in the location, only the first 2.
Maybe
> > I have an incorrect value in the settings? I'm not sure.
> >
> > Thanks in advance,
> > Bernie
>
> I don't see how you are implementing a 24-bit address, which is what
> it looks like you are saying. What is the instruction that jumps
wrong?


Hi Bernie,

your problem is that the CALL instruction is not expecting the 24 far
address in the (for the HC12) usual big endian format. It expects the
page to be behind the 16 bit offset (I guess this made the
implementation of the CALL instruction simpler, more similar to the
JSR). As this is different to far data pointers, you might have to
rotate the bytes.
Basically you can work with far function pointers and with far data
pointers as usual. But when it comes down to assign/cast the two kinds,
you have to care about this (unless you will assign/cast them back
before using them).

here a code snippet which does the swapping:

void (* __far funptr)(void);
void* __far ptr;
/* code snippet to call a far function at a location */
/* which is pointed to by a far data pointer */
*(int*)((char*)&ptr+1) = *(int*)&funptr; /* 16 bit offset */
*(char*)&ptr = *((char*)&funptr+2); /* 8 bit page */
funptr(); So you should end up calling "0x4C0000" for a function which is at 0x004C00.
PS: I would hide this behind a macro.

Another way for you might be to explicitly use near functions and near
function pointers. It looks like your function is in non banked memory
anyway.

Daniel

Bernie Boos wrote:
> I wish I understood this better, but I'll try.
> I'm using the EEPROM NVM functions.
> typedef SGF_RESULT (*pNVMINIT) ( UINT16 oscClock,
> BOOLEAN BDMEnable,
> UINT16 regBase,
> UINT16 pDescriptor,
> UINT16 funcPtr);
> //I declare the function pointers
> pNVMINIT NVMInit;
> // then initialize to the beginning of the function
> NVMInit = (pNVMINIT) NVMInit_C;
> //so NVMInit points to 0x4C00 (as seen in the debugger)
> //Then I call the function
> NVMInit(NVM_CLOCK, FALSE, REGISTER_BASE_ADDRESS, (UINT16)Descriptor,
> (UINT16)RangeCheck_C);
> // and I expect the program to jump to address 0x4C00, but it jumps
> // to 0x004C instead
>
> Sorry I can't be more descriptive, but I have never used the banked
> flash application before and I don't entirely understand how it all
> works.
>
> Bernie
>
> --- In 68HC12@68HC..., "Jefferson Smith" <imajeffs@h...> wrote:
>
>>--- In 68HC12@68HC..., "Bernie Boos" <bernie_boos@h...>
>
> wrote:
>
>>>If I step through the assembly code, it looks like instead of
>
> jumping
>
>>>to the proper 0x004C67 location, it's going to the 0x004C
>
> location...
>
>>>it's not reading all 3 bytes in the location, only the first 2.
>
> Maybe
>
>>>I have an incorrect value in the settings? I'm not sure.
>>>
>>>Thanks in advance,
>>>Bernie
>>
>>I don't see how you are implementing a 24-bit address, which is what
>>it looks like you are saying. What is the instruction that jumps
>
> wrong? > Yahoo! Groups Links >
>




--- In 68HC12@68HC..., Daniel Friededrich <dfriederich@m...>
wrote:
> Hi Bernie,
>
> your problem is that the CALL instruction is not expecting the 24 far
> address in the (for the HC12) usual big endian format. It expects the

Daniel,

I am a GCC programmer, and this is interresting to see how CodeWarrior
(if that's what this is) supports far functions. Is the problem that
the compiler doesn't know how to format the far call, or is this
something wrigged?

GCC avoids this problem by creating a "trampoline" stub so all
pointers are 16-bit. If you jsr to trampoline.funk, it adjusts the
stack, sets ppage, and jumps to the real funk. So when the far funk
returns with rtc, it returns back to the place that called
trampoline.funk.



Thanks Daniel, That is exactly what the problem is.
I tried your code snippet, and it works great, but I am now running
into the same problem when the processor tries to return from the
subroutine...I think. The problem is that the NVM fuctions are only
given as an array of hex numbers.
I guess at this point the simplest question I can ask is:
How can I get the SGF NVM functions to work properly for a banked-
flash application? Is there another set of functions for this
purpose? Or should I be writing my own drivers?

Thanks a bunch, this really shed light on my predicament.

Bernie --- In 68HC12@68HC..., Daniel Friededrich <dfriederich@m...>
wrote:
> Hi Bernie,
>
> your problem is that the CALL instruction is not expecting the 24
far
> address in the (for the HC12) usual big endian format. It expects
the
> page to be behind the 16 bit offset (I guess this made the
> implementation of the CALL instruction simpler, more similar to
the
> JSR). As this is different to far data pointers, you might have to
> rotate the bytes.
> Basically you can work with far function pointers and with far
data
> pointers as usual. But when it comes down to assign/cast the two
kinds,
> you have to care about this (unless you will assign/cast them back
> before using them).
>
> here a code snippet which does the swapping:
>
> void (* __far funptr)(void);
> void* __far ptr;
> /* code snippet to call a far function at a location */
> /* which is pointed to by a far data pointer */
> *(int*)((char*)&ptr+1) = *(int*)&funptr; /* 16 bit offset
*/
> *(char*)&ptr = *((char*)&funptr+2); /* 8 bit page */
> funptr(); > So you should end up calling "0x4C0000" for a function which is at
0x004C00.
> PS: I would hide this behind a macro.
>
> Another way for you might be to explicitly use near functions and
near
> function pointers. It looks like your function is in non banked
memory
> anyway.
>
> Daniel
>
> Bernie Boos wrote:
> > I wish I understood this better, but I'll try.
> > I'm using the EEPROM NVM functions.
> > typedef SGF_RESULT (*pNVMINIT) ( UINT16 oscClock,
> > BOOLEAN BDMEnable,
> > UINT16 regBase,
> > UINT16 pDescriptor,
> > UINT16 funcPtr);
> > //I declare the function pointers
> > pNVMINIT NVMInit;
> > // then initialize to the beginning of the function
> > NVMInit = (pNVMINIT) NVMInit_C;
> > //so NVMInit points to 0x4C00 (as seen in the debugger)
> > //Then I call the function
> > NVMInit(NVM_CLOCK, FALSE, REGISTER_BASE_ADDRESS, (UINT16)
Descriptor,
> > (UINT16)RangeCheck_C);
> > // and I expect the program to jump to address 0x4C00, but it
jumps
> > // to 0x004C instead
> >
> > Sorry I can't be more descriptive, but I have never used the
banked
> > flash application before and I don't entirely understand how it
all
> > works.
> >
> > Bernie
> >
> > --- In 68HC12@68HC..., "Jefferson Smith" <imajeffs@h...>
wrote:
> >
> >>--- In 68HC12@68HC..., "Bernie Boos" <bernie_boos@h...>
> >
> > wrote:
> >
> >>>If I step through the assembly code, it looks like instead of
> >
> > jumping
> >
> >>>to the proper 0x004C67 location, it's going to the 0x004C
> >
> > location...
> >
> >>>it's not reading all 3 bytes in the location, only the first 2.
> >
> > Maybe
> >
> >>>I have an incorrect value in the settings? I'm not sure.
> >>>
> >>>Thanks in advance,
> >>>Bernie
> >>
> >>I don't see how you are implementing a 24-bit address, which is
what
> >>it looks like you are saying. What is the instruction that jumps
> >
> > wrong?
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >



Bernie,

Not sure how much flash you need, but Gilles helped me to get my application
running with 48k of flash (including the window page) in non banked mode
recently using Codewarrior. I basically have a flash window that runs from
$4000 - $FF80 now. The metrowerks drivers were changed to load the area
$8000-BFFF into one of the page windows, and I changed my startup code so
that it loads the relevant page into the PPAGE register. Works fine, and has
none of the overheads of banked mode, and 48k may be enough for your
application.... I figured that 50% increase on the 32k I had previously
would keep me going for a fare while!!

-- Adrian

----- Original Message -----
From: "Bernie Boos" <bernie_boos@bern...>
To: <68HC12@68HC...>
Sent: Thursday, July 28, 2005 7:17 AM
Subject: [68HC12] Re: flash app vs banked flash app > Thanks Daniel, That is exactly what the problem is.
> I tried your code snippet, and it works great, but I am now running
> into the same problem when the processor tries to return from the
> subroutine...I think. The problem is that the NVM fuctions are only
> given as an array of hex numbers.
> I guess at this point the simplest question I can ask is:
> How can I get the SGF NVM functions to work properly for a banked-
> flash application? Is there another set of functions for this
> purpose? Or should I be writing my own drivers?
>
> Thanks a bunch, this really shed light on my predicament.
>
> Bernie > --- In 68HC12@68HC..., Daniel Friededrich <dfriederich@m...>
> wrote:
>> Hi Bernie,
>>
>> your problem is that the CALL instruction is not expecting the 24
> far
>> address in the (for the HC12) usual big endian format. It expects
> the
>> page to be behind the 16 bit offset (I guess this made the
>> implementation of the CALL instruction simpler, more similar to
> the
>> JSR). As this is different to far data pointers, you might have to
>> rotate the bytes.
>> Basically you can work with far function pointers and with far
> data
>> pointers as usual. But when it comes down to assign/cast the two
> kinds,
>> you have to care about this (unless you will assign/cast them back
>> before using them).
>>
>> here a code snippet which does the swapping:
>>
>> void (* __far funptr)(void);
>> void* __far ptr;
>> /* code snippet to call a far function at a location */
>> /* which is pointed to by a far data pointer */
>> *(int*)((char*)&ptr+1) = *(int*)&funptr; /* 16 bit offset
> */
>> *(char*)&ptr = *((char*)&funptr+2); /* 8 bit page */
>> funptr();
>>
>>
>> So you should end up calling "0x4C0000" for a function which is at
> 0x004C00.
>> PS: I would hide this behind a macro.
>>
>> Another way for you might be to explicitly use near functions and
> near
>> function pointers. It looks like your function is in non banked
> memory
>> anyway.
>>
>> Daniel
>>
>> Bernie Boos wrote:
>> > I wish I understood this better, but I'll try.
>> > I'm using the EEPROM NVM functions.
>> > typedef SGF_RESULT (*pNVMINIT) ( UINT16 oscClock,
>> > BOOLEAN BDMEnable,
>> > UINT16 regBase,
>> > UINT16 pDescriptor,
>> > UINT16 funcPtr);
>> > //I declare the function pointers
>> > pNVMINIT NVMInit;
>> > // then initialize to the beginning of the function
>> > NVMInit = (pNVMINIT) NVMInit_C;
>> > //so NVMInit points to 0x4C00 (as seen in the debugger)
>> > //Then I call the function
>> > NVMInit(NVM_CLOCK, FALSE, REGISTER_BASE_ADDRESS, (UINT16)
> Descriptor,
>> > (UINT16)RangeCheck_C);
>> > // and I expect the program to jump to address 0x4C00, but it
> jumps
>> > // to 0x004C instead
>> >
>> > Sorry I can't be more descriptive, but I have never used the
> banked
>> > flash application before and I don't entirely understand how it
> all
>> > works.
>> >
>> > Bernie
>> >
>> > --- In 68HC12@68HC..., "Jefferson Smith" <imajeffs@h...>
> wrote:
>> >
>> >>--- In 68HC12@68HC..., "Bernie Boos" <bernie_boos@h...>
>> >
>> > wrote:
>> >
>> >>>If I step through the assembly code, it looks like instead of
>> >
>> > jumping
>> >
>> >>>to the proper 0x004C67 location, it's going to the 0x004C
>> >
>> > location...
>> >
>> >>>it's not reading all 3 bytes in the location, only the first 2.
>> >
>> > Maybe
>> >
>> >>>I have an incorrect value in the settings? I'm not sure.
>> >>>
>> >>>Thanks in advance,
>> >>>Bernie
>> >>
>> >>I don't see how you are implementing a 24-bit address, which is
> what
>> >>it looks like you are saying. What is the instruction that jumps
>> >
>> > wrong?
>> >
>> >
>> >
>> >
>> >
>> > Yahoo! Groups Links
>> >
>> >
>> >
>> >
>> >
>> >
>> >
> Yahoo! Groups Links

Send instant messages to your online friends http://au.messenger.yahoo.com



Hey Adrian,
I'm sure I wouldn't come even close to 48K, but I want to store
parameters in non-volatile memory so the user doesn't have to re-
enter settings from one job to the next. Do you have that
capability? If so, do you use the NVM functions? Maybe just changing
the offset and size of the "EEPROM" would work.
I'd be really interested to hear how you do this, might be exactly
what I'm looking for.

THanks Adrian,

Bernie Boos
--- In 68HC12@68HC..., "Adrian Vos" <vosadrian@y...> wrote:
> Bernie,
>
> Not sure how much flash you need, but Gilles helped me to get my
application
> running with 48k of flash (including the window page) in non
banked mode
> recently using Codewarrior. I basically have a flash window that
runs from
> $4000 - $FF80 now. The metrowerks drivers were changed to load the
area
> $8000-BFFF into one of the page windows, and I changed my startup
code so
> that it loads the relevant page into the PPAGE register. Works
fine, and has
> none of the overheads of banked mode, and 48k may be enough for
your
> application.... I figured that 50% increase on the 32k I had
previously
> would keep me going for a fare while!!
>
> -- Adrian
>
> ----- Original Message -----
> From: "Bernie Boos" <bernie_boos@h...>
> To: <68HC12@68HC...>
> Sent: Thursday, July 28, 2005 7:17 AM
> Subject: [68HC12] Re: flash app vs banked flash app > > Thanks Daniel, That is exactly what the problem is.
> > I tried your code snippet, and it works great, but I am now
running
> > into the same problem when the processor tries to return from the
> > subroutine...I think. The problem is that the NVM fuctions are
only
> > given as an array of hex numbers.
> > I guess at this point the simplest question I can ask is:
> > How can I get the SGF NVM functions to work properly for a
banked-
> > flash application? Is there another set of functions for this
> > purpose? Or should I be writing my own drivers?
> >
> > Thanks a bunch, this really shed light on my predicament.
> >
> > Bernie
> >
> >
> > --- In 68HC12@68HC..., Daniel Friededrich
<dfriederich@m...>
> > wrote:
> >> Hi Bernie,
> >>
> >> your problem is that the CALL instruction is not expecting the
24
> > far
> >> address in the (for the HC12) usual big endian format. It
expects
> > the
> >> page to be behind the 16 bit offset (I guess this made the
> >> implementation of the CALL instruction simpler, more similar to
> > the
> >> JSR). As this is different to far data pointers, you might have
to
> >> rotate the bytes.
> >> Basically you can work with far function pointers and with far
> > data
> >> pointers as usual. But when it comes down to assign/cast the two
> > kinds,
> >> you have to care about this (unless you will assign/cast them
back
> >> before using them).
> >>
> >> here a code snippet which does the swapping:
> >>
> >> void (* __far funptr)(void);
> >> void* __far ptr;
> >> /* code snippet to call a far function at a location */
> >> /* which is pointed to by a far data pointer */
> >> *(int*)((char*)&ptr+1) = *(int*)&funptr; /* 16 bit
offset
> > */
> >> *(char*)&ptr = *((char*)&funptr+2); /* 8 bit page */
> >> funptr();
> >>
> >>
> >> So you should end up calling "0x4C0000" for a function which is
at
> > 0x004C00.
> >> PS: I would hide this behind a macro.
> >>
> >> Another way for you might be to explicitly use near functions
and
> > near
> >> function pointers. It looks like your function is in non banked
> > memory
> >> anyway.
> >>
> >> Daniel
> >>
> >> Bernie Boos wrote:
> >> > I wish I understood this better, but I'll try.
> >> > I'm using the EEPROM NVM functions.
> >> > typedef SGF_RESULT (*pNVMINIT) ( UINT16 oscClock,
> >> > BOOLEAN BDMEnable,
> >> > UINT16 regBase,
> >> > UINT16 pDescriptor,
> >> > UINT16 funcPtr);
> >> > //I declare the function pointers
> >> > pNVMINIT NVMInit;
> >> > // then initialize to the beginning of the function
> >> > NVMInit = (pNVMINIT) NVMInit_C;
> >> > //so NVMInit points to 0x4C00 (as seen in the debugger)
> >> > //Then I call the function
> >> > NVMInit(NVM_CLOCK, FALSE, REGISTER_BASE_ADDRESS, (UINT16)
> > Descriptor,
> >> > (UINT16)RangeCheck_C);
> >> > // and I expect the program to jump to address 0x4C00, but it
> > jumps
> >> > // to 0x004C instead
> >> >
> >> > Sorry I can't be more descriptive, but I have never used the
> > banked
> >> > flash application before and I don't entirely understand how
it
> > all
> >> > works.
> >> >
> >> > Bernie
> >> >
> >> > --- In 68HC12@68HC..., "Jefferson Smith"
<imajeffs@h...>
> > wrote:
> >> >
> >> >>--- In 68HC12@68HC..., "Bernie Boos"
<bernie_boos@h...>
> >> >
> >> > wrote:
> >> >
> >> >>>If I step through the assembly code, it looks like instead of
> >> >
> >> > jumping
> >> >
> >> >>>to the proper 0x004C67 location, it's going to the 0x004C
> >> >
> >> > location...
> >> >
> >> >>>it's not reading all 3 bytes in the location, only the first
2.
> >> >
> >> > Maybe
> >> >
> >> >>>I have an incorrect value in the settings? I'm not sure.
> >> >>>
> >> >>>Thanks in advance,
> >> >>>Bernie
> >> >>
> >> >>I don't see how you are implementing a 24-bit address, which
is
> > what
> >> >>it looks like you are saying. What is the instruction that
jumps
> >> >
> >> > wrong?
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > Yahoo! Groups Links
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
>
> Send instant messages to your online friends
http://au.messenger.yahoo.com


Hi Bernie,

I have the S12DP256 with the following setup (have copyed and edited my PRM
file below as I have some other stuff that may be confusing):

RAM = 0x1000 TO 0x3FFF (including stack in this area)
EEPROM = 0x4000 TO 0x4FFF (4k of NV memory relocated in the EEINIT register)
FLASH = 0x5000 TO 0xFEFF (Approx 44k of flash rom)

I use the EEPROM to store data... not code. I have never run code from this
area, but I am sure that it could easily be done if this is what you want to
do, though I don;t understand why. I wrote my own code to write to the
EEPROM. I do not use any off the shelf NVM functions, but again, I am sure
it can be done. It is not hard to relocate various memory modules and resize
them if necessary using the registers in the MMC module.

I think this method of getting some extra code may be less trouble than the
banked mode method. All I need to do to enable this was get the driver file
from Gilles, change my PRM file to refect using the 8000-BFFF window, and
set the PPAGE register in the startup routine, and make sure that the
startup routine live in an area of flash that is not in the $8000-BFFF area.
I actually made a seperate section in the PRM file for the startup routines,
and located it at the back of the flash space.

-- Adrian ----- Original Message -----
From: "Bernie Boos" <bernie_boos@bern...>
To: <68HC12@68HC...>
Sent: Thursday, July 28, 2005 10:00 AM
Subject: [68HC12] Re: flash app vs banked flash app > Hey Adrian,
> I'm sure I wouldn't come even close to 48K, but I want to store
> parameters in non-volatile memory so the user doesn't have to re-
> enter settings from one job to the next. Do you have that
> capability? If so, do you use the NVM functions? Maybe just changing
> the offset and size of the "EEPROM" would work.
> I'd be really interested to hear how you do this, might be exactly
> what I'm looking for.
>
> THanks Adrian,
>
> Bernie Boos >
> --- In 68HC12@68HC..., "Adrian Vos" <vosadrian@y...> wrote:
>> Bernie,
>>
>> Not sure how much flash you need, but Gilles helped me to get my
> application
>> running with 48k of flash (including the window page) in non
> banked mode
>> recently using Codewarrior. I basically have a flash window that
> runs from
>> $4000 - $FF80 now. The metrowerks drivers were changed to load the
> area
>> $8000-BFFF into one of the page windows, and I changed my startup
> code so
>> that it loads the relevant page into the PPAGE register. Works
> fine, and has
>> none of the overheads of banked mode, and 48k may be enough for
> your
>> application.... I figured that 50% increase on the 32k I had
> previously
>> would keep me going for a fare while!!
>>
>> -- Adrian
>>
>> ----- Original Message -----
>> From: "Bernie Boos" <bernie_boos@h...>
>> To: <68HC12@68HC...>
>> Sent: Thursday, July 28, 2005 7:17 AM
>> Subject: [68HC12] Re: flash app vs banked flash app
>>
>>
>> > Thanks Daniel, That is exactly what the problem is.
>> > I tried your code snippet, and it works great, but I am now
> running
>> > into the same problem when the processor tries to return from the
>> > subroutine...I think. The problem is that the NVM fuctions are
> only
>> > given as an array of hex numbers.
>> > I guess at this point the simplest question I can ask is:
>> > How can I get the SGF NVM functions to work properly for a
> banked-
>> > flash application? Is there another set of functions for this
>> > purpose? Or should I be writing my own drivers?
>> >
>> > Thanks a bunch, this really shed light on my predicament.
>> >
>> > Bernie
>> >
>> >
>> > --- In 68HC12@68HC..., Daniel Friededrich
> <dfriederich@m...>
>> > wrote:
>> >> Hi Bernie,
>> >>
>> >> your problem is that the CALL instruction is not expecting the
> 24
>> > far
>> >> address in the (for the HC12) usual big endian format. It
> expects
>> > the
>> >> page to be behind the 16 bit offset (I guess this made the
>> >> implementation of the CALL instruction simpler, more similar to
>> > the
>> >> JSR). As this is different to far data pointers, you might have
> to
>> >> rotate the bytes.
>> >> Basically you can work with far function pointers and with far
>> > data
>> >> pointers as usual. But when it comes down to assign/cast the two
>> > kinds,
>> >> you have to care about this (unless you will assign/cast them
> back
>> >> before using them).
>> >>
>> >> here a code snippet which does the swapping:
>> >>
>> >> void (* __far funptr)(void);
>> >> void* __far ptr;
>> >> /* code snippet to call a far function at a location */
>> >> /* which is pointed to by a far data pointer */
>> >> *(int*)((char*)&ptr+1) = *(int*)&funptr; /* 16 bit
> offset
>> > */
>> >> *(char*)&ptr = *((char*)&funptr+2); /* 8 bit page */
>> >> funptr();
>> >>
>> >>
>> >> So you should end up calling "0x4C0000" for a function which is
> at
>> > 0x004C00.
>> >> PS: I would hide this behind a macro.
>> >>
>> >> Another way for you might be to explicitly use near functions
> and
>> > near
>> >> function pointers. It looks like your function is in non banked
>> > memory
>> >> anyway.
>> >>
>> >> Daniel
>> >>
>> >> Bernie Boos wrote:
>> >> > I wish I understood this better, but I'll try.
>> >> > I'm using the EEPROM NVM functions.
>> >> > typedef SGF_RESULT (*pNVMINIT) ( UINT16 oscClock,
>> >> > BOOLEAN BDMEnable,
>> >> > UINT16 regBase,
>> >> > UINT16 pDescriptor,
>> >> > UINT16 funcPtr);
>> >> > //I declare the function pointers
>> >> > pNVMINIT NVMInit;
>> >> > // then initialize to the beginning of the function
>> >> > NVMInit = (pNVMINIT) NVMInit_C;
>> >> > //so NVMInit points to 0x4C00 (as seen in the debugger)
>> >> > //Then I call the function
>> >> > NVMInit(NVM_CLOCK, FALSE, REGISTER_BASE_ADDRESS, (UINT16)
>> > Descriptor,
>> >> > (UINT16)RangeCheck_C);
>> >> > // and I expect the program to jump to address 0x4C00, but it
>> > jumps
>> >> > // to 0x004C instead
>> >> >
>> >> > Sorry I can't be more descriptive, but I have never used the
>> > banked
>> >> > flash application before and I don't entirely understand how
> it
>> > all
>> >> > works.
>> >> >
>> >> > Bernie
>> >> >
>> >> > --- In 68HC12@68HC..., "Jefferson Smith"
> <imajeffs@h...>
>> > wrote:
>> >> >
>> >> >>--- In 68HC12@68HC..., "Bernie Boos"
> <bernie_boos@h...>
>> >> >
>> >> > wrote:
>> >> >
>> >> >>>If I step through the assembly code, it looks like instead of
>> >> >
>> >> > jumping
>> >> >
>> >> >>>to the proper 0x004C67 location, it's going to the 0x004C
>> >> >
>> >> > location...
>> >> >
>> >> >>>it's not reading all 3 bytes in the location, only the first
> 2.
>> >> >
>> >> > Maybe
>> >> >
>> >> >>>I have an incorrect value in the settings? I'm not sure.
>> >> >>>
>> >> >>>Thanks in advance,
>> >> >>>Bernie
>> >> >>
>> >> >>I don't see how you are implementing a 24-bit address, which
> is
>> > what
>> >> >>it looks like you are saying. What is the instruction that
> jumps
>> >> >
>> >> > wrong?
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > Yahoo! Groups Links
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Yahoo! Groups Links
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>> Send instant messages to your online friends
> http://au.messenger.yahoo.com > Yahoo! Groups Links >
>

Send instant messages to your online friends http://au.messenger.yahoo.com



Adrian
I misunderstood you. I thought you were using the EEPROM space for
code. What you are describing is exactly what I need. I don't think
I will add more than 4 or 5K more code.
How can I find out more information about doing this?

Thanks Adrian and everyone else that helped me with this problem.

Bernie

--- In 68HC12@68HC..., "Adrian Vos" <vosadrian@y...> wrote:
> Hi Bernie,
>
> I have the S12DP256 with the following setup (have copyed and
edited my PRM
> file below as I have some other stuff that may be confusing):
>
> RAM = 0x1000 TO 0x3FFF (including stack in this area)
> EEPROM = 0x4000 TO 0x4FFF (4k of NV memory relocated in the EEINIT
register)
> FLASH = 0x5000 TO 0xFEFF (Approx 44k of flash rom)
>
> I use the EEPROM to store data... not code. I have never run code
from this
> area, but I am sure that it could easily be done if this is what
you want to
> do, though I don;t understand why. I wrote my own code to write to
the
> EEPROM. I do not use any off the shelf NVM functions, but again, I
am sure
> it can be done. It is not hard to relocate various memory modules
and resize
> them if necessary using the registers in the MMC module.
>
> I think this method of getting some extra code may be less trouble
than the
> banked mode method. All I need to do to enable this was get the
driver file
> from Gilles, change my PRM file to refect using the 8000-BFFF
window, and
> set the PPAGE register in the startup routine, and make sure that
the
> startup routine live in an area of flash that is not in the $8000-
BFFF area.
> I actually made a seperate section in the PRM file for the startup
routines,
> and located it at the back of the flash space.
>
> -- Adrian > ----- Original Message -----
> From: "Bernie Boos" <bernie_boos@h...>
> To: <68HC12@68HC...>
> Sent: Thursday, July 28, 2005 10:00 AM
> Subject: [68HC12] Re: flash app vs banked flash app > > Hey Adrian,
> > I'm sure I wouldn't come even close to 48K, but I want to store
> > parameters in non-volatile memory so the user doesn't have to re-
> > enter settings from one job to the next. Do you have that
> > capability? If so, do you use the NVM functions? Maybe just
changing
> > the offset and size of the "EEPROM" would work.
> > I'd be really interested to hear how you do this, might be
exactly
> > what I'm looking for.
> >
> > THanks Adrian,
> >
> > Bernie Boos
> >
> >
> >
> > --- In 68HC12@68HC..., "Adrian Vos" <vosadrian@y...>
wrote:
> >> Bernie,
> >>
> >> Not sure how much flash you need, but Gilles helped me to get my
> > application
> >> running with 48k of flash (including the window page) in non
> > banked mode
> >> recently using Codewarrior. I basically have a flash window that
> > runs from
> >> $4000 - $FF80 now. The metrowerks drivers were changed to load
the
> > area
> >> $8000-BFFF into one of the page windows, and I changed my
startup
> > code so
> >> that it loads the relevant page into the PPAGE register. Works
> > fine, and has
> >> none of the overheads of banked mode, and 48k may be enough for
> > your
> >> application.... I figured that 50% increase on the 32k I had
> > previously
> >> would keep me going for a fare while!!
> >>
> >> -- Adrian
> >>
> >> ----- Original Message -----
> >> From: "Bernie Boos" <bernie_boos@h...>
> >> To: <68HC12@68HC...>
> >> Sent: Thursday, July 28, 2005 7:17 AM
> >> Subject: [68HC12] Re: flash app vs banked flash app
> >>
> >>
> >> > Thanks Daniel, That is exactly what the problem is.
> >> > I tried your code snippet, and it works great, but I am now
> > running
> >> > into the same problem when the processor tries to return from
the
> >> > subroutine...I think. The problem is that the NVM fuctions are
> > only
> >> > given as an array of hex numbers.
> >> > I guess at this point the simplest question I can ask is:
> >> > How can I get the SGF NVM functions to work properly for a
> > banked-
> >> > flash application? Is there another set of functions for this
> >> > purpose? Or should I be writing my own drivers?
> >> >
> >> > Thanks a bunch, this really shed light on my predicament.
> >> >
> >> > Bernie
> >> >
> >> >
> >> > --- In 68HC12@68HC..., Daniel Friededrich
> > <dfriederich@m...>
> >> > wrote:
> >> >> Hi Bernie,
> >> >>
> >> >> your problem is that the CALL instruction is not expecting
the
> > 24
> >> > far
> >> >> address in the (for the HC12) usual big endian format. It
> > expects
> >> > the
> >> >> page to be behind the 16 bit offset (I guess this made the
> >> >> implementation of the CALL instruction simpler, more similar
to
> >> > the
> >> >> JSR). As this is different to far data pointers, you might
have
> > to
> >> >> rotate the bytes.
> >> >> Basically you can work with far function pointers and with
far
> >> > data
> >> >> pointers as usual. But when it comes down to assign/cast the
two
> >> > kinds,
> >> >> you have to care about this (unless you will assign/cast them
> > back
> >> >> before using them).
> >> >>
> >> >> here a code snippet which does the swapping:
> >> >>
> >> >> void (* __far funptr)(void);
> >> >> void* __far ptr;
> >> >> /* code snippet to call a far function at a
location */
> >> >> /* which is pointed to by a far data pointer */
> >> >> *(int*)((char*)&ptr+1) = *(int*)&funptr; /* 16 bit
> > offset
> >> > */
> >> >> *(char*)&ptr = *((char*)&funptr+2); /* 8 bit page */
> >> >> funptr();
> >> >>
> >> >>
> >> >> So you should end up calling "0x4C0000" for a function which
is
> > at
> >> > 0x004C00.
> >> >> PS: I would hide this behind a macro.
> >> >>
> >> >> Another way for you might be to explicitly use near functions
> > and
> >> > near
> >> >> function pointers. It looks like your function is in non
banked
> >> > memory
> >> >> anyway.
> >> >>
> >> >> Daniel
> >> >>
> >> >> Bernie Boos wrote:
> >> >> > I wish I understood this better, but I'll try.
> >> >> > I'm using the EEPROM NVM functions.
> >> >> > typedef SGF_RESULT (*pNVMINIT) ( UINT16 oscClock,
> >> >> > BOOLEAN BDMEnable,
> >> >> > UINT16 regBase,
> >> >> > UINT16 pDescriptor,
> >> >> > UINT16 funcPtr);
> >> >> > //I declare the function pointers
> >> >> > pNVMINIT NVMInit;
> >> >> > // then initialize to the beginning of the function
> >> >> > NVMInit = (pNVMINIT) NVMInit_C;
> >> >> > //so NVMInit points to 0x4C00 (as seen in the debugger)
> >> >> > //Then I call the function
> >> >> > NVMInit(NVM_CLOCK, FALSE, REGISTER_BASE_ADDRESS, (UINT16)
> >> > Descriptor,
> >> >> > (UINT16)RangeCheck_C);
> >> >> > // and I expect the program to jump to address 0x4C00, but
it
> >> > jumps
> >> >> > // to 0x004C instead
> >> >> >
> >> >> > Sorry I can't be more descriptive, but I have never used
the
> >> > banked
> >> >> > flash application before and I don't entirely understand
how
> > it
> >> > all
> >> >> > works.
> >> >> >
> >> >> > Bernie
> >> >> >
> >> >> > --- In 68HC12@68HC..., "Jefferson Smith"
> > <imajeffs@h...>
> >> > wrote:
> >> >> >
> >> >> >>--- In 68HC12@68HC..., "Bernie Boos"
> > <bernie_boos@h...>
> >> >> >
> >> >> > wrote:
> >> >> >
> >> >> >>>If I step through the assembly code, it looks like
instead of
> >> >> >
> >> >> > jumping
> >> >> >
> >> >> >>>to the proper 0x004C67 location, it's going to the 0x004C
> >> >> >
> >> >> > location...
> >> >> >
> >> >> >>>it's not reading all 3 bytes in the location, only the
first
> > 2.
> >> >> >
> >> >> > Maybe
> >> >> >
> >> >> >>>I have an incorrect value in the settings? I'm not sure.
> >> >> >>>
> >> >> >>>Thanks in advance,
> >> >> >>>Bernie
> >> >> >>
> >> >> >>I don't see how you are implementing a 24-bit address,
which
> > is
> >> > what
> >> >> >>it looks like you are saying. What is the instruction that
> > jumps
> >> >> >
> >> >> > wrong?
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > Yahoo! Groups Links
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > Yahoo! Groups Links
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >> Send instant messages to your online friends
> > http://au.messenger.yahoo.com
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
>
> Send instant messages to your online friends
http://au.messenger.yahoo.com