Re: HC912DG128A : bootloader in non-banked memory ?

Started by wz24 April 25, 2006
Hi, David and all,

I have a similar situation as discussed in this tread. I would like
to have a bootloader that resides in page 0x3C-0x3F(bank 0) of a
9S12DP256B MCU. One part of the application firmware that the
bootloader tries to load resides in non-banked page 0x3E of the same
bank.

>From reading the Freescale flash memory spec S12FTS256KV2.pdf, I got
the impression you can program page -0x3E of bank 0 from a different
bank, say bank 3(page 0x30). So I designed my boot loader
in a way that I would have two copies of function code that do
flash_erase and flash_write, one copy are in page 0x30 of bank 3 and
the other in page 0x3F of bank 0. Then in the bootloader, I would
'@far call' the copy in bank 3 to program page 0x3E and '@near call'
the copy in bank 0 to program addresses in bank 1, 2 and 3.

Somehow the code is not working while programming page 0x3E. Could
someone help to confirm if this solution should work or I am missing
something.

Thanks.

--Wenji
--- In 6..., David Wild wrote:
>
> I am digging back in memory here so this may not be 100%. I made my
bootloader lie in f800 to ffff and I did not use any pcr addressing.
for the pseudovector table I simply did something along the lines of
(in pseudocode)
>
> FFDO:
> ldx FFD0 - BOOTBLOCKSIZE
> jmp 0,x
>
> I did one of these labels and offsets for each possible interrupt.
>
> For the Flash writing routines, instead of using PCR, I simply
wrote it carefully in a fashion that would allow a jump to that
address in RAM (where the routine would be copied to) and then,
within that routine, used all relative addressing. Before I jumped to
ram I woudl save the PC on the stack. At the end of the routine I
think I simply popped the top of the stack into the program counter
to return to FLASH. I would have to double check but if I recall,
that is pretty close to what I did.
>
> Easier than it sounds I am sure. :)
>
> ----
> From: y.sevin@...
> Sent: December 15, 2005 2:56 PM
> To: 6...
> Subject: RE: [68HC12] HC912DG128A : bootloader in non-banked
memory ?
>
> I'd like to program only one part but apparently, some sections
used by the
> assembler must be in the same part than the bootloader (see my
first post).
> I'm trying to use the bootloader without copying it in RAM because
the examples
> I've found use "pcr" or relative addressing mode and my assembler
fails with
> that. The bootloader is in assembler and I put it in a C program by
using the
> "asm" command. I have a lot of label addressing mode errors or
something like
> this.
> Do I have to put the bootloader in an asm file, then assembly it
and then
> include it in the main project with the C program ?
>
> > The DG128 has two blocks. You can run a program in one block to
program the
> > other block. However, if you want to program parts of the same
block that
> > the bootlader is in then you have to be running the code from
RAM. When I
> > created a bootloader I simply copied the few small writing
routines into RAM
> > rather than the entire bootloader.
> >
> >
> >
> > -----Original Message-----
> > From: 6... [mailto:6...] On
Behalf Of
> > y.sevin@...
> > Sent: Thursday, December 15, 2005 9:16 AM
> > To: 6...
> > Subject: RE: [68HC12] HC912DG128A : bootloader in non-banked
memory ?
> >
> > AN2166 is about erasing and programming flash EEPROM on DG128A
and explains
> > that you can run a program in non-banked memory to erase or flash
banked
> > memory.
> > So why not a bootloader ?
> >
> >
> >
> > > you should look at the Serial Bootloader from Freescale AN2153.
The
> > > document explains how he built the bootloader and why you need
to move
> > > it to move the bootloader to RAM. You will also find the SW
files within
> > AN2153_SW.
> > >
> > > _____
> > >
> > > From: 6... [mailto:6...] On
Behalf
> > > Of
> > > yann_37
> > > Sent: December 15, 2005 9:16 AM
> > > To: 6...
> > > Subject: [68HC12] HC912DG128A : bootloader in non-banked
memory ?
> > >
> > >
> > > Hello,
> > > I'm working on a HC912DG128A.
> > > Apparently, it is possible to put a bootloader in the non-banked
> > > memory ($4000-$7FFF and $C000-$FFFF). You can also erase and
program
> > > banked memory (6 pages from $8000-$BFFF).
> > > My problem is about the predefined sections that must be in non-
banked
> > > memory : ROM_VAR (application constant variables), STRINGS
> > > (application string constants), COPY (initialization values for
the
> > > application variables).
> > > If the new code that the bootloader will put in flash memory
contains
> > > new variables, it will create changes in these sections, so it
won't
> > > work ?
> > > Is it possible to put these sections in banked memory ?
> > > Does anybody have a solution ?
> > > Am I obliged to copy and run the bootloader in RAM ?
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > SPONSORED LINKS
> > > Freescale
> > > > > eescal
> > >
e+semiconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w45
> > > e+semiconductor+1+micr
> > > oprocessor&c=4&s6&.sig=K2HGv-zFlv5OYUv_QxIq_Q> semiconductor
inc
> > > Microcontrollers
> > > > > icondu
> > >
ctor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microproc
> > > ctor+essor&
> > > c=4&s6&.sig=SYHwNJjjGQXRvtt_GybT4g> Pic
> > > > > +semic
> > >
onductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+micro
> > > onductor+proces
> > > sor&c=4&s6&.sig=umVbbnUwsPzEzKKD_pQfUw> microcontrollers
> > > 8051
> > > > > semico
> > >
nductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microp
> > > nductor+rocess
> > > or&c=4&s6&.sig=NO-nSKjHoAlh9XtZ8LB1_A> microprocessor
> > >
> > > _____
> > >
> > >
Wenji,

Some suggestions below.

Steve Russell
Nohau Emulators

At 12:45 PM 4/25/2006, wz24 wrote:
>Hi, David and all,
>
>I have a similar situation as discussed in this tread. I would like
>to have a bootloader that resides in page 0x3C-0x3F(bank 0) of a
>9S12DP256B MCU. One part of the application firmware that the
>bootloader tries to load resides in non-banked page 0x3E of the same
>bank.
>
> >From reading the Freescale flash memory spec S12FTS256KV2.pdf, I got
>the impression you can program page -0x3E of bank 0 from a different
>bank, say bank 3(page 0x30). So I designed my boot loader
>in a way that I would have two copies of function code that do
>flash_erase and flash_write, one copy are in page 0x30 of bank 3 and
>the other in page 0x3F of bank 0. Then in the bootloader, I would
>'@far call' the copy in bank 3 to program page 0x3E and '@near call'
>the copy in bank 0 to program addresses in bank 1, 2 and 3.
>
>Somehow the code is not working while programming page 0x3E. Could
>someone help to confirm if this solution should work or I am missing
>something.

It sounds like there might be a fight over the contents of the PPAGE
register.

This register controls which page the CPU executes instructions from in the
flash window from 0x8000 through 0xBFFF, AND it also controls which flash
is selected for programming. This means that if you are attempting to
program page 3E in the flash window, you cannot execute instructions from
that window.

The @near call and @far call just control whether the function call sets
PPAGE appropriately to the function address.

Since page 0x30 is can only be addressed in the flash window, you must set
PPAGE to 0x30 to execute any function in page 0x30. This means that a
programming algorithm running entirely in page 0x30 cannot program other
pages because of the conflict over PPAGE for program execution AND to
select the flash page.

The way to overcome this is to have the actual sequence of instructions
that does the setting of PPAGE and flash programming in RAM so that PPAGE
can have any value without disturbing the program operation.

In the archives there are discussions of two ways to do this: One is to
cleverly cause the right code to be in a local array, which will be on the
stack which has to be in RAM; The other is to explicitly compile some code
to be position independent or to execute at a fixed location in RAM, and
transfer that code from flash to RAM to execute.

Bootstrap loaders always seem to end up with these and many more
complications. They're hard to get right, and its hard to figure out
what's wrong.

Keep trying! Good luck!

>Thanks.
>
>--Wenji
>--- In 6..., David Wild wrote:
> >
> > I am digging back in memory here so this may not be 100%. I made my
>bootloader lie in f800 to ffff and I did not use any pcr addressing.
>for the pseudovector table I simply did something along the lines of
>(in pseudocode)
> >
> > FFDO:
> > ldx FFD0 - BOOTBLOCKSIZE
> > jmp 0,x
> >
> > I did one of these labels and offsets for each possible interrupt.
> >
> > For the Flash writing routines, instead of using PCR, I simply
>wrote it carefully in a fashion that would allow a jump to that
>address in RAM (where the routine would be copied to) and then,
>within that routine, used all relative addressing. Before I jumped to
>ram I woudl save the PC on the stack. At the end of the routine I
>think I simply popped the top of the stack into the program counter
>to return to FLASH. I would have to double check but if I recall,
>that is pretty close to what I did.
> >
> > Easier than it sounds I am sure. :)
> >
> > ----
> > From: y.sevin@...
> > Sent: December 15, 2005 2:56 PM
> > To: 6...
> > Subject: RE: [68HC12] HC912DG128A : bootloader in non-banked
>memory ?
> >
> > I'd like to program only one part but apparently, some sections
>used by the
> > assembler must be in the same part than the bootloader (see my
>first post).
> > I'm trying to use the bootloader without copying it in RAM because
>the examples
> > I've found use "pcr" or relative addressing mode and my assembler
>fails with
> > that. The bootloader is in assembler and I put it in a C program by
>using the
> > "asm" command. I have a lot of label addressing mode errors or
>something like
> > this.
> > Do I have to put the bootloader in an asm file, then assembly it
>and then
> > include it in the main project with the C program ?
> >
> > > The DG128 has two blocks. You can run a program in one block to
>program the
> > > other block. However, if you want to program parts of the same
>block that
> > > the bootlader is in then you have to be running the code from
>RAM. When I
> > > created a bootloader I simply copied the few small writing
>routines into RAM
> > > rather than the entire bootloader.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: 6... [mailto:6...] On
>Behalf Of
> > > y.sevin@...
> > > Sent: Thursday, December 15, 2005 9:16 AM
> > > To: 6...
> > > Subject: RE: [68HC12] HC912DG128A : bootloader in non-banked
>memory ?
> > >
> > > AN2166 is about erasing and programming flash EEPROM on DG128A
>and explains
> > > that you can run a program in non-banked memory to erase or flash
>banked
> > > memory.
> > > So why not a bootloader ?
> > >
> > >
> > >
> > > > you should look at the Serial Bootloader from Freescale AN2153.
>The
> > > > document explains how he built the bootloader and why you need
>to move
> > > > it to move the bootloader to RAM. You will also find the SW
>files within
> > > AN2153_SW.
> > > >
> > > > _____
> > > >
> > > > From: 6... [mailto:6...] On
>Behalf
> > > > Of
> > > > yann_37
> > > > Sent: December 15, 2005 9:16 AM
> > > > To: 6...
> > > > Subject: [68HC12] HC912DG128A : bootloader in non-banked
>memory ?
> > > >
> > > >
> > > > Hello,
> > > > I'm working on a HC912DG128A.
> > > > Apparently, it is possible to put a bootloader in the non-banked
> > > > memory ($4000-$7FFF and $C000-$FFFF). You can also erase and
>program
> > > > banked memory (6 pages from $8000-$BFFF).
> > > > My problem is about the predefined sections that must be in non-
>banked
> > > > memory : ROM_VAR (application constant variables), STRINGS
> > > > (application string constants), COPY (initialization values for
>the
> > > > application variables).
> > > > If the new code that the bootloader will put in flash memory
>contains
> > > > new variables, it will create changes in these sections, so it
>won't
> > > > work ?
> > > > Is it possible to put these sections in banked memory ?
> > > > Does anybody have a solution ?
> > > > Am I obliged to copy and run the bootloader in RAM ?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > SPONSORED LINKS
> > > > Freescale
> > > > > > eescal
> > > >
>e+semiconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w45
> > > > e+semiconductor+1+micr
> > > > oprocessor&c=4&s6&.sig=K2HGv-zFlv5OYUv_QxIq_Q> semiconductor
>inc
> > > > Microcontrollers
> > > > > > icondu
> > > >
>ctor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microproc
> > > > ctor+essor&
> > > > c=4&s6&.sig=SYHwNJjjGQXRvtt_GybT4g> Pic
> > > > > > +semic
> > > >
>onductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+micro
> > > > onductor+proces
> > > > sor&c=4&s6&.sig=umVbbnUwsPzEzKKD_pQfUw> microcontrollers
> > > > 8051
> > > > > > semico
> > > >
>nductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microp
> > > > nductor+rocess
> > > > or&c=4&s6&.sig=NO-nSKjHoAlh9XtZ8LB1_A> microprocessor
> > > >
> > > > _____
> > > >
> > > >
Steve,

Thanks a lot for your help. I appreciate it.

My intention was to have the copy of flash function in
page 0x30 to erase/program page 0x3E only. Per Freescale
document, it is not required to load the PPAGE register
if the memory address being erased/programed is not in paged area.
So for this copy of functions, I took out the lines that
set PPAGE register. The content of PPAGE register will remain
0x30. Instead, I uesed the physical address of
0x4000-0x7FFFF to program page 0x3E.

Another thing that is weird and I can't explain is that, I was using
Cosmic ZAP debugger, if I use single step, both the flash_erase
and flash_write functions will succeed. However, once I let the
program run continuously through the function of flash_erase, the
system would fail. But the flash_program seems to work if I single
step and complete the flash_erase function. Can you or
anyone shed a light on what might be happening?

Thanks.
--Wenji
--- In 6..., Steve Russell wrote:
> Wenji,
>
> Some suggestions below.
>
> Steve Russell
> Nohau Emulators
>
> At 12:45 PM 4/25/2006, wz24 wrote:
> >Hi, David and all,
> >
> >I have a similar situation as discussed in this tread. I would like
> >to have a bootloader that resides in page 0x3C-0x3F(bank 0) of a
> >9S12DP256B MCU. One part of the application firmware that the
> >bootloader tries to load resides in non-banked page 0x3E of the
same
> >bank.
> >
> > >From reading the Freescale flash memory spec S12FTS256KV2.pdf, I
got
> >the impression you can program page -0x3E of bank 0 from a
different
> >bank, say bank 3(page 0x30). So I designed my boot loader
> >in a way that I would have two copies of function code that do
> >flash_erase and flash_write, one copy are in page 0x30 of bank 3
and
> >the other in page 0x3F of bank 0. Then in the bootloader, I would
> >'@far call' the copy in bank 3 to program page 0x3E and '@near
call'
> >the copy in bank 0 to program addresses in bank 1, 2 and 3.
> >
> >Somehow the code is not working while programming page 0x3E. Could
> >someone help to confirm if this solution should work or I am
missing
> >something.
>
> It sounds like there might be a fight over the contents of the
PPAGE
> register.
>
> This register controls which page the CPU executes instructions
from in the
> flash window from 0x8000 through 0xBFFF, AND it also controls which
flash
> is selected for programming. This means that if you are attempting
to
> program page 3E in the flash window, you cannot execute
instructions from
> that window.
>
> The @near call and @far call just control whether the function call
sets
> PPAGE appropriately to the function address.
>
> Since page 0x30 is can only be addressed in the flash window, you
must set
> PPAGE to 0x30 to execute any function in page 0x30. This means
that a
> programming algorithm running entirely in page 0x30 cannot program
other
> pages because of the conflict over PPAGE for program execution AND
to
> select the flash page.
>
> The way to overcome this is to have the actual sequence of
instructions
> that does the setting of PPAGE and flash programming in RAM so that
PPAGE
> can have any value without disturbing the program operation.
>
> In the archives there are discussions of two ways to do this: One
is to
> cleverly cause the right code to be in a local array, which will be
on the
> stack which has to be in RAM; The other is to explicitly compile
some code
> to be position independent or to execute at a fixed location in
RAM, and
> transfer that code from flash to RAM to execute.
>
> Bootstrap loaders always seem to end up with these and many more
> complications. They're hard to get right, and its hard to figure
out
> what's wrong.
>
> Keep trying! Good luck!
>
> >Thanks.
> >
> >--Wenji
> >
> >
> >--- In 6..., David Wild wrote:
> > >
> > > I am digging back in memory here so this may not be 100%. I
made my
> >bootloader lie in f800 to ffff and I did not use any pcr
addressing.
> >for the pseudovector table I simply did something along the lines
of
> >(in pseudocode)
> > >
> > > FFDO:
> > > ldx FFD0 - BOOTBLOCKSIZE
> > > jmp 0,x
> > >
> > > I did one of these labels and offsets for each possible
interrupt.
> > >
> > > For the Flash writing routines, instead of using PCR, I simply
> >wrote it carefully in a fashion that would allow a jump to that
> >address in RAM (where the routine would be copied to) and then,
> >within that routine, used all relative addressing. Before I jumped
to
> >ram I woudl save the PC on the stack. At the end of the routine I
> >think I simply popped the top of the stack into the program counter
> >to return to FLASH. I would have to double check but if I recall,
> >that is pretty close to what I did.
> > >
> > > Easier than it sounds I am sure. :)
> > >
> > > ----
> > > From: y.sevin@
> > > Sent: December 15, 2005 2:56 PM
> > > To: 6...
> > > Subject: RE: [68HC12] HC912DG128A : bootloader in non-banked
> >memory ?
> > >
> > > I'd like to program only one part but apparently, some sections
> >used by the
> > > assembler must be in the same part than the bootloader (see my
> >first post).
> > > I'm trying to use the bootloader without copying it in RAM
because
> >the examples
> > > I've found use "pcr" or relative addressing mode and my
assembler
> >fails with
> > > that. The bootloader is in assembler and I put it in a C
program by
> >using the
> > > "asm" command. I have a lot of label addressing mode errors or
> >something like
> > > this.
> > > Do I have to put the bootloader in an asm file, then assembly it
> >and then
> > > include it in the main project with the C program ?
> > >
> > > > The DG128 has two blocks. You can run a program in one block
to
> >program the
> > > > other block. However, if you want to program parts of the same
> >block that
> > > > the bootlader is in then you have to be running the code from
> >RAM. When I
> > > > created a bootloader I simply copied the few small writing
> >routines into RAM
> > > > rather than the entire bootloader.
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: 6... [mailto:6...]
On
> >Behalf Of
> > > > y.sevin@
> > > > Sent: Thursday, December 15, 2005 9:16 AM
> > > > To: 6...
> > > > Subject: RE: [68HC12] HC912DG128A : bootloader in non-banked
> >memory ?
> > > >
> > > > AN2166 is about erasing and programming flash EEPROM on DG128A
> >and explains
> > > > that you can run a program in non-banked memory to erase or
flash
> >banked
> > > > memory.
> > > > So why not a bootloader ?
> > > >
> > > >
> > > >
> > > > > you should look at the Serial Bootloader from Freescale
AN2153.
> >The
> > > > > document explains how he built the bootloader and why you
need
> >to move
> > > > > it to move the bootloader to RAM. You will also find the SW
> >files within
> > > > AN2153_SW.
> > > > >
> > > > > _____
> > > > >
> > > > > From: 6...
[mailto:6...] On
> >Behalf
> > > > > Of
> > > > > yann_37
> > > > > Sent: December 15, 2005 9:16 AM
> > > > > To: 6...
> > > > > Subject: [68HC12] HC912DG128A : bootloader in non-banked
> >memory ?
> > > > >
> > > > >
> > > > > Hello,
> > > > > I'm working on a HC912DG128A.
> > > > > Apparently, it is possible to put a bootloader in the non-
banked
> > > > > memory ($4000-$7FFF and $C000-$FFFF). You can also erase and
> >program
> > > > > banked memory (6 pages from $8000-$BFFF).
> > > > > My problem is about the predefined sections that must be in
non-
> >banked
> > > > > memory : ROM_VAR (application constant variables), STRINGS
> > > > > (application string constants), COPY (initialization values
for
> >the
> > > > > application variables).
> > > > > If the new code that the bootloader will put in flash memory
> >contains
> > > > > new variables, it will create changes in these sections, so
it
> >won't
> > > > > work ?
> > > > > Is it possible to put these sections in banked memory ?
> > > > > Does anybody have a solution ?
> > > > > Am I obliged to copy and run the bootloader in RAM ?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > SPONSORED LINKS
> > > > > Freescale
> > > > > > > eescal
> > > > >e+semiconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w4
5
> > > > > e+semiconductor+1+micr
> > > > > oprocessor&c=4&s6&.sig=K2HGv-zFlv5OYUv_QxIq_Q>
semiconductor
> >inc
> > > > > Microcontrollers
> > > > > > > icondu
> > > > >ctor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+micropro
c
> > > > > ctor+essor&
> > > > > c=4&s6&.sig=SYHwNJjjGQXRvtt_GybT4g> Pic
> > > > > > > +semic
> > > > >onductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+micr
o
> > > > > onductor+proces
> > > > > sor&c=4&s6&.sig=umVbbnUwsPzEzKKD_pQfUw> microcontrollers
> > > > > 8051
> > > > > > > semico
> > > > >nductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+micro
p
> > > > > nductor+rocess
> > > > > or&c=4&s6&.sig=NO-nSKjHoAlh9XtZ8LB1_A> microprocessor
> > > > >
> > > > > _____
> > > > >
> > > > >
Wenji,

When you single step, you insert big delays. If your code was not
correctly waiting for CBEIF in FSTAT to set to indicate that the
programming process had finished the current command it would likely work
right when single stepping but not when running at full speed.

Are you checking the PVIOL and ACCERR in FSTAT and reporting which one is
set if they are? I found that they were very helpful in giving me a clue
as to what sort of problem the flash programming was having.

I believe that the Freescale documentation has a listing of the causes that
can set these flags.

Steve Russell
Nohau Emulators
At 03:28 PM 4/25/2006, wz24 wrote:
>Steve,
>
>Thanks a lot for your help. I appreciate it.
>
>My intention was to have the copy of flash function in
>page 0x30 to erase/program page 0x3E only. Per Freescale
>document, it is not required to load the PPAGE register
>if the memory address being erased/programed is not in paged area.
>So for this copy of functions, I took out the lines that
>set PPAGE register. The content of PPAGE register will remain
>0x30. Instead, I uesed the physical address of
>0x4000-0x7FFFF to program page 0x3E.
>
>Another thing that is weird and I can't explain is that, I was using
>Cosmic ZAP debugger, if I use single step, both the flash_erase
>and flash_write functions will succeed. However, once I let the
>program run continuously through the function of flash_erase, the
>system would fail. But the flash_program seems to work if I single
>step and complete the flash_erase function. Can you or
>anyone shed a light on what might be happening?
>
>Thanks.
>--Wenji
>--- In 6..., Steve Russell wrote:
> >
> >
> > Wenji,
> >
> > Some suggestions below.
> >
> > Steve Russell
> > Nohau Emulators
> >
> > At 12:45 PM 4/25/2006, wz24 wrote:
> > >Hi, David and all,
> > >
> > >I have a similar situation as discussed in this tread. I would like
> > >to have a bootloader that resides in page 0x3C-0x3F(bank 0) of a
> > >9S12DP256B MCU. One part of the application firmware that the
> > >bootloader tries to load resides in non-banked page 0x3E of the
>same
> > >bank.
> > >
> > > >From reading the Freescale flash memory spec S12FTS256KV2.pdf, I
>got
> > >the impression you can program page -0x3E of bank 0 from a
>different
> > >bank, say bank 3(page 0x30). So I designed my boot loader
> > >in a way that I would have two copies of function code that do
> > >flash_erase and flash_write, one copy are in page 0x30 of bank 3
>and
> > >the other in page 0x3F of bank 0. Then in the bootloader, I would
> > >'@far call' the copy in bank 3 to program page 0x3E and '@near
>call'
> > >the copy in bank 0 to program addresses in bank 1, 2 and 3.
> > >
> > >Somehow the code is not working while programming page 0x3E. Could
> > >someone help to confirm if this solution should work or I am
>missing
> > >something.
> >
> > It sounds like there might be a fight over the contents of the
>PPAGE
> > register.
> >
> > This register controls which page the CPU executes instructions
>from in the
> > flash window from 0x8000 through 0xBFFF, AND it also controls which
>flash
> > is selected for programming. This means that if you are attempting
>to
> > program page 3E in the flash window, you cannot execute
>instructions from
> > that window.
> >
> > The @near call and @far call just control whether the function call
>sets
> > PPAGE appropriately to the function address.
> >
> > Since page 0x30 is can only be addressed in the flash window, you
>must set
> > PPAGE to 0x30 to execute any function in page 0x30. This means
>that a
> > programming algorithm running entirely in page 0x30 cannot program
>other
> > pages because of the conflict over PPAGE for program execution AND
>to
> > select the flash page.
> >
> > The way to overcome this is to have the actual sequence of
>instructions
> > that does the setting of PPAGE and flash programming in RAM so that
>PPAGE
> > can have any value without disturbing the program operation.
> >
> > In the archives there are discussions of two ways to do this: One
>is to
> > cleverly cause the right code to be in a local array, which will be
>on the
> > stack which has to be in RAM; The other is to explicitly compile
>some code
> > to be position independent or to execute at a fixed location in
>RAM, and
> > transfer that code from flash to RAM to execute.
> >
> > Bootstrap loaders always seem to end up with these and many more
> > complications. They're hard to get right, and its hard to figure
>out
> > what's wrong.
> >
> > Keep trying! Good luck!
> >
> > >Thanks.
> > >
> > >--Wenji
> > >
> > >
> > >--- In 6..., David Wild wrote:
> > > >
> > > > I am digging back in memory here so this may not be 100%. I
>made my
> > >bootloader lie in f800 to ffff and I did not use any pcr
>addressing.
> > >for the pseudovector table I simply did something along the lines
>of
> > >(in pseudocode)
> > > >
> > > > FFDO:
> > > > ldx FFD0 - BOOTBLOCKSIZE
> > > > jmp 0,x
> > > >
> > > > I did one of these labels and offsets for each possible
>interrupt.
> > > >
> > > > For the Flash writing routines, instead of using PCR, I simply
> > >wrote it carefully in a fashion that would allow a jump to that
> > >address in RAM (where the routine would be copied to) and then,
> > >within that routine, used all relative addressing. Before I jumped
>to
> > >ram I woudl save the PC on the stack. At the end of the routine I
> > >think I simply popped the top of the stack into the program counter
> > >to return to FLASH. I would have to double check but if I recall,
> > >that is pretty close to what I did.
> > > >
> > > > Easier than it sounds I am sure. :)
> > > >
> > > > ----
> > > > From: y.sevin@
> > > > Sent: December 15, 2005 2:56 PM
> > > > To: 6...
> > > > Subject: RE: [68HC12] HC912DG128A : bootloader in non-banked
> > >memory ?
> > > >
> > > > I'd like to program only one part but apparently, some sections
> > >used by the
> > > > assembler must be in the same part than the bootloader (see my
> > >first post).
> > > > I'm trying to use the bootloader without copying it in RAM
>because
> > >the examples
> > > > I've found use "pcr" or relative addressing mode and my
>assembler
> > >fails with
> > > > that. The bootloader is in assembler and I put it in a C
>program by
> > >using the
> > > > "asm" command. I have a lot of label addressing mode errors or
> > >something like
> > > > this.
> > > > Do I have to put the bootloader in an asm file, then assembly it
> > >and then
> > > > include it in the main project with the C program ?
> > > >
> > > > > The DG128 has two blocks. You can run a program in one block
>to
> > >program the
> > > > > other block. However, if you want to program parts of the same
> > >block that
> > > > > the bootlader is in then you have to be running the code from
> > >RAM. When I
> > > > > created a bootloader I simply copied the few small writing
> > >routines into RAM
> > > > > rather than the entire bootloader.
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: 6... [mailto:6...]
>On
> > >Behalf Of
> > > > > y.sevin@
> > > > > Sent: Thursday, December 15, 2005 9:16 AM
> > > > > To: 6...
> > > > > Subject: RE: [68HC12] HC912DG128A : bootloader in non-banked
> > >memory ?
> > > > >
> > > > > AN2166 is about erasing and programming flash EEPROM on DG128A
> > >and explains
> > > > > that you can run a program in non-banked memory to erase or
>flash
> > >banked
> > > > > memory.
> > > > > So why not a bootloader ?
> > > > >
> > > > >
> > > > >
> > > > > > you should look at the Serial Bootloader from Freescale
>AN2153.
> > >The
> > > > > > document explains how he built the bootloader and why you
>need
> > >to move
> > > > > > it to move the bootloader to RAM. You will also find the SW
> > >files within
> > > > > AN2153_SW.
> > > > > >
> > > > > > _____
> > > > > >
> > > > > > From: 6...
>[mailto:6...] On
> > >Behalf
> > > > > > Of
> > > > > > yann_37
> > > > > > Sent: December 15, 2005 9:16 AM
> > > > > > To: 6...
> > > > > > Subject: [68HC12] HC912DG128A : bootloader in non-banked
> > >memory ?
> > > > > >
> > > > > >
> > > > > > Hello,
> > > > > > I'm working on a HC912DG128A.
> > > > > > Apparently, it is possible to put a bootloader in the non-
>banked
> > > > > > memory ($4000-$7FFF and $C000-$FFFF). You can also erase and
> > >program
> > > > > > banked memory (6 pages from $8000-$BFFF).
> > > > > > My problem is about the predefined sections that must be in
>non-
> > >banked
> > > > > > memory : ROM_VAR (application constant variables), STRINGS
> > > > > > (application string constants), COPY (initialization values
>for
> > >the
> > > > > > application variables).
> > > > > > If the new code that the bootloader will put in flash memory
> > >contains
> > > > > > new variables, it will create changes in these sections, so
>it
> > >won't
> > > > > > work ?
> > > > > > Is it possible to put these sections in banked memory ?
> > > > > > Does anybody have a solution ?
> > > > > > Am I obliged to copy and run the bootloader in RAM ?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > SPONSORED LINKS
> > > > > > Freescale
> > > > > > > > eescal
> > > > > >
> >
> >e+semiconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w4
>5
> > > > > > e+semiconductor+1+micr
> > > > > > oprocessor&c=4&s6&.sig=K2HGv-zFlv5OYUv_QxIq_Q>
>semiconductor
> > >inc
> > > > > > Microcontrollers
> > > > > > > > icondu
> > > > > >
> >
> >ctor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+micropro
>c
> > > > > > ctor+essor&
> > > > > > c=4&s6&.sig=SYHwNJjjGQXRvtt_GybT4g> Pic
> > > > > > > > +semic
> > > > > >
> >
> >onductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+micr
>o
> > > > > > onductor+proces
> > > > > > sor&c=4&s6&.sig=umVbbnUwsPzEzKKD_pQfUw> microcontrollers
> > > > > > 8051
> > > > > > > > semico
> > > > > >
> >
> >nductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+micro
>p
> > > > > > nductor+rocess
> > > > > > or&c=4&s6&.sig=NO-nSKjHoAlh9XtZ8LB1_A> microprocessor
> > > > > >
> > > > > > _____
> > > > > >
> > > > > >
Wenji,

In addition to Steve's advice:

When you program page 0x3E, you must see that no interrupt request will be
issued. This is since interrupt requests result in the CPU fetching the
Interrupt vector which is in Flash block 0 - the same block as the one you
are trying to program in page 0x3E. (so you need to see that the I bit in
the CCR register is set prior to starting the program algorithm for page 0x3E)

When you single step, depending on the debugger settings, interrupts may be
masked off, as compared to full-speed execution where they are not masked,
so this could explain the behavior you experience.

Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html

At 22:28 25/04/2006 +0000, you wrote:
>Steve,
>
>Thanks a lot for your help. I appreciate it.
>
>My intention was to have the copy of flash function in
>page 0x30 to erase/program page 0x3E only. Per Freescale
>document, it is not required to load the PPAGE register
>if the memory address being erased/programed is not in paged area.
>So for this copy of functions, I took out the lines that
>set PPAGE register. The content of PPAGE register will remain
>0x30. Instead, I uesed the physical address of
>0x4000-0x7FFFF to program page 0x3E.
>
>Another thing that is weird and I can't explain is that, I was using
>Cosmic ZAP debugger, if I use single step, both the flash_erase
>and flash_write functions will succeed. However, once I let the
>program run continuously through the function of flash_erase, the
>system would fail. But the flash_program seems to work if I single
>step and complete the flash_erase function. Can you or
>anyone shed a light on what might be happening?
>
>Thanks.
>--Wenji
>--- In 6..., Steve Russell wrote:
> >
> >
> > Wenji,
> >
> > Some suggestions below.
> >
> > Steve Russell
> > Nohau Emulators
> >
> > At 12:45 PM 4/25/2006, wz24 wrote:
> > >Hi, David and all,
> > >
> > >I have a similar situation as discussed in this tread. I would like
> > >to have a bootloader that resides in page 0x3C-0x3F(bank 0) of a
> > >9S12DP256B MCU. One part of the application firmware that the
> > >bootloader tries to load resides in non-banked page 0x3E of the
>same
> > >bank.
> > >
> > > >From reading the Freescale flash memory spec S12FTS256KV2.pdf, I
>got
> > >the impression you can program page -0x3E of bank 0 from a
>different
> > >bank, say bank 3(page 0x30). So I designed my boot loader
> > >in a way that I would have two copies of function code that do
> > >flash_erase and flash_write, one copy are in page 0x30 of bank 3
>and
> > >the other in page 0x3F of bank 0. Then in the bootloader, I would
> > >'@far call' the copy in bank 3 to program page 0x3E and '@near
>call'
> > >the copy in bank 0 to program addresses in bank 1, 2 and 3.
> > >
> > >Somehow the code is not working while programming page 0x3E. Could
> > >someone help to confirm if this solution should work or I am
>missing
> > >something.
> >
> > It sounds like there might be a fight over the contents of the
>PPAGE
> > register.
> >
> > This register controls which page the CPU executes instructions
>from in the
> > flash window from 0x8000 through 0xBFFF, AND it also controls which
>flash
> > is selected for programming. This means that if you are attempting
>to
> > program page 3E in the flash window, you cannot execute
>instructions from
> > that window.
> >
> > The @near call and @far call just control whether the function call
>sets
> > PPAGE appropriately to the function address.
> >
> > Since page 0x30 is can only be addressed in the flash window, you
>must set
> > PPAGE to 0x30 to execute any function in page 0x30. This means
>that a
> > programming algorithm running entirely in page 0x30 cannot program
>other
> > pages because of the conflict over PPAGE for program execution AND
>to
> > select the flash page.
> >
> > The way to overcome this is to have the actual sequence of
>instructions
> > that does the setting of PPAGE and flash programming in RAM so that
>PPAGE
> > can have any value without disturbing the program operation.
> >
> > In the archives there are discussions of two ways to do this: One
>is to
> > cleverly cause the right code to be in a local array, which will be
>on the
> > stack which has to be in RAM; The other is to explicitly compile
>some code
> > to be position independent or to execute at a fixed location in
>RAM, and
> > transfer that code from flash to RAM to execute.
> >
> > Bootstrap loaders always seem to end up with these and many more
> > complications. They're hard to get right, and its hard to figure
>out
> > what's wrong.
> >
> > Keep trying! Good luck!
> >
> > >Thanks.
> > >
> > >--Wenji
wenji,

I use codewarrior debugger for my bootloader. When I try to execute a flash
command as a single step I always get ACCESS_ERROR. I can only debug it
running continously.
S12FTS256KV2 doc says that a CPU STOP instruction can not be execute after a
flash command is launched. I had to asume that single step cannot be tried
after a falsh command.

Ensure you wait for the flash command completion as Steve said.

Below some of my erase / write code. It works fine:

-----FLASH WRITE
WORD----------------------

PPAGE = page;
FCNFG = GetBNKSEL(PPAGE);

if(FSTAT_CBEIF == 1) // If cmd queue can accept another cmd
{
(*address) = data;
FCMD = PROG;// Store programming command in FCMD
(void)DoOnStack(page);// just passed for PPAGE

PPAGE = thisPage;
if (FSTAT_ACCERR) {return Access_Error;}
if (FSTAT_PVIOL) {return Protection_Error;}
while (FSTAT_CCIF != 1){} // Wait for command completion
}
else
{
return FULL_QUEUE_ERROR; // Cmd queue can not accept another cmd
}

if(readPagedAddress(page,address) == data) return OK;
else return CHECK_WRITE;

----ERASE
SECTOR------------------------------
PPAGE = page;
FCNFG = GetBNKSEL(PPAGE);

if(FSTAT_CBEIF == 1) // If cmd queue can accept another cmd
{
*address = 0xABCD; // Load any data
FCMD= ERASE;// Store programming command in FCMD

(void)DoOnStack(page);// just passed for PPAGE
PPAGE = thisPage;
if (FSTAT_ACCERR) {return Access_Error;}
if (FSTAT_PVIOL) {return Protection_Error;}
while(FSTAT_CCIF != 1){}
}
else
{
return FULL_QUEUE_ERROR; // Cmd queue can not accept another cmd
}
// Check for blank
for (addressOffset = 0;
addressOffset addressOffset++){
readValue = readPagedAddress(page,address+addressOffset);
if(readValue != 0xFFFF) return CHECK_BLANK_SECTOR;
}
return OK;

I hope this helps
-----Original Message-----
From: Doron Fael
To: 6...
Date: Wed, 26 Apr 2006 05:41:16 +0300
Subject: Re: [68HC12] Re: HC912DG128A : bootloader in non-banked memory ?

Wenji,

In addition to Steve's advice:

When you program page 0x3E, you must see that no interrupt request will be
issued. This is since interrupt requests result in the CPU fetching the
Interrupt vector which is in Flash block 0 - the same block as the one you
are trying to program in page 0x3E. (so you need to see that the I bit in
the CCR register is set prior to starting the program algorithm for page
0x3E)

When you single step, depending on the debugger settings, interrupts may be
masked off, as compared to full-speed execution where they are not masked,
so this could explain the behavior you experience.

Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html

At 22:28 25/04/2006 +0000, you wrote:
>Steve,
>
>Thanks a lot for your help. I appreciate it.
>
>My intention was to have the copy of flash function in
>page 0x30 to erase/program page 0x3E only. Per Freescale
>document, it is not required to load the PPAGE register
>if the memory address being erased/programed is not in paged area.
>So for this copy of functions, I took out the lines that
>set PPAGE register. The content of PPAGE register will remain
>0x30. Instead, I uesed the physical address of
>0x4000-0x7FFFF to program page 0x3E.
>
>Another thing that is weird and I can't explain is that, I was using
>Cosmic ZAP debugger, if I use single step, both the flash_erase
>and flash_write functions will succeed. However, once I let the
>program run continuously through the function of flash_erase, the
>system would fail. But the flash_program seems to work if I single
>step and complete the flash_erase function. Can you or
>anyone shed a light on what might be happening?
>
>Thanks.
>--Wenji
>--- In 6..., Steve Russell wrote:
> >
> >
> > Wenji,
> >
> > Some suggestions below.
> >
> > Steve Russell
> > Nohau Emulators
> >
> > At 12:45 PM 4/25/2006, wz24 wrote:
> > >Hi, David and all,
> > >
> > >I have a similar situation as discussed in this tread. I would like
> > >to have a bootloader that resides in page 0x3C-0x3F(bank 0) of a
> > >9S12DP256B MCU. One part of the application firmware that the
> > >bootloader tries to load resides in non-banked page 0x3E of the
>same
> > >bank.
> > >
> > > >From reading the Freescale flash memory spec S12FTS256KV2.pdf, I
>got
> > >the impression you can program page -0x3E of bank 0 from a
>different
> > >bank, say bank 3(page 0x30). So I designed my boot loader
> > >in a way that I would have two copies of function code that do
> > >flash_erase and flash_write, one copy are in page 0x30 of bank 3
>and
> > >the other in page 0x3F of bank 0. Then in the bootloader, I would
> > >'@far call' the copy in bank 3 to program page 0x3E and '@near
>call'
> > >the copy in bank 0 to program addresses in bank 1, 2 and 3.
> > >
> > >Somehow the code is not working while programming page 0x3E. Could
> > >someone help to confirm if this solution should work or I am
>missing
> > >something.
> >
> > It sounds like there might be a fight over the contents of the
>PPAGE
> > register.
> >
> > This register controls which page the CPU executes instructions
>from in the
> > flash window from 0x8000 through 0xBFFF, AND it also controls which
>flash
> > is selected for programming. This means that if you are attempting
>to
> > program page 3E in the flash window, you cannot execute
>instructions from
> > that window.
> >
> > The @near call and @far call just control whether the function call
>sets
> > PPAGE appropriately to the function address.
> >
> > Since page 0x30 is can only be addressed in the flash window, you
>must set
> > PPAGE to 0x30 to execute any function in page 0x30. This means
>that a
> > programming algorithm running entirely in page 0x30 cannot program
>other
> > pages because of the conflict over PPAGE for program execution AND
>to
> > select the flash page.
> >
> > The way to overcome this is to have the actual sequence of
>instructions
> > that does the setting of PPAGE and flash programming in RAM so that
>PPAGE
> > can have any value without disturbing the program operation.
> >
> > In the archives there are discussions of two ways to do this: One
>is to
> > cleverly cause the right code to be in a local array, which will be
>on the
> > stack which has to be in RAM; The other is to explicitly compile
>some code
> > to be position independent or to execute at a fixed location in
>RAM, and
> > transfer that code from flash to RAM to execute.
> >
> > Bootstrap loaders always seem to end up with these and many more
> > complications. They're hard to get right, and its hard to figure
>out
> > what's wrong.
> >
> > Keep trying! Good luck!
> >
> > >Thanks.
> > >
> > >--Wenji
Hi, Guys,

Thanks a lot for the help. I figured out what is causing the problem
yesterday night. The reason is exactly what Doron said. I have my
interrupt routines in block 0. And the difference between running
in single step in the debugger vs running continuously is that
it is much less likely to hit interrrupt while in singel stepping
mode.

What I end up doing was to disable interrupts in my second copy of
flash funcitons in page 0x30. That solved the problem.

Thanks again.

--Wenji

--- In 6..., "Agust Pedroso" wrote:
>
> wenji,
>
> I use codewarrior debugger for my bootloader. When I try to execute
a flash
> command as a single step I always get ACCESS_ERROR. I can only
debug it
> running continously.
> S12FTS256KV2 doc says that a CPU STOP instruction can not be
execute after a
> flash command is launched. I had to asume that single step cannot
be tried
> after a falsh command.
>
> Ensure you wait for the flash command completion as Steve said.
>
> Below some of my erase / write code. It works fine:
>
> -----FLASH WRITE
> WORD----------------------------
------------------------------
>
> PPAGE = page;
> FCNFG = GetBNKSEL(PPAGE);
>
> if(FSTAT_CBEIF == 1) // If cmd queue can accept another cmd
> {
> (*address) = data;
> FCMD = PROG;// Store programming command in FCMD
> (void)DoOnStack(page);// just passed for PPAGE
>
> PPAGE = thisPage;
> if (FSTAT_ACCERR) {return Access_Error;}
> if (FSTAT_PVIOL) {return Protection_Error;}
> while (FSTAT_CCIF != 1){} // Wait for command completion
> }
> else
> {
> return FULL_QUEUE_ERROR; // Cmd queue can not accept another
cmd
> }
>
> if(readPagedAddress(page,address) == data) return OK;
> else return CHECK_WRITE;
>
> ----ERASE
> SECTOR--------------------------
----
> PPAGE = page;
> FCNFG = GetBNKSEL(PPAGE);
>
> if(FSTAT_CBEIF == 1) // If cmd queue can accept another cmd
> {
> *address = 0xABCD; // Load any data
> FCMD= ERASE;// Store programming command in FCMD
>
> (void)DoOnStack(page);// just passed for PPAGE
> PPAGE = thisPage;
> if (FSTAT_ACCERR) {return Access_Error;}
> if (FSTAT_PVIOL) {return Protection_Error;}
> while(FSTAT_CCIF != 1){}
> }
> else
> {
> return FULL_QUEUE_ERROR; // Cmd queue can not accept another
cmd
> }
> // Check for blank
> for (addressOffset = 0;
> addressOffset > addressOffset++){
> readValue = readPagedAddress(page,address+addressOffset);
> if(readValue != 0xFFFF) return CHECK_BLANK_SECTOR;
> }
> return OK;
>
> I hope this helps
> -----Original Message-----
> From: Doron Fael
> To: 6...
> Date: Wed, 26 Apr 2006 05:41:16 +0300
> Subject: Re: [68HC12] Re: HC912DG128A : bootloader in non-banked
memory ?
>
> Wenji,
>
> In addition to Steve's advice:
>
> When you program page 0x3E, you must see that no interrupt request
will be
> issued. This is since interrupt requests result in the CPU fetching
the
> Interrupt vector which is in Flash block 0 - the same block as the
one you
> are trying to program in page 0x3E. (so you need to see that the I
bit in
> the CCR register is set prior to starting the program algorithm for
page
> 0x3E)
>
> When you single step, depending on the debugger settings,
interrupts may be
> masked off, as compared to full-speed execution where they are not
masked,
> so this could explain the behavior you experience.
>
> Hope this helps,
> Doron
> Nohau
> HC12 In-Circuit Emulators
> www.nohau.com/emul12pc.html
>
> At 22:28 25/04/2006 +0000, you wrote:
> >Steve,
> >
> >Thanks a lot for your help. I appreciate it.
> >
> >My intention was to have the copy of flash function in
> >page 0x30 to erase/program page 0x3E only. Per Freescale
> >document, it is not required to load the PPAGE register
> >if the memory address being erased/programed is not in paged area.
> >So for this copy of functions, I took out the lines that
> >set PPAGE register. The content of PPAGE register will remain
> >0x30. Instead, I uesed the physical address of
> >0x4000-0x7FFFF to program page 0x3E.
> >
> >Another thing that is weird and I can't explain is that, I was
using
> >Cosmic ZAP debugger, if I use single step, both the flash_erase
> >and flash_write functions will succeed. However, once I let the
> >program run continuously through the function of flash_erase, the
> >system would fail. But the flash_program seems to work if I single
> >step and complete the flash_erase function. Can you or
> >anyone shed a light on what might be happening?
> >
> >Thanks.
> >
> >
> >--Wenji
> >
> >
> >--- In 6..., Steve Russell wrote:
> > >
> > >
> > > Wenji,
> > >
> > > Some suggestions below.
> > >
> > > Steve Russell
> > > Nohau Emulators
> > >
> > > At 12:45 PM 4/25/2006, wz24 wrote:
> > > >Hi, David and all,
> > > >
> > > >I have a similar situation as discussed in this tread. I would
like
> > > >to have a bootloader that resides in page 0x3C-0x3F(bank 0) of
a
> > > >9S12DP256B MCU. One part of the application firmware that the
> > > >bootloader tries to load resides in non-banked page 0x3E of the
> >same
> > > >bank.
> > > >
> > > > >From reading the Freescale flash memory spec
S12FTS256KV2.pdf, I
> >got
> > > >the impression you can program page -0x3E of bank 0 from a
> >different
> > > >bank, say bank 3(page 0x30). So I designed my boot loader
> > > >in a way that I would have two copies of function code that do
> > > >flash_erase and flash_write, one copy are in page 0x30 of bank
3
> >and
> > > >the other in page 0x3F of bank 0. Then in the bootloader, I
would
> > > >'@far call' the copy in bank 3 to program page 0x3E and '@near
> >call'
> > > >the copy in bank 0 to program addresses in bank 1, 2 and 3.
> > > >
> > > >Somehow the code is not working while programming page 0x3E.
Could
> > > >someone help to confirm if this solution should work or I am
> >missing
> > > >something.
> > >
> > > It sounds like there might be a fight over the contents of the
> >PPAGE
> > > register.
> > >
> > > This register controls which page the CPU executes instructions
> >from in the
> > > flash window from 0x8000 through 0xBFFF, AND it also controls
which
> >flash
> > > is selected for programming. This means that if you are
attempting
> >to
> > > program page 3E in the flash window, you cannot execute
> >instructions from
> > > that window.
> > >
> > > The @near call and @far call just control whether the function
call
> >sets
> > > PPAGE appropriately to the function address.
> > >
> > > Since page 0x30 is can only be addressed in the flash window,
you
> >must set
> > > PPAGE to 0x30 to execute any function in page 0x30. This means
> >that a
> > > programming algorithm running entirely in page 0x30 cannot
program
> >other
> > > pages because of the conflict over PPAGE for program execution
AND
> >to
> > > select the flash page.
> > >
> > > The way to overcome this is to have the actual sequence of
> >instructions
> > > that does the setting of PPAGE and flash programming in RAM so
that
> >PPAGE
> > > can have any value without disturbing the program operation.
> > >
> > > In the archives there are discussions of two ways to do this:
One
> >is to
> > > cleverly cause the right code to be in a local array, which
will be
> >on the
> > > stack which has to be in RAM; The other is to explicitly
compile
> >some code
> > > to be position independent or to execute at a fixed location in
> >RAM, and
> > > transfer that code from flash to RAM to execute.
> > >
> > > Bootstrap loaders always seem to end up with these and many more
> > > complications. They're hard to get right, and its hard to
figure
> >out
> > > what's wrong.
> > >
> > > Keep trying! Good luck!
> > >
> > > >Thanks.
> > > >
> > > >--Wenji
>
>
>
>
>
>
>
>