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 > > |