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 |
|
Metrowerks banked mode
Started by ●January 18, 2004
Reply by ●January 18, 20042004-01-18
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 |
|
Reply by ●January 19, 20042004-01-19
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 > |
Reply by ●January 19, 20042004-01-19
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 |
|
Reply by ●January 20, 20042004-01-20
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 > > |
|
Reply by ●January 20, 20042004-01-20
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. |
|
Reply by ●January 20, 20042004-01-20
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 |
|
Reply by ●January 21, 20042004-01-21
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 |
Reply by ●January 22, 20042004-01-22
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 > > |