Metrowerks banked mode

Started by Adrian Vos January 19, 2004
Hi All,

I am using metrowerks v2, which I have 32k license for with s12DP256. My
code is approx 16k, and I am starting to get the following linker error:

L1907: Fixup overflow in _LDIVS, to _NEG_P type 3, at offset 0xB

I also get the same error, but with differing offset, several times. It
seems to be unrelated to the actual code, but only occurs if I add more code
to push the size over some boundary (no matter what code I add!!). I assume
my problem is that I am going over the first fixed page size which is 16k,
and I need to do something to enable the banked memory option.

I would appreciate if someone can point me in the direction of documentation
that can help me to sort out this problem. I will search myself, but I
assume other here have had the same problem, and can point me in the right
direction quickly.

Thanks,

Adrian



It seems I was a little hasty in my last email. I have done further
investigation.

I was previously using the Flash Application Target, and I changed it to
Banked Flash Target, and it compiles fine, but I do not see why I should
need to use banked flash yet. My code is 16k, and, and there is 2 fixed
flash banks of 16k, so I should be able to go to 32k which is the limit of
my license anyway. I have checked the PRM file which looks right, and I have
attached below. It looks like the fixed pages are correctly allocated for a
total unbanked memory size of 32k. I checked my map files from the last
successful compile when I was under 16k, and the _LDIVS code which is
causing the problem is the last function, and is located just at the end of
the first page. I would have thought that the linker would have identified
that this code would not fit in the first fixed flash bank, and moved it to
the second fixed flash bank, but this does not seem to have occured.

Any help appeciated in working out how to get the linker to use both fixed
flash bank correctly would be appreciated. It would be great if it could
work out itself which bank to put it in rather than me having to manually
allocate to the second bank by altering the prm file and using #pragma etc.

Anyway, here is my prm file:

NAMES
END

SECTIONS
RAM = READ_WRITE 0x1000 TO 0x3FFF;
/* unbanked FLASH ROM */
FLASH_PAGE4000 = READ_ONLY 0x04000 TO 0x07FFF;
FLASH_PAGEC000 = READ_ONLY 0x0C000 TO 0x0FEFF;
EEPROM = READ_WRITE 0x0800 TO 0x0FFF;
END

PLACEMENT
_PRESTART, STARTUP,
ROM_VAR, STRINGS,
NON_BANKED, DEFAULT_ROM,
COPY INTO FLASH_PAGE4000, FLASH_PAGEC000;
DEFAULT_RAM INTO RAM;
END

STACKSIZE 0x100

VECTOR ADDRESS 0xFFFE _Startup ----- Original Message -----
From: "Adrian Vos" <>
To: <>
Sent: Monday, January 19, 2004 12:56 PM
Subject: [68HC12] Metrowerks banked mode > Hi All,
>
> I am using metrowerks v2, which I have 32k license for with s12DP256. My
> code is approx 16k, and I am starting to get the following linker error:
>
> L1907: Fixup overflow in _LDIVS, to _NEG_P type 3, at offset 0xB
>
> I also get the same error, but with differing offset, several times. It
> seems to be unrelated to the actual code, but only occurs if I add more
code
> to push the size over some boundary (no matter what code I add!!). I
assume
> my problem is that I am going over the first fixed page size which is 16k,
> and I need to do something to enable the banked memory option.
>
> I would appreciate if someone can point me in the direction of
documentation
> that can help me to sort out this problem. I will search myself, but I
> assume other here have had the same problem, and can point me in the right
> direction quickly.
>
> Thanks,
>
> Adrian > --------------------To learn more
about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu





Hi Adrian,

The problem is that _LDIVS is calling NEG_P with a 8 bit relative offset:

1233: void NEAR _LDIVS (void) { /* a = a / b signed */
...
000a 0700 BSR _NEG_P
.. This works fine as long as you do allocate the NON_BANKED section into one single placement.
However for your app it looks like all the others would just fill up the FLASH_PAGE4000 segment so
that _NEG_P does still fit into it and _LDIVS is allocated in FLASH_PAGEC000.

So now what you can do about it:

1. Change the allocation order in your prm file.
The problem with this solution is that it does not really resolve the problem but instead it just tries to avoid it.
2. Build rtshc12.c with the option -OnB=b.
Either rebuild the whole library (lib\hc12c\hc12_lib.mcp) or add rtshc12.c to your project and
add the option in your project. For the second one, make sure rtshc12.c.o is before the ansi library in your link order.
3. Distribute the NON_BANKED section manually to either FLASH_PAGE4000 or FLASH_PAGEC000, but not to both.

> PLACEMENT
> _PRESTART, STARTUP,
> ROM_VAR, STRINGS INTO FLASH_PAGE4000
> NON_BANKED, DEFAULT_ROM,
> COPY INTO FLASH_PAGEC000;
> DEFAULT_RAM INTO RAM;
> END

Hope this helps.

Daniel
> -----Original Message-----
> From: Adrian Vos [mailto:]
> Sent: Monday, January 19, 2004 3:43
> To:
> Subject: Re: [68HC12] Metrowerks banked mode > It seems I was a little hasty in my last email. I have done further
> investigation.
>
> I was previously using the Flash Application Target, and I changed it to
> Banked Flash Target, and it compiles fine, but I do not see why I should
> need to use banked flash yet. My code is 16k, and, and there is 2 fixed
> flash banks of 16k, so I should be able to go to 32k which is the limit of
> my license anyway. I have checked the PRM file which looks right, and I have
> attached below. It looks like the fixed pages are correctly allocated for a
> total unbanked memory size of 32k. I checked my map files from the last
> successful compile when I was under 16k, and the _LDIVS code which is
> causing the problem is the last function, and is located just at the end of
> the first page. I would have thought that the linker would have identified
> that this code would not fit in the first fixed flash bank, and moved it to
> the second fixed flash bank, but this does not seem to have occured.
>
> Any help appeciated in working out how to get the linker to use both fixed
> flash bank correctly would be appreciated. It would be great if it could
> work out itself which bank to put it in rather than me having to manually
> allocate to the second bank by altering the prm file and using #pragma etc.
>
> Anyway, here is my prm file:
>
> NAMES
> END
>
> SECTIONS
> RAM = READ_WRITE 0x1000 TO 0x3FFF;
> /* unbanked FLASH ROM */
> FLASH_PAGE4000 = READ_ONLY 0x04000 TO 0x07FFF;
> FLASH_PAGEC000 = READ_ONLY 0x0C000 TO 0x0FEFF;
> EEPROM = READ_WRITE 0x0800 TO 0x0FFF;
> END
>
> PLACEMENT
> _PRESTART, STARTUP,
> ROM_VAR, STRINGS,
> NON_BANKED, DEFAULT_ROM,
> COPY INTO FLASH_PAGE4000, FLASH_PAGEC000;
> DEFAULT_RAM INTO RAM;
> END
>
> STACKSIZE 0x100
>
> VECTOR ADDRESS 0xFFFE _Startup > ----- Original Message -----
> From: "Adrian Vos" <>
> To: <>
> Sent: Monday, January 19, 2004 12:56 PM
> Subject: [68HC12] Metrowerks banked mode > > Hi All,
> >
> > I am using metrowerks v2, which I have 32k license for with s12DP256. My
> > code is approx 16k, and I am starting to get the following linker error:
> >
> > L1907: Fixup overflow in _LDIVS, to _NEG_P type 3, at offset 0xB
> >
> > I also get the same error, but with differing offset, several times. It
> > seems to be unrelated to the actual code, but only occurs if I add more
> code
> > to push the size over some boundary (no matter what code I add!!). I
> assume
> > my problem is that I am going over the first fixed page size which is 16k,
> > and I need to do something to enable the banked memory option.
> >
> > I would appreciate if someone can point me in the direction of
> documentation
> > that can help me to sort out this problem. I will search myself, but I
> > assume other here have had the same problem, and can point me in the right
> > direction quickly.
> >
> > Thanks,
> >
> > Adrian
> >
> >
> > --------------------To learn more
> about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> > o learn more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> >
> >
> >
> >
> > --------------------To learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu >



Thanks Daniel,

That was what I was after!!

Just another question since you seem to understand it well. I played around
a bit, and thought the optimal setup would be to hardwire all segmaents but
DEFAULT_ROM to once section, and then allocate DEFAULT_ROM (with my user
code) across both, but the linker will not accept this. I am currently using
successfully:

DEFAULT_ROM INTO FLASH_PAGE4000;
_PRESTART, STARTUP,
ROM_VAR, STRINGS,
NON_BANKED, COPY INTO FLASH_PAGEC000;

but DEFAULT_ROM is using about 13k of FLASH_PAGE4000 which will run out
shortly, and the other segments are using very little of FLASH_PAGEC000. I
would prefer to do something like:

DEFAULT_ROM INTO FLASH_PAGE4000, FLASH_PAGEC000;
_PRESTART, STARTUP,
ROM_VAR, STRINGS,
NON_BANKED, COPY INTO FLASH_PAGEC000;

which allows the DEFAULT_ROM to overflow into the second page, but it does
not like this (you cannot used the same section page more than once). Is
there any way to fully utilise the unbanked 32k for my user code before
having to resort to banked mode?

Thanks again for your help.

Regards,

Adrian ----- Original Message -----
From: "Daniel Friederich" <>
To: <>
Sent: Tuesday, January 20, 2004 1:47 AM
Subject: RE: [68HC12] Metrowerks banked mode > Hi Adrian,
>
> The problem is that _LDIVS is calling NEG_P with a 8 bit relative offset:
>
> 1233: void NEAR _LDIVS (void) { /* a = a / b signed */
> ...
> 000a 0700 BSR _NEG_P
> .. > This works fine as long as you do allocate the NON_BANKED section into one
single placement.
> However for your app it looks like all the others would just fill up the
FLASH_PAGE4000 segment so
> that _NEG_P does still fit into it and _LDIVS is allocated in
FLASH_PAGEC000.
>
> So now what you can do about it:
>
> 1. Change the allocation order in your prm file.
> The problem with this solution is that it does not really resolve the p
roblem but instead it just tries to avoid it.
> 2. Build rtshc12.c with the option -OnB=b.
> Either rebuild the whole library (lib\hc12c\hc12_lib.mcp) or add
rtshc12.c to your project and
> add the option in your project. For the second one, make sure
rtshc12.c.o is before the ansi library in your link order.
> 3. Distribute the NON_BANKED section manually to either FLASH_PAGE4000 or
FLASH_PAGEC000, but not to both.
>
> > PLACEMENT
> > _PRESTART, STARTUP,
> > ROM_VAR, STRINGS INTO FLASH_PAGE4000
> > NON_BANKED, DEFAULT_ROM,
> > COPY INTO FLASH_PAGEC000;
> > DEFAULT_RAM INTO RAM;
> > END
>
> Hope this helps.
>
> Daniel >
> > -----Original Message-----
> > From: Adrian Vos [mailto:]
> > Sent: Monday, January 19, 2004 3:43
> > To:
> > Subject: Re: [68HC12] Metrowerks banked mode
> >
> >
> > It seems I was a little hasty in my last email. I have done further
> > investigation.
> >
> > I was previously using the Flash Application Target, and I changed it to
> > Banked Flash Target, and it compiles fine, but I do not see why I should
> > need to use banked flash yet. My code is 16k, and, and there is 2 fixed
> > flash banks of 16k, so I should be able to go to 32k which is the limit
of
> > my license anyway. I have checked the PRM file which looks right, and I
have
> > attached below. It looks like the fixed pages are correctly allocated
for a
> > total unbanked memory size of 32k. I checked my map files from the last
> > successful compile when I was under 16k, and the _LDIVS code which is
> > causing the problem is the last function, and is located just at the end
of
> > the first page. I would have thought that the linker would have
identified
> > that this code would not fit in the first fixed flash bank, and moved it
to
> > the second fixed flash bank, but this does not seem to have occured.
> >
> > Any help appeciated in working out how to get the linker to use both
fixed
> > flash bank correctly would be appreciated. It would be great if it could
> > work out itself which bank to put it in rather than me having to
manually
> > allocate to the second bank by altering the prm file and using #pragma
etc.
> >
> > Anyway, here is my prm file:
> >
> > NAMES
> > END
> >
> > SECTIONS
> > RAM = READ_WRITE 0x1000 TO 0x3FFF;
> > /* unbanked FLASH ROM */
> > FLASH_PAGE4000 = READ_ONLY 0x04000 TO 0x07FFF;
> > FLASH_PAGEC000 = READ_ONLY 0x0C000 TO 0x0FEFF;
> > EEPROM = READ_WRITE 0x0800 TO 0x0FFF;
> > END
> >
> > PLACEMENT
> > _PRESTART, STARTUP,
> > ROM_VAR, STRINGS,
> > NON_BANKED, DEFAULT_ROM,
> > COPY INTO FLASH_PAGE4000, FLASH_PAGEC000;
> > DEFAULT_RAM INTO RAM;
> > END
> >
> > STACKSIZE 0x100
> >
> > VECTOR ADDRESS 0xFFFE _Startup
> >
> >
> > ----- Original Message -----
> > From: "Adrian Vos" <>
> > To: <>
> > Sent: Monday, January 19, 2004 12:56 PM
> > Subject: [68HC12] Metrowerks banked mode
> >
> >
> > > Hi All,
> > >
> > > I am using metrowerks v2, which I have 32k license for with s12DP256.
My
> > > code is approx 16k, and I am starting to get the following linker
error:
> > >
> > > L1907: Fixup overflow in _LDIVS, to _NEG_P type 3, at offset 0xB
> > >
> > > I also get the same error, but with differing offset, several times.
It
> > > seems to be unrelated to the actual code, but only occurs if I add
more
> > code
> > > to push the size over some boundary (no matter what code I add!!). I
> > assume
> > > my problem is that I am going over the first fixed page size which is
16k,
> > > and I need to do something to enable the banked memory option.
> > >
> > > I would appreciate if someone can point me in the direction of
> > documentation
> > > that can help me to sort out this problem. I will search myself, but I
> > > assume other here have had the same problem, and can point me in the
right
> > > direction quickly.
> > >
> > > Thanks,
> > >
> > > Adrian
> > >
> > >
> > > --------------------To learn more
> > about Motorola Microcontrollers, please visit
> > > http://www.motorola.com/mcu
> > > o learn more about Motorola Microcontrollers, please visit
> > > http://www.motorola.com/mcu
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --------------------To learn more
about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> > o learn more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> >
> >
> >
> >
> >
>
> --------------------To learn more
about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu





Hallo Adrian,

For CW HC12 2.0 you can disable the linker error message for this case with -WmsgSd1110.
The linker contained in CW HC12 V3.0 does allow your syntax even without this option.

Apart from disabling the message, the only way I see with V2.0 is to put some functions into a separate, non default section.
:-(.

Anyway, be prepared to use "-OnB=b" if you want to distribute a section containing non banked code into multiple segments.
Note that with banked code this problem does not occur.

Bye

Daniel

> -----Original Message-----
> From: Adrian Vos [mailto:]
> Sent: Tuesday, January 20, 2004 1:30
> To:
> Subject: Re: [68HC12] Metrowerks banked mode > Thanks Daniel,
>
> That was what I was after!!
>
> Just another question since you seem to understand it well. I played around
> a bit, and thought the optimal setup would be to hardwire all segmaents but
> DEFAULT_ROM to once section, and then allocate DEFAULT_ROM (with my user
> code) across both, but the linker will not accept this. I am currently using
> successfully:
>
> DEFAULT_ROM INTO FLASH_PAGE4000;
> _PRESTART, STARTUP,
> ROM_VAR, STRINGS,
> NON_BANKED, COPY INTO FLASH_PAGEC000;
>
> but DEFAULT_ROM is using about 13k of FLASH_PAGE4000 which will run out
> shortly, and the other segments are using very little of FLASH_PAGEC000. I
> would prefer to do something like:
>
> DEFAULT_ROM INTO FLASH_PAGE4000, FLASH_PAGEC000;
> _PRESTART, STARTUP,
> ROM_VAR, STRINGS,
> NON_BANKED, COPY INTO FLASH_PAGEC000;
>
> which allows the DEFAULT_ROM to overflow into the second page, but it does
> not like this (you cannot used the same section page more than once). Is
> there any way to fully utilise the unbanked 32k for my user code before
> having to resort to banked mode?
>
> Thanks again for your help.
>
> Regards,
>
> Adrian > ----- Original Message -----
> From: "Daniel Friederich" <>
> To: <>
> Sent: Tuesday, January 20, 2004 1:47 AM
> Subject: RE: [68HC12] Metrowerks banked mode > > Hi Adrian,
> >
> > The problem is that _LDIVS is calling NEG_P with a 8 bit relative offset:
> >
> > 1233: void NEAR _LDIVS (void) { /* a = a / b signed */
> > ...
> > 000a 0700 BSR _NEG_P
> > ..
> >
> >
> > This works fine as long as you do allocate the NON_BANKED section into one
> single placement.
> > However for your app it looks like all the others would just fill up the
> FLASH_PAGE4000 segment so
> > that _NEG_P does still fit into it and _LDIVS is allocated in
> FLASH_PAGEC000.
> >
> > So now what you can do about it:
> >
> > 1. Change the allocation order in your prm file.
> > The problem with this solution is that it does not really resolve the p
> roblem but instead it just tries to avoid it.
> > 2. Build rtshc12.c with the option -OnB=b.
> > Either rebuild the whole library (lib\hc12c\hc12_lib.mcp) or add
> rtshc12.c to your project and
> > add the option in your project. For the second one, make sure
> rtshc12.c.o is before the ansi library in your link order.
> > 3. Distribute the NON_BANKED section manually to either FLASH_PAGE4000 or
> FLASH_PAGEC000, but not to both.
> >
> > > PLACEMENT
> > > _PRESTART, STARTUP,
> > > ROM_VAR, STRINGS INTO FLASH_PAGE4000
> > > NON_BANKED, DEFAULT_ROM,
> > > COPY INTO FLASH_PAGEC000;
> > > DEFAULT_RAM INTO RAM;
> > > END
> >
> > Hope this helps.
> >
> > Daniel
> >
> >
> >
> > > -----Original Message-----
> > > From: Adrian Vos [mailto:]
> > > Sent: Monday, January 19, 2004 3:43
> > > To:
> > > Subject: Re: [68HC12] Metrowerks banked mode
> > >
> > >
> > > It seems I was a little hasty in my last email. I have done further
> > > investigation.
> > >
> > > I was previously using the Flash Application Target, and I changed it to
> > > Banked Flash Target, and it compiles fine, but I do not see why I should
> > > need to use banked flash yet. My code is 16k, and, and there is 2 fixed
> > > flash banks of 16k, so I should be able to go to 32k which is the limit
> of
> > > my license anyway. I have checked the PRM file which looks right, and I
> have
> > > attached below. It looks like the fixed pages are correctly allocated
> for a
> > > total unbanked memory size of 32k. I checked my map files from the last
> > > successful compile when I was under 16k, and the _LDIVS code which is
> > > causing the problem is the last function, and is located just at the end
> of
> > > the first page. I would have thought that the linker would have
> identified
> > > that this code would not fit in the first fixed flash bank, and moved it
> to
> > > the second fixed flash bank, but this does not seem to have occured.
> > >
> > > Any help appeciated in working out how to get the linker to use both
> fixed
> > > flash bank correctly would be appreciated. It would be great if it could
> > > work out itself which bank to put it in rather than me having to
> manually
> > > allocate to the second bank by altering the prm file and using #pragma
> etc.
> > >
> > > Anyway, here is my prm file:
> > >
> > > NAMES
> > > END
> > >
> > > SECTIONS
> > > RAM = READ_WRITE 0x1000 TO 0x3FFF;
> > > /* unbanked FLASH ROM */
> > > FLASH_PAGE4000 = READ_ONLY 0x04000 TO 0x07FFF;
> > > FLASH_PAGEC000 = READ_ONLY 0x0C000 TO 0x0FEFF;
> > > EEPROM = READ_WRITE 0x0800 TO 0x0FFF;
> > > END
> > >
> > > PLACEMENT
> > > _PRESTART, STARTUP,
> > > ROM_VAR, STRINGS,
> > > NON_BANKED, DEFAULT_ROM,
> > > COPY INTO FLASH_PAGE4000, FLASH_PAGEC000;
> > > DEFAULT_RAM INTO RAM;
> > > END
> > >
> > > STACKSIZE 0x100
> > >
> > > VECTOR ADDRESS 0xFFFE _Startup
> > >
> > >
> > > ----- Original Message -----
> > > From: "Adrian Vos" <>
> > > To: <>
> > > Sent: Monday, January 19, 2004 12:56 PM
> > > Subject: [68HC12] Metrowerks banked mode
> > >
> > >
> > > > Hi All,
> > > >
> > > > I am using metrowerks v2, which I have 32k license for with s12DP256.
> My
> > > > code is approx 16k, and I am starting to get the following linker
> error:
> > > >
> > > > L1907: Fixup overflow in _LDIVS, to _NEG_P type 3, at offset 0xB
> > > >
> > > > I also get the same error, but with differing offset, several times.
> It
> > > > seems to be unrelated to the actual code, but only occurs if I add
> more
> > > code
> > > > to push the size over some boundary (no matter what code I add!!). I
> > > assume
> > > > my problem is that I am going over the first fixed page size which is
> 16k,
> > > > and I need to do something to enable the banked memory option.
> > > >
> > > > I would appreciate if someone can point me in the direction of
> > > documentation
> > > > that can help me to sort out this problem. I will search myself, but I
> > > > assume other here have had the same problem, and can point me in the
> right
> > > > direction quickly.
> > > >
> > > > Thanks,
> > > >
> > > > Adrian
> > > >
> > > >
> > > > --------------------To learn more
> > > about Motorola Microcontrollers, please visit
> > > > http://www.motorola.com/mcu
> > > > o learn more about Motorola Microcontrollers, please visit
> > > > http://www.motorola.com/mcu
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > --------------------To learn more
> about Motorola Microcontrollers, please visit
> > > http://www.motorola.com/mcu
> > > o learn more about Motorola Microcontrollers, please visit
> > > http://www.motorola.com/mcu
> > >
> > >
> > >
> > >
> > >
> >
> > --------------------To learn more
> about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> > o learn more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> >
> >
> >
> >
> > --------------------To learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu >
>




Note that the file boot256... has the following error:
SRecFmtStr: dc.b $0d,$0a,"Bad S-Record Format",$0d,$0a
It should be:
SRecFmtStr: dc.b $0d,$0a,"Bad S-Record Format",$0d,$0a,0
Otherwise the error routine will look thru the file for stray characters
to send to the terminal until it does.

Rod Niner
GSE Scales
42860 Nine Mile Road
Novi, MI 48375-4122
ph: 248.596.3350 The information contained in this electronic mail transmission is intended
by SPX Corporation for the use of the named individual or entity to which
it is directed and may contain information that is confidential or
privileged. If you have received this electronic mail transmission in
error, please delete it from your system without copying or forwarding it,
and notify the sender of the error by reply email so that the sender's
address records can be corrected.




Thanks Daniel,

Just one more question if you don't mind. I have a 32k license for CW HC12
2.0. If I use v3.0, will this license work, or must I purchase a new license
for v3.0?

Cheers,

Adrian

----- Original Message -----
From: "Daniel Friederich" <>
To: <>
Sent: Wednesday, January 21, 2004 2:49 AM
Subject: RE: [68HC12] Metrowerks banked mode > Hallo Adrian,
>
> For CW HC12 2.0 you can disable the linker error message for this case
with -WmsgSd1110.
> The linker contained in CW HC12 V3.0 does allow your syntax even without
this option.
>
> Apart from disabling the message, the only way I see with V2.0 is to put
some functions into a separate, non default section.
> :-(.
>
> Anyway, be prepared to use "-OnB=b" if you want to distribute a section
containing non banked code into multiple segments.
> Note that with banked code this problem does not occur.
>
> Bye
>
> Daniel
>
> > -----Original Message-----
> > From: Adrian Vos [mailto:]
> > Sent: Tuesday, January 20, 2004 1:30
> > To:
> > Subject: Re: [68HC12] Metrowerks banked mode
> >
> >
> > Thanks Daniel,
> >
> > That was what I was after!!
> >
> > Just another question since you seem to understand it well. I played
around
> > a bit, and thought the optimal setup would be to hardwire all segmaents
but
> > DEFAULT_ROM to once section, and then allocate DEFAULT_ROM (with my user
> > code) across both, but the linker will not accept this. I am currently
using
> > successfully:
> >
> > DEFAULT_ROM INTO FLASH_PAGE4000;
> > _PRESTART, STARTUP,
> > ROM_VAR, STRINGS,
> > NON_BANKED, COPY INTO FLASH_PAGEC000;
> >
> > but DEFAULT_ROM is using about 13k of FLASH_PAGE4000 which will run out
> > shortly, and the other segments are using very little of FLASH_PAGEC000.
I
> > would prefer to do something like:
> >
> > DEFAULT_ROM INTO FLASH_PAGE4000, FLASH_PAGEC000;
> > _PRESTART, STARTUP,
> > ROM_VAR, STRINGS,
> > NON_BANKED, COPY INTO FLASH_PAGEC000;
> >
> > which allows the DEFAULT_ROM to overflow into the second page, but it
does
> > not like this (you cannot used the same section page more than once). Is
> > there any way to fully utilise the unbanked 32k for my user code before
> > having to resort to banked mode?
> >
> > Thanks again for your help.
> >
> > Regards,
> >
> > Adrian
> >
> >
> > ----- Original Message -----
> > From: "Daniel Friederich" <>
> > To: <>
> > Sent: Tuesday, January 20, 2004 1:47 AM
> > Subject: RE: [68HC12] Metrowerks banked mode
> >
> >
> > > Hi Adrian,
> > >
> > > The problem is that _LDIVS is calling NEG_P with a 8 bit relative
offset:
> > >
> > > 1233: void NEAR _LDIVS (void) { /* a = a / b signed */
> > > ...
> > > 000a 0700 BSR _NEG_P
> > > ..
> > >
> > >
> > > This works fine as long as you do allocate the NON_BANKED section into
one
> > single placement.
> > > However for your app it looks like all the others would just fill up
the
> > FLASH_PAGE4000 segment so
> > > that _NEG_P does still fit into it and _LDIVS is allocated in
> > FLASH_PAGEC000.
> > >
> > > So now what you can do about it:
> > >
> > > 1. Change the allocation order in your prm file.
> > > The problem with this solution is that it does not really resolve
the p
> > roblem but instead it just tries to avoid it.
> > > 2. Build rtshc12.c with the option -OnB=b.
> > > Either rebuild the whole library (lib\hc12c\hc12_lib.mcp) or add
> > rtshc12.c to your project and
> > > add the option in your project. For the second one, make sure
> > rtshc12.c.o is before the ansi library in your link order.
> > > 3. Distribute the NON_BANKED section manually to either FLASH_PAGE4000
or
> > FLASH_PAGEC000, but not to both.
> > >
> > > > PLACEMENT
> > > > _PRESTART, STARTUP,
> > > > ROM_VAR, STRINGS INTO FLASH_PAGE4000
> > > > NON_BANKED, DEFAULT_ROM,
> > > > COPY INTO FLASH_PAGEC000;
> > > > DEFAULT_RAM INTO RAM;
> > > > END
> > >
> > > Hope this helps.
> > >
> > > Daniel
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Adrian Vos [mailto:]
> > > > Sent: Monday, January 19, 2004 3:43
> > > > To:
> > > > Subject: Re: [68HC12] Metrowerks banked mode
> > > >
> > > >
> > > > It seems I was a little hasty in my last email. I have done further
> > > > investigation.
> > > >
> > > > I was previously using the Flash Application Target, and I changed
it to
> > > > Banked Flash Target, and it compiles fine, but I do not see why I
should
> > > > need to use banked flash yet. My code is 16k, and, and there is 2
fixed
> > > > flash banks of 16k, so I should be able to go to 32k which is the
limit
> > of
> > > > my license anyway. I have checked the PRM file which looks right,
and I
> > have
> > > > attached below. It looks like the fixed pages are correctly
allocated
> > for a
> > > > total unbanked memory size of 32k. I checked my map files from the
last
> > > > successful compile when I was under 16k, and the _LDIVS code which
is
> > > > causing the problem is the last function, and is located just at the
end
> > of
> > > > the first page. I would have thought that the linker would have
> > identified
> > > > that this code would not fit in the first fixed flash bank, and
moved it
> > to
> > > > the second fixed flash bank, but this does not seem to have occured.
> > > >
> > > > Any help appeciated in working out how to get the linker to use both
> > fixed
> > > > flash bank correctly would be appreciated. It would be great if it
could
> > > > work out itself which bank to put it in rather than me having to
> > manually
> > > > allocate to the second bank by altering the prm file and using
#pragma
> > etc.
> > > >
> > > > Anyway, here is my prm file:
> > > >
> > > > NAMES
> > > > END
> > > >
> > > > SECTIONS
> > > > RAM = READ_WRITE 0x1000 TO 0x3FFF;
> > > > /* unbanked FLASH ROM */
> > > > FLASH_PAGE4000 = READ_ONLY 0x04000 TO 0x07FFF;
> > > > FLASH_PAGEC000 = READ_ONLY 0x0C000 TO 0x0FEFF;
> > > > EEPROM = READ_WRITE 0x0800 TO 0x0FFF;
> > > > END
> > > >
> > > > PLACEMENT
> > > > _PRESTART, STARTUP,
> > > > ROM_VAR, STRINGS,
> > > > NON_BANKED, DEFAULT_ROM,
> > > > COPY INTO FLASH_PAGE4000, FLASH_PAGEC000;
> > > > DEFAULT_RAM INTO RAM;
> > > > END
> > > >
> > > > STACKSIZE 0x100
> > > >
> > > > VECTOR ADDRESS 0xFFFE _Startup
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Adrian Vos" <>
> > > > To: <>
> > > > Sent: Monday, January 19, 2004 12:56 PM
> > > > Subject: [68HC12] Metrowerks banked mode
> > > >
> > > >
> > > > > Hi All,
> > > > >
> > > > > I am using metrowerks v2, which I have 32k license for with
s12DP256.
> > My
> > > > > code is approx 16k, and I am starting to get the following linker
> > error:
> > > > >
> > > > > L1907: Fixup overflow in _LDIVS, to _NEG_P type 3, at offset 0xB
> > > > >
> > > > > I also get the same error, but with differing offset, several
times.
> > It
> > > > > seems to be unrelated to the actual code, but only occurs if I add
> > more
> > > > code
> > > > > to push the size over some boundary (no matter what code I add!!).
I
> > > > assume
> > > > > my problem is that I am going over the first fixed page size which
is
> > 16k,
> > > > > and I need to do something to enable the banked memory option.
> > > > >
> > > > > I would appreciate if someone can point me in the direction of
> > > > documentation
> > > > > that can help me to sort out this problem. I will search myself,
but I
> > > > > assume other here have had the same problem, and can point me in
the
> > right
> > > > > direction quickly.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Adrian
> > > > >
> > > > >
> > > > > --------------------To learn
more
> > > > about Motorola Microcontrollers, please visit
> > > > > http://www.motorola.com/mcu
> > > > > o learn more about Motorola Microcontrollers, please visit
> > > > > http://www.motorola.com/mcu
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --------------------To learn
more
> > about Motorola Microcontrollers, please visit
> > > > http://www.motorola.com/mcu
> > > > o learn more about Motorola Microcontrollers, please visit
> > > > http://www.motorola.com/mcu
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > --------------------To learn more
> > about Motorola Microcontrollers, please visit
> > > http://www.motorola.com/mcu
> > > o learn more about Motorola Microcontrollers, please visit
> > > http://www.motorola.com/mcu
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --------------------To learn more
about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> > o learn more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> >
> >
> >
> >
> >
> >
>
> --------------------To learn more
about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu





Rod,

Sorry about that! I'll have a corrected version up on the web in the
next day or so.

Regards,
Gordon

wrote:

>Note that the file boot256... has the following error:
>SRecFmtStr: dc.b $0d,$0a,"Bad S-Record Format",$0d,$0a
>It should be:
>SRecFmtStr: dc.b $0d,$0a,"Bad S-Record Format",$0d,$0a,0
>Otherwise the error routine will look thru the file for stray characters
>to send to the terminal until it does.
>
>Rod Niner
>GSE Scales
>42860 Nine Mile Road
>Novi, MI 48375-4122
>ph: 248.596.3350 >The information contained in this electronic mail transmission is intended
>by SPX Corporation for the use of the named individual or entity to which
>it is directed and may contain information that is confidential or
>privileged. If you have received this electronic mail transmission in
>error, please delete it from your system without copying or forwarding it,
>and notify the sender of the error by reply email so that the sender's
>address records can be corrected. >
>
>--------------------To learn more about Motorola Microcontrollers, please visit
>http://www.motorola.com/mcu
>o learn more about Motorola Microcontrollers, please visit
>http://www.motorola.com/mcu >

--
===============================================================
Gordon Doughman Ph: 937-438-6811
Motorola Semiconductor Fax: 937-434-7457
Field Applications Engineer Pager: 800-759-8352 Pin: 1304089
Suite 175
3131 Newmark Drive
Miamisburg, OH 45342

Check out my HC12 book at:
http://www.rtcbooks.com/programming.php



The V2.0 license does not work for V3.0.

:-(

Bye

Daniel
> -----Original Message-----
> From: Adrian Vos [mailto:]
> Sent: Tuesday, January 20, 2004 23:24
> To:
> Subject: Re: [68HC12] Metrowerks banked mode > Thanks Daniel,
>
> Just one more question if you don't mind. I have a 32k license for CW HC12
> 2.0. If I use v3.0, will this license work, or must I purchase a new license
> for v3.0?
>
> Cheers,
>
> Adrian
>
> ----- Original Message -----
> From: "Daniel Friederich" <>
> To: <>
> Sent: Wednesday, January 21, 2004 2:49 AM
> Subject: RE: [68HC12] Metrowerks banked mode > > Hallo Adrian,
> >
> > For CW HC12 2.0 you can disable the linker error message for this case
> with -WmsgSd1110.
> > The linker contained in CW HC12 V3.0 does allow your syntax even without
> this option.
> >
> > Apart from disabling the message, the only way I see with V2.0 is to put
> some functions into a separate, non default section.
> > :-(.
> >
> > Anyway, be prepared to use "-OnB=b" if you want to distribute a section
> containing non banked code into multiple segments.
> > Note that with banked code this problem does not occur.
> >
> > Bye
> >
> > Daniel
> >
> > > -----Original Message-----
> > > From: Adrian Vos [mailto:]
> > > Sent: Tuesday, January 20, 2004 1:30
> > > To:
> > > Subject: Re: [68HC12] Metrowerks banked mode
> > >
> > >
> > > Thanks Daniel,
> > >
> > > That was what I was after!!
> > >
> > > Just another question since you seem to understand it well. I played
> around
> > > a bit, and thought the optimal setup would be to hardwire all segmaents
> but
> > > DEFAULT_ROM to once section, and then allocate DEFAULT_ROM (with my user
> > > code) across both, but the linker will not accept this. I am currently
> using
> > > successfully:
> > >
> > > DEFAULT_ROM INTO FLASH_PAGE4000;
> > > _PRESTART, STARTUP,
> > > ROM_VAR, STRINGS,
> > > NON_BANKED, COPY INTO FLASH_PAGEC000;
> > >
> > > but DEFAULT_ROM is using about 13k of FLASH_PAGE4000 which will run out
> > > shortly, and the other segments are using very little of FLASH_PAGEC000.
> I
> > > would prefer to do something like:
> > >
> > > DEFAULT_ROM INTO FLASH_PAGE4000, FLASH_PAGEC000;
> > > _PRESTART, STARTUP,
> > > ROM_VAR, STRINGS,
> > > NON_BANKED, COPY INTO FLASH_PAGEC000;
> > >
> > > which allows the DEFAULT_ROM to overflow into the second page, but it
> does
> > > not like this (you cannot used the same section page more than once). Is
> > > there any way to fully utilise the unbanked 32k for my user code before
> > > having to resort to banked mode?
> > >
> > > Thanks again for your help.
> > >
> > > Regards,
> > >
> > > Adrian
> > >
> > >
> > > ----- Original Message -----
> > > From: "Daniel Friederich" <>
> > > To: <>
> > > Sent: Tuesday, January 20, 2004 1:47 AM
> > > Subject: RE: [68HC12] Metrowerks banked mode
> > >
> > >
> > > > Hi Adrian,
> > > >
> > > > The problem is that _LDIVS is calling NEG_P with a 8 bit relative
> offset:
> > > >
> > > > 1233: void NEAR _LDIVS (void) { /* a = a / b signed */
> > > > ...
> > > > 000a 0700 BSR _NEG_P
> > > > ..
> > > >
> > > >
> > > > This works fine as long as you do allocate the NON_BANKED section into
> one
> > > single placement.
> > > > However for your app it looks like all the others would just fill up
> the
> > > FLASH_PAGE4000 segment so
> > > > that _NEG_P does still fit into it and _LDIVS is allocated in
> > > FLASH_PAGEC000.
> > > >
> > > > So now what you can do about it:
> > > >
> > > > 1. Change the allocation order in your prm file.
> > > > The problem with this solution is that it does not really resolve
> the p
> > > roblem but instead it just tries to avoid it.
> > > > 2. Build rtshc12.c with the option -OnB=b.
> > > > Either rebuild the whole library (lib\hc12c\hc12_lib.mcp) or add
> > > rtshc12.c to your project and
> > > > add the option in your project. For the second one, make sure
> > > rtshc12.c.o is before the ansi library in your link order.
> > > > 3. Distribute the NON_BANKED section manually to either FLASH_PAGE4000
> or
> > > FLASH_PAGEC000, but not to both.
> > > >
> > > > > PLACEMENT
> > > > > _PRESTART, STARTUP,
> > > > > ROM_VAR, STRINGS INTO FLASH_PAGE4000
> > > > > NON_BANKED, DEFAULT_ROM,
> > > > > COPY INTO FLASH_PAGEC000;
> > > > > DEFAULT_RAM INTO RAM;
> > > > > END
> > > >
> > > > Hope this helps.
> > > >
> > > > Daniel
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Adrian Vos [mailto:]
> > > > > Sent: Monday, January 19, 2004 3:43
> > > > > To:
> > > > > Subject: Re: [68HC12] Metrowerks banked mode
> > > > >
> > > > >
> > > > > It seems I was a little hasty in my last email. I have done further
> > > > > investigation.
> > > > >
> > > > > I was previously using the Flash Application Target, and I changed
> it to
> > > > > Banked Flash Target, and it compiles fine, but I do not see why I
> should
> > > > > need to use banked flash yet. My code is 16k, and, and there is 2
> fixed
> > > > > flash banks of 16k, so I should be able to go to 32k which is the
> limit
> > > of
> > > > > my license anyway. I have checked the PRM file which looks right,
> and I
> > > have
> > > > > attached below. It looks like the fixed pages are correctly
> allocated
> > > for a
> > > > > total unbanked memory size of 32k. I checked my map files from the
> last
> > > > > successful compile when I was under 16k, and the _LDIVS code which
> is
> > > > > causing the problem is the last function, and is located just at the
> end
> > > of
> > > > > the first page. I would have thought that the linker would have
> > > identified
> > > > > that this code would not fit in the first fixed flash bank, and
> moved it
> > > to
> > > > > the second fixed flash bank, but this does not seem to have occured.
> > > > >
> > > > > Any help appeciated in working out how to get the linker to use both
> > > fixed
> > > > > flash bank correctly would be appreciated. It would be great if it
> could
> > > > > work out itself which bank to put it in rather than me having to
> > > manually
> > > > > allocate to the second bank by altering the prm file and using
> #pragma
> > > etc.
> > > > >
> > > > > Anyway, here is my prm file:
> > > > >
> > > > > NAMES
> > > > > END
> > > > >
> > > > > SECTIONS
> > > > > RAM = READ_WRITE 0x1000 TO 0x3FFF;
> > > > > /* unbanked FLASH ROM */
> > > > > FLASH_PAGE4000 = READ_ONLY 0x04000 TO 0x07FFF;
> > > > > FLASH_PAGEC000 = READ_ONLY 0x0C000 TO 0x0FEFF;
> > > > > EEPROM = READ_WRITE 0x0800 TO 0x0FFF;
> > > > > END
> > > > >
> > > > > PLACEMENT
> > > > > _PRESTART, STARTUP,
> > > > > ROM_VAR, STRINGS,
> > > > > NON_BANKED, DEFAULT_ROM,
> > > > > COPY INTO FLASH_PAGE4000, FLASH_PAGEC000;
> > > > > DEFAULT_RAM INTO RAM;
> > > > > END
> > > > >
> > > > > STACKSIZE 0x100
> > > > >
> > > > > VECTOR ADDRESS 0xFFFE _Startup
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Adrian Vos" <>
> > > > > To: <>
> > > > > Sent: Monday, January 19, 2004 12:56 PM
> > > > > Subject: [68HC12] Metrowerks banked mode
> > > > >
> > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > I am using metrowerks v2, which I have 32k license for with
> s12DP256.
> > > My
> > > > > > code is approx 16k, and I am starting to get the following linker
> > > error:
> > > > > >
> > > > > > L1907: Fixup overflow in _LDIVS, to _NEG_P type 3, at offset 0xB
> > > > > >
> > > > > > I also get the same error, but with differing offset, several
> times.
> > > It
> > > > > > seems to be unrelated to the actual code, but only occurs if I add
> > > more
> > > > > code
> > > > > > to push the size over some boundary (no matter what code I add!!).
> I
> > > > > assume
> > > > > > my problem is that I am going over the first fixed page size which
> is
> > > 16k,
> > > > > > and I need to do something to enable the banked memory option.
> > > > > >
> > > > > > I would appreciate if someone can point me in the direction of
> > > > > documentation
> > > > > > that can help me to sort out this problem. I will search myself,
> but I
> > > > > > assume other here have had the same problem, and can point me in
> the
> > > right
> > > > > > direction quickly.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Adrian
> > > > > >
> > > > > >
> > > > > > --------------------To learn
> more
> > > > > about Motorola Microcontrollers, please visit
> > > > > > http://www.motorola.com/mcu
> > > > > > o learn more about Motorola Microcontrollers, please visit
> > > > > > http://www.motorola.com/mcu
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --------------------To learn
> more
> > > about Motorola Microcontrollers, please visit
> > > > > http://www.motorola.com/mcu
> > > > > o learn more about Motorola Microcontrollers, please visit
> > > > > http://www.motorola.com/mcu
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > --------------------To learn more
> > > about Motorola Microcontrollers, please visit
> > > > http://www.motorola.com/mcu
> > > > o learn more about Motorola Microcontrollers, please visit
> > > > http://www.motorola.com/mcu
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > --------------------To learn more
> about Motorola Microcontrollers, please visit
> > > http://www.motorola.com/mcu
> > > o learn more about Motorola Microcontrollers, please visit
> > > http://www.motorola.com/mcu
> > >
> > >
> > >
> > >
> > >
> > >
> >
> > --------------------To learn more
> about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> > o learn more about Motorola Microcontrollers, please visit
> > http://www.motorola.com/mcu
> >
> >
> >
> >
> > --------------------To learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu
> o learn more about Motorola Microcontrollers, please visit
> http://www.motorola.com/mcu >
>