Sign in
Search 68hc12
Subscribe to 68hc12
68hc12 by Keywords
68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC
Sponsor
Ads
Discussion Groups
See Also
Discussion Groups | 68HC12 | flash app vs banked flash app
Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
flash app vs banked flash app - Bernie Boos - Jul 26 17:42:00 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
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
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
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: flash app vs banked flash app - Jefferson Smith - Jul 26 19:14:00 2005
--- 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?
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
> 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?
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: flash app vs banked flash app - Bernie Boos - Jul 26 20:16:00 2005
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?
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
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?
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: flash app vs banked flash app - Daniel Friededrich - Jul 27 5:12:00 2005
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
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
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
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: flash app vs banked flash app - Jefferson Smith - Jul 27 9:52:00 2005
--- 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.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
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.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: flash app vs banked flash app - Bernie Boos - Jul 27 17:17:00 2005
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
> >
> >
> >
> >
> >
> >
>
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
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
> >
> >
> >
> >
> >
> >
>
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: flash app vs banked flash app - Adrian Vos - Jul 27 19:49:00 2005
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
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
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
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: flash app vs banked flash app - Bernie Boos - Jul 27 20:00:00 2005
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
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
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
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: flash app vs banked flash app - Adrian Vos - Jul 27 20:15:00 2005
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
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
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
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: flash app vs banked flash app - Bernie Boos - Jul 28 10:04:00 2005
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
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
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
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: flash app vs banked flash app - Adrian Vos - Jul 28 20:58:00 2005
Bernie,
I recommend you contact Gilles on this list to get the right driver for you
version of codewarrior.
Cheers,
Adrian
----- Original Message -----
From: "Bernie Boos" <bernie_boos@bern...>
To: <68HC12@68HC...>
Sent: Friday, July 29, 2005 12:04 AM
Subject: [68HC12] Re: flash app vs banked flash app > 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 > Yahoo! Groups Links Send instant messages to your online friends http://au.messenger.yahoo.com
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
I recommend you contact Gilles on this list to get the right driver for you
version of codewarrior.
Cheers,
Adrian
----- Original Message -----
From: "Bernie Boos" <bernie_boos@bern...>
To: <68HC12@68HC...>
Sent: Friday, July 29, 2005 12:04 AM
Subject: [68HC12] Re: flash app vs banked flash app > 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 > Yahoo! Groups Links Send instant messages to your online friends http://au.messenger.yahoo.com
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: flash app vs banked flash app - Bernie Boos - Aug 4 15:07:00 2005
Adrian,
I was reading your message (below) and you say:
"I 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"
Can you tell me what you did to the PPAGE register in the startup
routine? Did you have to make any other changes?
I noticed in my code that it jumps to the 0xBXXX area and there is
no code located there. I thought it might have soemthing to do with
the fact that I didn't change anything in my startup routine.
I added the section to isolate the startup code, and that seems to
work fine.
Thanks Adrian
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
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
I was reading your message (below) and you say:
"I 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"
Can you tell me what you did to the PPAGE register in the startup
routine? Did you have to make any other changes?
I noticed in my code that it jumps to the 0xBXXX area and there is
no code located there. I thought it might have soemthing to do with
the fact that I didn't change anything in my startup routine.
I added the section to isolate the startup code, and that seems to
work fine.
Thanks Adrian
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
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: flash app vs banked flash app - Adrian Vos - Aug 4 19:56:00 2005
Hi Bernie,
I really did not have much difficulty getting this running, so I hope I
havn't sent you up a path that is more difficult than the path you were on
with banked mode.
I removed the startup code provided by metrowerks, and redefined the various
reset vectors to store data about what caused the reset and than jump to my
own startup code which is below:
#pragma MESSAGE DISABLE C12053 // Stack-pointer change not in
debugging-information
INIT_SP_FROM_STARTUP_DESC(); // Init Stack Pointer (Macro)
InitCRG(); // Set Processor speed (All Code in protected
memory)
ZeroGeneralRam(); // Set all general ram to 0 (All Code in
protected memory)
PPAGE = 0x3D; // Set page $3D as the page window as main firmware
in this page
After this, I am into general code. Note that Gilles made a verison of the
driver from me that uses page $3D as this suits my application better as it
puts all the flash on the same page which is better for my bootloader code.
Cheers,
Adrian
----- Original Message -----
From: "Bernie Boos" <bernie_boos@bern...>
To: <68HC12@68HC...>
Sent: Friday, August 05, 2005 5:07 AM
Subject: [68HC12] Re: flash app vs banked flash app > Adrian,
> I was reading your message (below) and you say:
>
> "I 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"
>
> Can you tell me what you did to the PPAGE register in the startup
> routine? Did you have to make any other changes?
>
> I noticed in my code that it jumps to the 0xBXXX area and there is
> no code located there. I thought it might have soemthing to do with
> the fact that I didn't change anything in my startup routine.
>
> I added the section to isolate the startup code, and that seems to
> work fine.
>
> Thanks Adrian
> 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 >
> Yahoo! Groups Links >
Send instant messages to your online friends http://au.messenger.yahoo.com
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
I really did not have much difficulty getting this running, so I hope I
havn't sent you up a path that is more difficult than the path you were on
with banked mode.
I removed the startup code provided by metrowerks, and redefined the various
reset vectors to store data about what caused the reset and than jump to my
own startup code which is below:
#pragma MESSAGE DISABLE C12053 // Stack-pointer change not in
debugging-information
INIT_SP_FROM_STARTUP_DESC(); // Init Stack Pointer (Macro)
InitCRG(); // Set Processor speed (All Code in protected
memory)
ZeroGeneralRam(); // Set all general ram to 0 (All Code in
protected memory)
PPAGE = 0x3D; // Set page $3D as the page window as main firmware
in this page
After this, I am into general code. Note that Gilles made a verison of the
driver from me that uses page $3D as this suits my application better as it
puts all the flash on the same page which is better for my bootloader code.
Cheers,
Adrian
----- Original Message -----
From: "Bernie Boos" <bernie_boos@bern...>
To: <68HC12@68HC...>
Sent: Friday, August 05, 2005 5:07 AM
Subject: [68HC12] Re: flash app vs banked flash app > Adrian,
> I was reading your message (below) and you say:
>
> "I 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"
>
> Can you tell me what you did to the PPAGE register in the startup
> routine? Did you have to make any other changes?
>
> I noticed in my code that it jumps to the 0xBXXX area and there is
> no code located there. I thought it might have soemthing to do with
> the fact that I didn't change anything in my startup routine.
>
> I added the section to isolate the startup code, and that seems to
> work fine.
>
> Thanks Adrian
> 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 >
> Yahoo! Groups Links >
Send instant messages to your online friends http://au.messenger.yahoo.com
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )