As indicated in my posts of a week or two ago, I am getting problems
very similar to Adrian's and I am using CW v3.0 with an HCS12C64 chip,
downloading through the serial monitor. I too use small bank memory, set
the PPAGE in startup.c, don't care about the paging aspect for now --
just want the extra 16k. I got it to work, such that main.c fit in the
3C8000 - block and the subroutines it called were placed in the C000
block. I then added some code to main so that it wouldn't fit in the
3C8000 block; the linker said it was moving 3C8000 to 8000 and nothing
worked. So I pulled out some code from main and made it into a
subroutine, thinking it would just place it in C000 block with the rest
of the subroutines - plenty of space there- and main would now fit in
the 3CD8000 block. But this did not work - the subroutines were placed
at the beginning of the 3C8000 block and as best I remeber main followed
them. This wouldn't work when I tried to download.
Can a main program or a subroutine span across one of the 4 blocks
with small memory model ?
>
> Hi again, Adrian.
>
> I just posted a new driver compliant with CW12V2.x
>
>
ftp://ftp3.metrowerks.com/pub/dropzone/Mcu03c6_fpp_flat8000_p30_proto_19Jul0
>
> 5.zip
>
> Just for info: The CW12V31 drivers program only words and the debugger
> asserts byte patterning for uncompleted words. In CW12V2.x, this is
> done by
> the driver itself, allowing byte programming. We had to eliminate word
> rewriting in some cases.
>
> Adrian, if this still does not work, you can send me your project or an
> example project showing this problem.
>
> You can also try the following mapping defining one single block of
flash.
>
> Regards,
> Gilles
>
Metrowerks small memory model banked memory
Started by ●July 18, 2005
Reply by ●July 19, 20052005-07-19
Reply by ●July 19, 20052005-07-19
Yes, because the CPU execution is not aware of the boundaries. It's
all just 64K of memory. That means the problem is in telling CW how to
link it, and the loader how to load it.
I do this stuff on GCC, so it should be simple. I just don't know how
to do it with CodeWarrior.
--- In 68HC12@68HC..., Al Grippo <grippo@j...> wrote:
...
> Can a main program or a subroutine span across one of the 4 blocks
> with small memory model ?
>
all just 64K of memory. That means the problem is in telling CW how to
link it, and the loader how to load it.
I do this stuff on GCC, so it should be simple. I just don't know how
to do it with CodeWarrior.
--- In 68HC12@68HC..., Al Grippo <grippo@j...> wrote:
...
> Can a main program or a subroutine span across one of the 4 blocks
> with small memory model ?
>
Reply by ●July 19, 20052005-07-19
P.S. I think you should call them banks instead of blocks. The term
block is used to indicate a larger chunk of Flash (dp256 has four 64K
blocks), as defined in their device guides.
--- In 68HC12@68HC..., Al Grippo <grippo@j...> wrote:
> 3C8000 - block and the subroutines it called were placed in the C000
> block. I then added some code to main so that it wouldn't fit in the
block is used to indicate a larger chunk of Flash (dp256 has four 64K
blocks), as defined in their device guides.
--- In 68HC12@68HC..., Al Grippo <grippo@j...> wrote:
> 3C8000 - block and the subroutines it called were placed in the C000
> block. I then added some code to main so that it wouldn't fit in the
Reply by ●July 19, 20052005-07-19
See below.
Al Grippo wrote:
> As indicated in my posts of a week or two ago, I am getting problems
> very similar to Adrian's and I am using CW v3.0 with an HCS12C64 chip,
> downloading through the serial monitor. I too use small bank memory, set
> the PPAGE in startup.c, don't care about the paging aspect for now --
> just want the extra 16k. I got it to work, such that main.c fit in the
> 3C8000 - block and the subroutines it called were placed in the C000
> block. I then added some code to main so that it wouldn't fit in the
> 3C8000 block; the linker said it was moving 3C8000 to 8000 and nothing
I guess you mention here the linker message about cutting the main entry
in the startup data structure? The linker should not move things around
unless you tell him to.
> worked. So I pulled out some code from main and made it into a
> subroutine, thinking it would just place it in C000 block with the rest
> of the subroutines - plenty of space there- and main would now fit in
> the 3CD8000 block. But this did not work - the subroutines were placed
> at the beginning of the 3C8000 block and as best I remeber main followed
> them. This wouldn't work when I tried to download.
What exactly do you mean with this? This did not program the flash
correctly? By default, the linker allocates functions in the order they are defined
in the source code. The order between files depends on the link order
tab in CW.
If there ever was a gap, its not filled unless you use the -Alloc linker
option.
So if you want to have as much space for your main in one page, put your
main into its own section (#pragma CODE_SEG MAIN_SECTION) and then list
this MAIN_SECTION before all the other sections.
Then main should start at 3C8000.
Also note that whenever you place code from one section into multiple,
placements in the small memory model, use the -OnB=b compiler option.
>
> Can a main program or a subroutine span across one of the 4 blocks
> with small memory model ?
You want to allocate a > 16k main function into multiple pages?
If possible, I would avoid it. Theoretically this should be possible,
but I never tried. >
>
>>Hi again, Adrian.
>>
>>I just posted a new driver compliant with CW12V2.x
>>
>>ftp://ftp3.metrowerks.com/pub/dropzone/Mcu03c6_fpp_flat8000_p30_proto_19Jul0
>>
>>5.zip
>>
>>Just for info: The CW12V31 drivers program only words and the debugger
>>asserts byte patterning for uncompleted words. In CW12V2.x, this is
>>done by
>>the driver itself, allowing byte programming. We had to eliminate word
>>rewriting in some cases.
>>
>>Adrian, if this still does not work, you can send me your project or an
>>example project showing this problem.
>>
>>You can also try the following mapping defining one single block of flash.
>>
>>Regards,
>>Gilles
> > Yahoo! Groups Links >
Al Grippo wrote:
> As indicated in my posts of a week or two ago, I am getting problems
> very similar to Adrian's and I am using CW v3.0 with an HCS12C64 chip,
> downloading through the serial monitor. I too use small bank memory, set
> the PPAGE in startup.c, don't care about the paging aspect for now --
> just want the extra 16k. I got it to work, such that main.c fit in the
> 3C8000 - block and the subroutines it called were placed in the C000
> block. I then added some code to main so that it wouldn't fit in the
> 3C8000 block; the linker said it was moving 3C8000 to 8000 and nothing
I guess you mention here the linker message about cutting the main entry
in the startup data structure? The linker should not move things around
unless you tell him to.
> worked. So I pulled out some code from main and made it into a
> subroutine, thinking it would just place it in C000 block with the rest
> of the subroutines - plenty of space there- and main would now fit in
> the 3CD8000 block. But this did not work - the subroutines were placed
> at the beginning of the 3C8000 block and as best I remeber main followed
> them. This wouldn't work when I tried to download.
What exactly do you mean with this? This did not program the flash
correctly? By default, the linker allocates functions in the order they are defined
in the source code. The order between files depends on the link order
tab in CW.
If there ever was a gap, its not filled unless you use the -Alloc linker
option.
So if you want to have as much space for your main in one page, put your
main into its own section (#pragma CODE_SEG MAIN_SECTION) and then list
this MAIN_SECTION before all the other sections.
Then main should start at 3C8000.
Also note that whenever you place code from one section into multiple,
placements in the small memory model, use the -OnB=b compiler option.
>
> Can a main program or a subroutine span across one of the 4 blocks
> with small memory model ?
You want to allocate a > 16k main function into multiple pages?
If possible, I would avoid it. Theoretically this should be possible,
but I never tried. >
>
>>Hi again, Adrian.
>>
>>I just posted a new driver compliant with CW12V2.x
>>
>>ftp://ftp3.metrowerks.com/pub/dropzone/Mcu03c6_fpp_flat8000_p30_proto_19Jul0
>>
>>5.zip
>>
>>Just for info: The CW12V31 drivers program only words and the debugger
>>asserts byte patterning for uncompleted words. In CW12V2.x, this is
>>done by
>>the driver itself, allowing byte programming. We had to eliminate word
>>rewriting in some cases.
>>
>>Adrian, if this still does not work, you can send me your project or an
>>example project showing this problem.
>>
>>You can also try the following mapping defining one single block of flash.
>>
>>Regards,
>>Gilles
> > Yahoo! Groups Links >
Reply by ●July 19, 20052005-07-19
Next week I hope to be able to devote full time to this using the info
you have provided me. If i have problems, I will post the exact problem
and error messages.
Thank you,
-Al Grippo
> See below.
>
> Al Grippo wrote:
> > As indicated in my posts of a week or two ago, I am getting problems
> > very similar to Adrian's and I am using CW v3.0 with an HCS12C64 chip,
> > downloading through the serial monitor. I too use small bank memory,
> set
> > the PPAGE in startup.c, don't care about the paging aspect for now --
> > just want the extra 16k. I got it to work, such that main.c fit in the
> > 3C8000 - block and the subroutines it called were placed in the C000
> > block. I then added some code to main so that it wouldn't fit in the
> > 3C8000 block; the linker said it was moving 3C8000 to 8000 and nothing
>
> I guess you mention here the linker message about cutting the main entry
> in the startup data structure? The linker should not move things around
> unless you tell him to.
>
> > worked. So I pulled out some code from main and made it into a
> > subroutine, thinking it would just place it in C000 block with the
> rest
> > of the subroutines - plenty of space there- and main would now fit in
> > the 3CD8000 block. But this did not work - the subroutines were placed
> > at the beginning of the 3C8000 block and as best I remeber main
> followed
> > them. This wouldn't work when I tried to download.
> What exactly do you mean with this? This did not program the flash
> correctly? > By default, the linker allocates functions in the order they are defined
> in the source code. The order between files depends on the link order
> tab in CW.
> If there ever was a gap, its not filled unless you use the -Alloc linker
> option.
> So if you want to have as much space for your main in one page, put your
> main into its own section (#pragma CODE_SEG MAIN_SECTION) and then list
> this MAIN_SECTION before all the other sections.
> Then main should start at 3C8000.
>
> Also note that whenever you place code from one section into multiple,
> placements in the small memory model, use the -OnB=b compiler option.
>
> >
> > Can a main program or a subroutine span across one of the 4 blocks
> > with small memory model ?
>
> You want to allocate a > 16k main function into multiple pages?
> If possible, I would avoid it. Theoretically this should be possible,
> but I never tried.
>
you have provided me. If i have problems, I will post the exact problem
and error messages.
Thank you,
-Al Grippo
> See below.
>
> Al Grippo wrote:
> > As indicated in my posts of a week or two ago, I am getting problems
> > very similar to Adrian's and I am using CW v3.0 with an HCS12C64 chip,
> > downloading through the serial monitor. I too use small bank memory,
> set
> > the PPAGE in startup.c, don't care about the paging aspect for now --
> > just want the extra 16k. I got it to work, such that main.c fit in the
> > 3C8000 - block and the subroutines it called were placed in the C000
> > block. I then added some code to main so that it wouldn't fit in the
> > 3C8000 block; the linker said it was moving 3C8000 to 8000 and nothing
>
> I guess you mention here the linker message about cutting the main entry
> in the startup data structure? The linker should not move things around
> unless you tell him to.
>
> > worked. So I pulled out some code from main and made it into a
> > subroutine, thinking it would just place it in C000 block with the
> rest
> > of the subroutines - plenty of space there- and main would now fit in
> > the 3CD8000 block. But this did not work - the subroutines were placed
> > at the beginning of the 3C8000 block and as best I remeber main
> followed
> > them. This wouldn't work when I tried to download.
> What exactly do you mean with this? This did not program the flash
> correctly? > By default, the linker allocates functions in the order they are defined
> in the source code. The order between files depends on the link order
> tab in CW.
> If there ever was a gap, its not filled unless you use the -Alloc linker
> option.
> So if you want to have as much space for your main in one page, put your
> main into its own section (#pragma CODE_SEG MAIN_SECTION) and then list
> this MAIN_SECTION before all the other sections.
> Then main should start at 3C8000.
>
> Also note that whenever you place code from one section into multiple,
> placements in the small memory model, use the -OnB=b compiler option.
>
> >
> > Can a main program or a subroutine span across one of the 4 blocks
> > with small memory model ?
>
> You want to allocate a > 16k main function into multiple pages?
> If possible, I would avoid it. Theoretically this should be possible,
> but I never tried.
>
Reply by ●July 19, 20052005-07-19
I beleive they are called pages and not blocks.
Dave Jefferson Smith wrote:
> P.S. I think you should call them banks instead of blocks. The term
> block is used to indicate a larger chunk of Flash (dp256 has four 64K
> blocks), as defined in their device guides.
>
> --- In 68HC12@68HC..., Al Grippo <grippo@j...> wrote:
>
> > 3C8000 - block and the subroutines it called were placed in the C000
> > block. I then added some code to main so that it wouldn't fit in the > >. >
>
Dave Jefferson Smith wrote:
> P.S. I think you should call them banks instead of blocks. The term
> block is used to indicate a larger chunk of Flash (dp256 has four 64K
> blocks), as defined in their device guides.
>
> --- In 68HC12@68HC..., Al Grippo <grippo@j...> wrote:
>
> > 3C8000 - block and the subroutines it called were placed in the C000
> > block. I then added some code to main so that it wouldn't fit in the > >. >
>
Reply by ●July 19, 20052005-07-19
Also they are not the same as page0, so we should call them ppages
(stands for program pages). Then we all know they are the memory banks
selected by the PPAGE register.
--- In 68HC12@68HC..., Dave Perreault <dap@p...> wrote:
> I beleive they are called pages and not blocks.
>
> Dave > Jefferson Smith wrote:
>
> > P.S. I think you should call them banks instead of blocks. The term
> > block is used to indicate a larger chunk of Flash (dp256 has four 64K
> > blocks), as defined in their device guides.
> >
> > --- In 68HC12@68HC..., Al Grippo <grippo@j...> wrote:
> >
> > > 3C8000 - block and the subroutines it called were placed in the C000
> > > block. I then added some code to main so that it wouldn't fit in the
> >
> >
> >
> >
> >
> > >.
> >
> >
> >
> >
(stands for program pages). Then we all know they are the memory banks
selected by the PPAGE register.
--- In 68HC12@68HC..., Dave Perreault <dap@p...> wrote:
> I beleive they are called pages and not blocks.
>
> Dave > Jefferson Smith wrote:
>
> > P.S. I think you should call them banks instead of blocks. The term
> > block is used to indicate a larger chunk of Flash (dp256 has four 64K
> > blocks), as defined in their device guides.
> >
> > --- In 68HC12@68HC..., Al Grippo <grippo@j...> wrote:
> >
> > > 3C8000 - block and the subroutines it called were placed in the C000
> > > block. I then added some code to main so that it wouldn't fit in the
> >
> >
> >
> >
> >
> > >.
> >
> >
> >
> >
Reply by ●July 19, 20052005-07-19
This fixed my problem.... Thankyou very much Gilles!!
-- Adrian
----- Original Message -----
From: "Gilles Blanquin" <gilles.blanquin@gill...>
To: <68HC12@68HC...>
Sent: Tuesday, July 19, 2005 7:09 PM
Subject: Re: [68HC12] Metrowerks small memory model banked memory >
> Hi again, Adrian.
>
> I just posted a new driver compliant with CW12V2.x
>
> ftp://ftp3.metrowerks.com/pub/dropzone/Mcu03c6_fpp_flat8000_p30_proto_19Jul0
> 5.zip
>
> Just for info: The CW12V31 drivers program only words and the debugger
> asserts byte patterning for uncompleted words. In CW12V2.x, this is done
> by
> the driver itself, allowing byte programming. We had to eliminate word
> rewriting in some cases.
>
> Adrian, if this still does not work, you can send me your project or an
> example project showing this problem.
>
> You can also try the following mapping defining one single block of flash.
>
> Regards,
> Gilles > DEFAULT_RAM INTO READ_WRITE 0x1000 TO 0x3FFF;
>
> DEFAULT_ROM,_PRESTART, STARTUP,
> ROM_VAR, STRINGS,
> NON_BANKED, COPY INTO READ_ONLY 0x4000 TO 0xFEFF; >
> At 10:04 AM 7/19/2005, Gilles Blanquin wrote:
>>Hi Adrian.
>>
>>I am going to check the driver.
>>Indeed, the driver is design for CW12 V3.1 release, where the debugger
>>asserts WORD programming of the memory instead of Byte programming.
>>This is a flash strict restriction.
>>The new module I added is programming only word aligned code, but this
>>restriction does not exist in CW12 V2.0. While testing, I could not detect
>>that.
>>Let me regenerate the driver. I post it asap.
>>
>>Regards,
>>Gilles
>>
>>
>>
>>
>>
>>At 09:39 AM 7/19/2005, you wrote:
>> >Thanks Giles and all for your help.
>> >
>> >I loaded the driver from giles and it does seem to work, however I am
>> >having
>> >the strangest problem I encountered yet on the HCS12, and I am unaware
>> >of
>> >how to fix it.
>> >
>> >Basically I have 3 flash memories setup in the PRM file, and I load my
>> >main
>> >code first into the 4000-8000 range, and then the 8000-C000 range, and
>> >finally the C000-F000 range in link order. The code seemed the load in
>> >correctly using the new driver, and I have set the PPAGE register to 30
>> >in
>> >my startup code. However it would crash and not run.... so after a lot
>> >of
>> >stuffing around, I reduced the size of the 8000-C000 page to 8000-ADC1
>> >and
>> >it works correctly. I tracked it down to the linker placing one function
>> >in
>> >the middle page or the final. Anyway, I wanted to use the whole space,
>> >and
>> >unexplained issues like this annoy me, so I have been trying to work out
>> >why. I currently have the project setup so that on the last function
>> >before
>> >the end of the middle page, if I add a NOP in, it crashes, but if I
>> >remove
>> >it, it runs fine. All other functions remain unchanged and linked in the
>> >same position since this function I am working on is the last that fits
>> >into
>> >that page.
>> >
>> >I thought that maybe there was something about the address at the end of
>> >the
>> >function, so I left the NOP out, altered the Segments and used a VECTOR
>> >instruction in the PRM file to set that extra byte filled out by the NOP
>> >with the same data as when the NOP is in place... it works fine... no
>> >crash.... but if I add the NOP back in and remove the vector, it crashed
>> >again. There is literally 4 bytes different in the binary file output
>> >from
>> >the linker between the working and crashing files. The 4 bytes equate to
>> >the
>> >NOP, stack clean up and the RTS instruction for the function.
>> >
>> >It is crasy, but no matter what I do, it repeatably crashes (must jump
>> >out
>> >of my code) if I have the NOP, and repeatably works without it.
>> >
>> >The only conclusions I can come to are that the flash loader is doing
>> >something funny with my files at that address, or the S12 has some funny
>> >to
>> >do with trying to run code of out the paged memory in non banked small
>> >memory model code... but modt of the code works that resides in this
>> >area...
>> >just not at the later addresses. It is very frustrating, and I am happy
>> >for
>> >any debugging ideas... Unfortunately I cannot step my code at normal
>> >speed
>> >with the BDN I have, and in slow speed, I get strange operation... it
>> >will
>> >step the code as long as I do not step over a function, otehrwise it
>> >loses
>> >control of it.
>> >
>> >ANyway, as you can see, I am quite perplexed. Any advice appreciated.
>> >
>> >Gilles is it possible that driver is doing something unexpected?
>> >
>> >Cheers,
>> >
>> >Adrian
>> >
>> >----- Original Message -----
>> >From: "Gilles Blanquin" <gilles.blanquin@gill...>
>> >To: <68HC12@68HC...>
>> >Sent: Monday, July 18, 2005 5:32 PM
>> >Subject: Re: [68HC12] Metrowerks small memory model banked memory
>> >
>> >
>> > > Hi Adrian.
>> > >
>> > > Please find here the prototype driver I just tested.
>> > >
>> > > To be installed in "prog\fpp" folder of your CodeWarrior (backup the
>> > > previous file).
>> > >
>> > >
>> >
>> ftp://ftp3.metrowerks.com/pub/dropzone/Mcu03c6.fpp-flat8000_p30-proto-18-Jul
>> > > -05.zip
>> > >
>> > > Note that the chip has by default/reset the ppage $00 is set, which
>> > > is a
>> > > mirror of ppage $30 !
>> > >
>> > > The driver flashes the ppage $30.
>> > >
>> > > I just flashed the chip with a test srecord from $4000 to $ffff. You
>> > > can
>> > > then scroll the memory and see all the code flashed linearly.
>> > >
>> > > To my opinion, you don't even need to preset the ppage anywhere.
>> > >
>> > > Please try my prm setup, try to flash and give me your feedback.
>> > > Note that erasing is disabled in FLAT8000_P30. You can still erase
>> > > via
>> > > FLASH_3 module.
>> > >
>> > > Regards,
>> > > Gilles
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > At 09:04 AM 7/18/2005, you wrote:
>> > >>Hi Gilles,
>> > >>
>> > >>That is almost exactly what I am after. I was planning on seperating
>> > >>the
>> > >>linear space from 4000 to FFFF into 3 subsections:
>> > >>
>> > >>* 4000-7FFF
>> > >>* 8000-BFFF
>> > >>* C000-FEFF
>> > >>
>> > >>The reason for this is that I still wanted to be able to place
>> > >>startup
>> > >>code
>> > >>into a known fixed page (4000-7FFF or C000-FEFF), as the area
>> > >>8000-BFFF
>> > >>would not be available until initialisation code had initialised
>> > >>PPAGE to
>> > >>30.
>> > >>
>> > >>If I make it one continuous space, then the startup code may end up
>> in the
>> > >>paged section, which would be invalid before PPAGE was set (Can't
>> have the
>> > >>reset vector pointing to the range 8000-BFFF)
>> > >>
>> > >>The thing I am lacking at the moment is a method to tell the linker
>> > >>and
>> > >>true
>> > >>time simulator to allocate the code space in the 8000-BFFF range to
>> > >>the
>> > >>first page 30800 to 30BFFF (In the case of linking it should treat
>> > >>this
>> > >>range as 8000-BFFF, but the flash programmer should write it to
>> > >>308000 to
>> > >>30BFFF). If I can get this sorted, I believe it will all fall out
>> > >>nicely.
>> > >>I
>> > >>believe the driver changes you propose would solve my problem. The
>> > >>processor
>> > >>I am using is the DP256.
>> > >>
>> > >>Interestingly I get some other funny errors when I try to set this
>> > >>up.
>> > >>When
>> > >>I add the segment 8000-BFFF, and then allocate data to it in the
>> placement
>> > >>section, for some reason I get an L1903 "Unexpected symbol" error on
>> > >>linking
>> > >>pointing at one of my vector lines at the bottom of the PRM files.
>> > >>Seems
>> > >>to
>> > >>me be some sort of bug in parsing the PRM file. Not sure if your
>> > >>proposed
>> > >>changes will fix this linking issue or not. Let me know if you want
>> my PRM
>> > >>file.
>> > >>
>> > >>You are correct that the small memory model does not support banked
>> > >>mode.
>> > >>I
>> > >>do not wish to use banked mode as it has other limitations... I just
>> > >>want
>> > >>to
>> > >>use all the available ROM for small memory model non-banked mode.
>> > >>Unfortunately I can only get to 32k of the available 48k on the
>> memory map
>> > >>currently.
>> > >>
>> > >>Thanks,
>> > >>
>> > >>Adrian
>> > >>
>> > >>
>> > >>
>> > >>----- Original Message -----
>> > >>From: "Gilles Blanquin" <gilles.blanquin@gill...>
>> > >>To: <68HC12@68HC...>
>> > >>Sent: Monday, July 18, 2005 4:42 PM
>> > >>Subject: Re: [68HC12] Metrowerks small memory model banked memory
>> > >>
>> > >>
>> > >> > Hi Adrian.
>> > >> >
>> > >> > I guess, from your previous email, that you use a DP256. Indeed,
>> > >> > it
>> > >> > would
>> > >> > be possible to program the flash in a linear way from $4000 to
>> > >> > $FFFF,
>> > >> > saying that for DP256, the reset PPAGE is $30.
>> > >> > The Flash Programmer does not handle the default (reset) page
>> > >> > programming
>> > >> > in $8000-BFFF, so I would have to provide you this driver upgrade
>> which
>> > >> > will be available in next CodeWarrior release.
>> > >> >
>> > >> > I presume you would like to have a similar (small / non banked)
>> > >> > prm
>> > >> > mapping:
>> > >> >
>> > >> > DEFAULT_RAM INTO READ_WRITE 0x1000 TO 0x3FFF;
>> > >> >
>> > >> > DEFAULT_ROM,_PRESTART, STARTUP,
>> > >> > ROM_VAR, STRINGS,
>> > >> > NON_BANKED, COPY INTO READ_ONLY 0x4000 TO 0xFEFF;
>> > >> >
>> > >> > Please confirm this and the derivative used and I will make a
>> > >> > CW12V2.x
>> > >> > flash driver programming addresses $8000-bfff remapped to logical
>> > >> > $308000-30bfff.
>> > >> >
>> > >> > Regards,
>> > >> > Gilles
>> > >> >
>> > >> > P.S. As far as I remember, the small memory model is not
>> > >> > compatible
>> > >> > with
>> > >> > banked model.
>> > >> >
>> > >> >
>> > >> >
>> > >> > At 07:38 AM 7/18/2005, Adrian Vos wrote:
>> > >> >>Hi All,
>> > >> >>
>> > >> >>I am using Metrowerks for HCS12 v2.0. In the small memory model it
>> > >> >>is
>> > >> >>easy
>> > >> >>to get access to the 2 16k fixed flash pages, but I am running out
>> > >> >>of
>> > >> >>code
>> > >> >>space as I quickly approach 32k code size. I was hoping to write
>> > >> >>into
>> > >> >>my
>> > >> >>start code some code to fix the PPAGE register at a particular
>> > >> >>page
>> > >> >>(not
>> > >> >>3E
>> > >> >>of 3F which are the fixed pages), and then utilise the banked
>> > >> >>memory
>> > >> >>range
>> > >> >>to extend to 48k of usable ROM whilst still using the small memory
>> > >> >>model.
>> > >> >>I
>> > >> >>am not sure how to do this with the PRM file, and I was hoping
>> > >> >>someone
>> > >> >>could
>> > >> >>tell me. I try setting a new segment from 308000 to 30BFFF, but
>> > >> >>the
>> > >> >>linker
>> > >> >>complains that it is not allowed to allocate to this address in
>> > >> >>small
>> > >> >>memory
>> > >> >>model mode. It does not complain if I set the segment from 8000 to
>> > >> >>BFFF,
>> > >> >>but
>> > >> >>I have no idea which page it will stick the code into (if any) to
>> > >> >>correctly
>> > >> >>initialise the PPAGE register.
>> > >> >>
>> > >> >>If someone can advise if what I want to do is possible, and if so
>> > >> >>the
>> > >> >>best
>> > >> >>way to achieve it, that would be appreciated.
>> > >> >>
>> > >> >>Cheers,
>> > >> >>
>> > >> >>Adrian
>> > >> >>
>> > >> >>Send instant messages to your online friends
>> > >> >>http://au.messenger.yahoo.com
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >>Yahoo! Groups Links
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> > Yahoo! Groups Links
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >>
>> > >>Send instant messages to your online friends
>> http://au.messenger.yahoo.com
>> > >>
>> > >>
>> > >>
>> > >>Yahoo! Groups Links
>> > >>
>> > >>
>> > >>
>> > >>
>> > >
>> > >
>> > >
>> > >
>> > > Yahoo! Groups Links
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> >Send instant messages to your online friends
>> >http://au.messenger.yahoo.com
>> >
>> >
>> >
>> >Yahoo! Groups Links
>> >
>> >
>> >
>> >
>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
> >
>
> Yahoo! Groups Links >
>
Send instant messages to your online friends http://au.messenger.yahoo.com
-- Adrian
----- Original Message -----
From: "Gilles Blanquin" <gilles.blanquin@gill...>
To: <68HC12@68HC...>
Sent: Tuesday, July 19, 2005 7:09 PM
Subject: Re: [68HC12] Metrowerks small memory model banked memory >
> Hi again, Adrian.
>
> I just posted a new driver compliant with CW12V2.x
>
> ftp://ftp3.metrowerks.com/pub/dropzone/Mcu03c6_fpp_flat8000_p30_proto_19Jul0
> 5.zip
>
> Just for info: The CW12V31 drivers program only words and the debugger
> asserts byte patterning for uncompleted words. In CW12V2.x, this is done
> by
> the driver itself, allowing byte programming. We had to eliminate word
> rewriting in some cases.
>
> Adrian, if this still does not work, you can send me your project or an
> example project showing this problem.
>
> You can also try the following mapping defining one single block of flash.
>
> Regards,
> Gilles > DEFAULT_RAM INTO READ_WRITE 0x1000 TO 0x3FFF;
>
> DEFAULT_ROM,_PRESTART, STARTUP,
> ROM_VAR, STRINGS,
> NON_BANKED, COPY INTO READ_ONLY 0x4000 TO 0xFEFF; >
> At 10:04 AM 7/19/2005, Gilles Blanquin wrote:
>>Hi Adrian.
>>
>>I am going to check the driver.
>>Indeed, the driver is design for CW12 V3.1 release, where the debugger
>>asserts WORD programming of the memory instead of Byte programming.
>>This is a flash strict restriction.
>>The new module I added is programming only word aligned code, but this
>>restriction does not exist in CW12 V2.0. While testing, I could not detect
>>that.
>>Let me regenerate the driver. I post it asap.
>>
>>Regards,
>>Gilles
>>
>>
>>
>>
>>
>>At 09:39 AM 7/19/2005, you wrote:
>> >Thanks Giles and all for your help.
>> >
>> >I loaded the driver from giles and it does seem to work, however I am
>> >having
>> >the strangest problem I encountered yet on the HCS12, and I am unaware
>> >of
>> >how to fix it.
>> >
>> >Basically I have 3 flash memories setup in the PRM file, and I load my
>> >main
>> >code first into the 4000-8000 range, and then the 8000-C000 range, and
>> >finally the C000-F000 range in link order. The code seemed the load in
>> >correctly using the new driver, and I have set the PPAGE register to 30
>> >in
>> >my startup code. However it would crash and not run.... so after a lot
>> >of
>> >stuffing around, I reduced the size of the 8000-C000 page to 8000-ADC1
>> >and
>> >it works correctly. I tracked it down to the linker placing one function
>> >in
>> >the middle page or the final. Anyway, I wanted to use the whole space,
>> >and
>> >unexplained issues like this annoy me, so I have been trying to work out
>> >why. I currently have the project setup so that on the last function
>> >before
>> >the end of the middle page, if I add a NOP in, it crashes, but if I
>> >remove
>> >it, it runs fine. All other functions remain unchanged and linked in the
>> >same position since this function I am working on is the last that fits
>> >into
>> >that page.
>> >
>> >I thought that maybe there was something about the address at the end of
>> >the
>> >function, so I left the NOP out, altered the Segments and used a VECTOR
>> >instruction in the PRM file to set that extra byte filled out by the NOP
>> >with the same data as when the NOP is in place... it works fine... no
>> >crash.... but if I add the NOP back in and remove the vector, it crashed
>> >again. There is literally 4 bytes different in the binary file output
>> >from
>> >the linker between the working and crashing files. The 4 bytes equate to
>> >the
>> >NOP, stack clean up and the RTS instruction for the function.
>> >
>> >It is crasy, but no matter what I do, it repeatably crashes (must jump
>> >out
>> >of my code) if I have the NOP, and repeatably works without it.
>> >
>> >The only conclusions I can come to are that the flash loader is doing
>> >something funny with my files at that address, or the S12 has some funny
>> >to
>> >do with trying to run code of out the paged memory in non banked small
>> >memory model code... but modt of the code works that resides in this
>> >area...
>> >just not at the later addresses. It is very frustrating, and I am happy
>> >for
>> >any debugging ideas... Unfortunately I cannot step my code at normal
>> >speed
>> >with the BDN I have, and in slow speed, I get strange operation... it
>> >will
>> >step the code as long as I do not step over a function, otehrwise it
>> >loses
>> >control of it.
>> >
>> >ANyway, as you can see, I am quite perplexed. Any advice appreciated.
>> >
>> >Gilles is it possible that driver is doing something unexpected?
>> >
>> >Cheers,
>> >
>> >Adrian
>> >
>> >----- Original Message -----
>> >From: "Gilles Blanquin" <gilles.blanquin@gill...>
>> >To: <68HC12@68HC...>
>> >Sent: Monday, July 18, 2005 5:32 PM
>> >Subject: Re: [68HC12] Metrowerks small memory model banked memory
>> >
>> >
>> > > Hi Adrian.
>> > >
>> > > Please find here the prototype driver I just tested.
>> > >
>> > > To be installed in "prog\fpp" folder of your CodeWarrior (backup the
>> > > previous file).
>> > >
>> > >
>> >
>> ftp://ftp3.metrowerks.com/pub/dropzone/Mcu03c6.fpp-flat8000_p30-proto-18-Jul
>> > > -05.zip
>> > >
>> > > Note that the chip has by default/reset the ppage $00 is set, which
>> > > is a
>> > > mirror of ppage $30 !
>> > >
>> > > The driver flashes the ppage $30.
>> > >
>> > > I just flashed the chip with a test srecord from $4000 to $ffff. You
>> > > can
>> > > then scroll the memory and see all the code flashed linearly.
>> > >
>> > > To my opinion, you don't even need to preset the ppage anywhere.
>> > >
>> > > Please try my prm setup, try to flash and give me your feedback.
>> > > Note that erasing is disabled in FLAT8000_P30. You can still erase
>> > > via
>> > > FLASH_3 module.
>> > >
>> > > Regards,
>> > > Gilles
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > At 09:04 AM 7/18/2005, you wrote:
>> > >>Hi Gilles,
>> > >>
>> > >>That is almost exactly what I am after. I was planning on seperating
>> > >>the
>> > >>linear space from 4000 to FFFF into 3 subsections:
>> > >>
>> > >>* 4000-7FFF
>> > >>* 8000-BFFF
>> > >>* C000-FEFF
>> > >>
>> > >>The reason for this is that I still wanted to be able to place
>> > >>startup
>> > >>code
>> > >>into a known fixed page (4000-7FFF or C000-FEFF), as the area
>> > >>8000-BFFF
>> > >>would not be available until initialisation code had initialised
>> > >>PPAGE to
>> > >>30.
>> > >>
>> > >>If I make it one continuous space, then the startup code may end up
>> in the
>> > >>paged section, which would be invalid before PPAGE was set (Can't
>> have the
>> > >>reset vector pointing to the range 8000-BFFF)
>> > >>
>> > >>The thing I am lacking at the moment is a method to tell the linker
>> > >>and
>> > >>true
>> > >>time simulator to allocate the code space in the 8000-BFFF range to
>> > >>the
>> > >>first page 30800 to 30BFFF (In the case of linking it should treat
>> > >>this
>> > >>range as 8000-BFFF, but the flash programmer should write it to
>> > >>308000 to
>> > >>30BFFF). If I can get this sorted, I believe it will all fall out
>> > >>nicely.
>> > >>I
>> > >>believe the driver changes you propose would solve my problem. The
>> > >>processor
>> > >>I am using is the DP256.
>> > >>
>> > >>Interestingly I get some other funny errors when I try to set this
>> > >>up.
>> > >>When
>> > >>I add the segment 8000-BFFF, and then allocate data to it in the
>> placement
>> > >>section, for some reason I get an L1903 "Unexpected symbol" error on
>> > >>linking
>> > >>pointing at one of my vector lines at the bottom of the PRM files.
>> > >>Seems
>> > >>to
>> > >>me be some sort of bug in parsing the PRM file. Not sure if your
>> > >>proposed
>> > >>changes will fix this linking issue or not. Let me know if you want
>> my PRM
>> > >>file.
>> > >>
>> > >>You are correct that the small memory model does not support banked
>> > >>mode.
>> > >>I
>> > >>do not wish to use banked mode as it has other limitations... I just
>> > >>want
>> > >>to
>> > >>use all the available ROM for small memory model non-banked mode.
>> > >>Unfortunately I can only get to 32k of the available 48k on the
>> memory map
>> > >>currently.
>> > >>
>> > >>Thanks,
>> > >>
>> > >>Adrian
>> > >>
>> > >>
>> > >>
>> > >>----- Original Message -----
>> > >>From: "Gilles Blanquin" <gilles.blanquin@gill...>
>> > >>To: <68HC12@68HC...>
>> > >>Sent: Monday, July 18, 2005 4:42 PM
>> > >>Subject: Re: [68HC12] Metrowerks small memory model banked memory
>> > >>
>> > >>
>> > >> > Hi Adrian.
>> > >> >
>> > >> > I guess, from your previous email, that you use a DP256. Indeed,
>> > >> > it
>> > >> > would
>> > >> > be possible to program the flash in a linear way from $4000 to
>> > >> > $FFFF,
>> > >> > saying that for DP256, the reset PPAGE is $30.
>> > >> > The Flash Programmer does not handle the default (reset) page
>> > >> > programming
>> > >> > in $8000-BFFF, so I would have to provide you this driver upgrade
>> which
>> > >> > will be available in next CodeWarrior release.
>> > >> >
>> > >> > I presume you would like to have a similar (small / non banked)
>> > >> > prm
>> > >> > mapping:
>> > >> >
>> > >> > DEFAULT_RAM INTO READ_WRITE 0x1000 TO 0x3FFF;
>> > >> >
>> > >> > DEFAULT_ROM,_PRESTART, STARTUP,
>> > >> > ROM_VAR, STRINGS,
>> > >> > NON_BANKED, COPY INTO READ_ONLY 0x4000 TO 0xFEFF;
>> > >> >
>> > >> > Please confirm this and the derivative used and I will make a
>> > >> > CW12V2.x
>> > >> > flash driver programming addresses $8000-bfff remapped to logical
>> > >> > $308000-30bfff.
>> > >> >
>> > >> > Regards,
>> > >> > Gilles
>> > >> >
>> > >> > P.S. As far as I remember, the small memory model is not
>> > >> > compatible
>> > >> > with
>> > >> > banked model.
>> > >> >
>> > >> >
>> > >> >
>> > >> > At 07:38 AM 7/18/2005, Adrian Vos wrote:
>> > >> >>Hi All,
>> > >> >>
>> > >> >>I am using Metrowerks for HCS12 v2.0. In the small memory model it
>> > >> >>is
>> > >> >>easy
>> > >> >>to get access to the 2 16k fixed flash pages, but I am running out
>> > >> >>of
>> > >> >>code
>> > >> >>space as I quickly approach 32k code size. I was hoping to write
>> > >> >>into
>> > >> >>my
>> > >> >>start code some code to fix the PPAGE register at a particular
>> > >> >>page
>> > >> >>(not
>> > >> >>3E
>> > >> >>of 3F which are the fixed pages), and then utilise the banked
>> > >> >>memory
>> > >> >>range
>> > >> >>to extend to 48k of usable ROM whilst still using the small memory
>> > >> >>model.
>> > >> >>I
>> > >> >>am not sure how to do this with the PRM file, and I was hoping
>> > >> >>someone
>> > >> >>could
>> > >> >>tell me. I try setting a new segment from 308000 to 30BFFF, but
>> > >> >>the
>> > >> >>linker
>> > >> >>complains that it is not allowed to allocate to this address in
>> > >> >>small
>> > >> >>memory
>> > >> >>model mode. It does not complain if I set the segment from 8000 to
>> > >> >>BFFF,
>> > >> >>but
>> > >> >>I have no idea which page it will stick the code into (if any) to
>> > >> >>correctly
>> > >> >>initialise the PPAGE register.
>> > >> >>
>> > >> >>If someone can advise if what I want to do is possible, and if so
>> > >> >>the
>> > >> >>best
>> > >> >>way to achieve it, that would be appreciated.
>> > >> >>
>> > >> >>Cheers,
>> > >> >>
>> > >> >>Adrian
>> > >> >>
>> > >> >>Send instant messages to your online friends
>> > >> >>http://au.messenger.yahoo.com
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >>Yahoo! Groups Links
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> > Yahoo! Groups Links
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >>
>> > >>Send instant messages to your online friends
>> http://au.messenger.yahoo.com
>> > >>
>> > >>
>> > >>
>> > >>Yahoo! Groups Links
>> > >>
>> > >>
>> > >>
>> > >>
>> > >
>> > >
>> > >
>> > >
>> > > Yahoo! Groups Links
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> >Send instant messages to your online friends
>> >http://au.messenger.yahoo.com
>> >
>> >
>> >
>> >Yahoo! Groups Links
>> >
>> >
>> >
>> >
>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
> >
>
> Yahoo! Groups Links >
>
Send instant messages to your online friends http://au.messenger.yahoo.com
Reply by ●July 20, 20052005-07-20
Gilles,
As stated previously, your driver fix soughted the problem I was having, and
there has been no further problems, and it all works great. The only thing I
have noticed now is that by selecting to map the area 8000 to BFFF to PPAGE
30, I have a minor issue in that this PPAGE is in a different Flash block to
the fixed pages. Pages 3C,3D,3E and 3F are all flash block 0, and the fixed
pages are 3E and 3F. I have a bootloader in this application, and the code
was written previously on the assumption that all code was in flash block 0.
I can modify this code to treat the area 8000-BFFF as a different falsh
block, but this complicates things quite a bit. I would prefer to do things
in one loop for the whole memory space. I would be able to do this if the
area 8000-BFFF was mapped to an area in flash block 0.
Would it be possible for you to regenerate this driver exactly as before in
terms of v2.0 byte addressing capability, but with the area 8000-BFFF mapped
to page 3D or 3C to put it in the same flash block as the fixed pages.
So map 8000-BFFF to 3D8000-3DBFFF
Thanks,
Adrian
----- Original Message -----
From: "Gilles Blanquin" <gilles.blanquin@gill...>
To: <68HC12@68HC...>
Sent: Tuesday, July 19, 2005 7:09 PM
Subject: Re: [68HC12] Metrowerks small memory model banked memory >
> Hi again, Adrian.
>
> I just posted a new driver compliant with CW12V2.x
>
> ftp://ftp3.metrowerks.com/pub/dropzone/Mcu03c6_fpp_flat8000_p30_proto_19Jul0
> 5.zip
>
> Just for info: The CW12V31 drivers program only words and the debugger
> asserts byte patterning for uncompleted words. In CW12V2.x, this is done
> by
> the driver itself, allowing byte programming. We had to eliminate word
> rewriting in some cases.
>
> Adrian, if this still does not work, you can send me your project or an
> example project showing this problem.
>
> You can also try the following mapping defining one single block of flash.
>
> Regards,
> Gilles > DEFAULT_RAM INTO READ_WRITE 0x1000 TO 0x3FFF;
>
> DEFAULT_ROM,_PRESTART, STARTUP,
> ROM_VAR, STRINGS,
> NON_BANKED, COPY INTO READ_ONLY 0x4000 TO 0xFEFF; >
> At 10:04 AM 7/19/2005, Gilles Blanquin wrote:
>>Hi Adrian.
>>
>>I am going to check the driver.
>>Indeed, the driver is design for CW12 V3.1 release, where the debugger
>>asserts WORD programming of the memory instead of Byte programming.
>>This is a flash strict restriction.
>>The new module I added is programming only word aligned code, but this
>>restriction does not exist in CW12 V2.0. While testing, I could not detect
>>that.
>>Let me regenerate the driver. I post it asap.
>>
>>Regards,
>>Gilles
>>
>>
>>
>>
>>
>>At 09:39 AM 7/19/2005, you wrote:
>> >Thanks Giles and all for your help.
>> >
>> >I loaded the driver from giles and it does seem to work, however I am
>> >having
>> >the strangest problem I encountered yet on the HCS12, and I am unaware
>> >of
>> >how to fix it.
>> >
>> >Basically I have 3 flash memories setup in the PRM file, and I load my
>> >main
>> >code first into the 4000-8000 range, and then the 8000-C000 range, and
>> >finally the C000-F000 range in link order. The code seemed the load in
>> >correctly using the new driver, and I have set the PPAGE register to 30
>> >in
>> >my startup code. However it would crash and not run.... so after a lot
>> >of
>> >stuffing around, I reduced the size of the 8000-C000 page to 8000-ADC1
>> >and
>> >it works correctly. I tracked it down to the linker placing one function
>> >in
>> >the middle page or the final. Anyway, I wanted to use the whole space,
>> >and
>> >unexplained issues like this annoy me, so I have been trying to work out
>> >why. I currently have the project setup so that on the last function
>> >before
>> >the end of the middle page, if I add a NOP in, it crashes, but if I
>> >remove
>> >it, it runs fine. All other functions remain unchanged and linked in the
>> >same position since this function I am working on is the last that fits
>> >into
>> >that page.
>> >
>> >I thought that maybe there was something about the address at the end of
>> >the
>> >function, so I left the NOP out, altered the Segments and used a VECTOR
>> >instruction in the PRM file to set that extra byte filled out by the NOP
>> >with the same data as when the NOP is in place... it works fine... no
>> >crash.... but if I add the NOP back in and remove the vector, it crashed
>> >again. There is literally 4 bytes different in the binary file output
>> >from
>> >the linker between the working and crashing files. The 4 bytes equate to
>> >the
>> >NOP, stack clean up and the RTS instruction for the function.
>> >
>> >It is crasy, but no matter what I do, it repeatably crashes (must jump
>> >out
>> >of my code) if I have the NOP, and repeatably works without it.
>> >
>> >The only conclusions I can come to are that the flash loader is doing
>> >something funny with my files at that address, or the S12 has some funny
>> >to
>> >do with trying to run code of out the paged memory in non banked small
>> >memory model code... but modt of the code works that resides in this
>> >area...
>> >just not at the later addresses. It is very frustrating, and I am happy
>> >for
>> >any debugging ideas... Unfortunately I cannot step my code at normal
>> >speed
>> >with the BDN I have, and in slow speed, I get strange operation... it
>> >will
>> >step the code as long as I do not step over a function, otehrwise it
>> >loses
>> >control of it.
>> >
>> >ANyway, as you can see, I am quite perplexed. Any advice appreciated.
>> >
>> >Gilles is it possible that driver is doing something unexpected?
>> >
>> >Cheers,
>> >
>> >Adrian
>> >
>> >----- Original Message -----
>> >From: "Gilles Blanquin" <gilles.blanquin@gill...>
>> >To: <68HC12@68HC...>
>> >Sent: Monday, July 18, 2005 5:32 PM
>> >Subject: Re: [68HC12] Metrowerks small memory model banked memory
>> >
>> >
>> > > Hi Adrian.
>> > >
>> > > Please find here the prototype driver I just tested.
>> > >
>> > > To be installed in "prog\fpp" folder of your CodeWarrior (backup the
>> > > previous file).
>> > >
>> > >
>> >
>> ftp://ftp3.metrowerks.com/pub/dropzone/Mcu03c6.fpp-flat8000_p30-proto-18-Jul
>> > > -05.zip
>> > >
>> > > Note that the chip has by default/reset the ppage $00 is set, which
>> > > is a
>> > > mirror of ppage $30 !
>> > >
>> > > The driver flashes the ppage $30.
>> > >
>> > > I just flashed the chip with a test srecord from $4000 to $ffff. You
>> > > can
>> > > then scroll the memory and see all the code flashed linearly.
>> > >
>> > > To my opinion, you don't even need to preset the ppage anywhere.
>> > >
>> > > Please try my prm setup, try to flash and give me your feedback.
>> > > Note that erasing is disabled in FLAT8000_P30. You can still erase
>> > > via
>> > > FLASH_3 module.
>> > >
>> > > Regards,
>> > > Gilles
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > At 09:04 AM 7/18/2005, you wrote:
>> > >>Hi Gilles,
>> > >>
>> > >>That is almost exactly what I am after. I was planning on seperating
>> > >>the
>> > >>linear space from 4000 to FFFF into 3 subsections:
>> > >>
>> > >>* 4000-7FFF
>> > >>* 8000-BFFF
>> > >>* C000-FEFF
>> > >>
>> > >>The reason for this is that I still wanted to be able to place
>> > >>startup
>> > >>code
>> > >>into a known fixed page (4000-7FFF or C000-FEFF), as the area
>> > >>8000-BFFF
>> > >>would not be available until initialisation code had initialised
>> > >>PPAGE to
>> > >>30.
>> > >>
>> > >>If I make it one continuous space, then the startup code may end up
>> in the
>> > >>paged section, which would be invalid before PPAGE was set (Can't
>> have the
>> > >>reset vector pointing to the range 8000-BFFF)
>> > >>
>> > >>The thing I am lacking at the moment is a method to tell the linker
>> > >>and
>> > >>true
>> > >>time simulator to allocate the code space in the 8000-BFFF range to
>> > >>the
>> > >>first page 30800 to 30BFFF (In the case of linking it should treat
>> > >>this
>> > >>range as 8000-BFFF, but the flash programmer should write it to
>> > >>308000 to
>> > >>30BFFF). If I can get this sorted, I believe it will all fall out
>> > >>nicely.
>> > >>I
>> > >>believe the driver changes you propose would solve my problem. The
>> > >>processor
>> > >>I am using is the DP256.
>> > >>
>> > >>Interestingly I get some other funny errors when I try to set this
>> > >>up.
>> > >>When
>> > >>I add the segment 8000-BFFF, and then allocate data to it in the
>> placement
>> > >>section, for some reason I get an L1903 "Unexpected symbol" error on
>> > >>linking
>> > >>pointing at one of my vector lines at the bottom of the PRM files.
>> > >>Seems
>> > >>to
>> > >>me be some sort of bug in parsing the PRM file. Not sure if your
>> > >>proposed
>> > >>changes will fix this linking issue or not. Let me know if you want
>> my PRM
>> > >>file.
>> > >>
>> > >>You are correct that the small memory model does not support banked
>> > >>mode.
>> > >>I
>> > >>do not wish to use banked mode as it has other limitations... I just
>> > >>want
>> > >>to
>> > >>use all the available ROM for small memory model non-banked mode.
>> > >>Unfortunately I can only get to 32k of the available 48k on the
>> memory map
>> > >>currently.
>> > >>
>> > >>Thanks,
>> > >>
>> > >>Adrian
>> > >>
>> > >>
>> > >>
>> > >>----- Original Message -----
>> > >>From: "Gilles Blanquin" <gilles.blanquin@gill...>
>> > >>To: <68HC12@68HC...>
>> > >>Sent: Monday, July 18, 2005 4:42 PM
>> > >>Subject: Re: [68HC12] Metrowerks small memory model banked memory
>> > >>
>> > >>
>> > >> > Hi Adrian.
>> > >> >
>> > >> > I guess, from your previous email, that you use a DP256. Indeed,
>> > >> > it
>> > >> > would
>> > >> > be possible to program the flash in a linear way from $4000 to
>> > >> > $FFFF,
>> > >> > saying that for DP256, the reset PPAGE is $30.
>> > >> > The Flash Programmer does not handle the default (reset) page
>> > >> > programming
>> > >> > in $8000-BFFF, so I would have to provide you this driver upgrade
>> which
>> > >> > will be available in next CodeWarrior release.
>> > >> >
>> > >> > I presume you would like to have a similar (small / non banked)
>> > >> > prm
>> > >> > mapping:
>> > >> >
>> > >> > DEFAULT_RAM INTO READ_WRITE 0x1000 TO 0x3FFF;
>> > >> >
>> > >> > DEFAULT_ROM,_PRESTART, STARTUP,
>> > >> > ROM_VAR, STRINGS,
>> > >> > NON_BANKED, COPY INTO READ_ONLY 0x4000 TO 0xFEFF;
>> > >> >
>> > >> > Please confirm this and the derivative used and I will make a
>> > >> > CW12V2.x
>> > >> > flash driver programming addresses $8000-bfff remapped to logical
>> > >> > $308000-30bfff.
>> > >> >
>> > >> > Regards,
>> > >> > Gilles
>> > >> >
>> > >> > P.S. As far as I remember, the small memory model is not
>> > >> > compatible
>> > >> > with
>> > >> > banked model.
>> > >> >
>> > >> >
>> > >> >
>> > >> > At 07:38 AM 7/18/2005, Adrian Vos wrote:
>> > >> >>Hi All,
>> > >> >>
>> > >> >>I am using Metrowerks for HCS12 v2.0. In the small memory model it
>> > >> >>is
>> > >> >>easy
>> > >> >>to get access to the 2 16k fixed flash pages, but I am running out
>> > >> >>of
>> > >> >>code
>> > >> >>space as I quickly approach 32k code size. I was hoping to write
>> > >> >>into
>> > >> >>my
>> > >> >>start code some code to fix the PPAGE register at a particular
>> > >> >>page
>> > >> >>(not
>> > >> >>3E
>> > >> >>of 3F which are the fixed pages), and then utilise the banked
>> > >> >>memory
>> > >> >>range
>> > >> >>to extend to 48k of usable ROM whilst still using the small memory
>> > >> >>model.
>> > >> >>I
>> > >> >>am not sure how to do this with the PRM file, and I was hoping
>> > >> >>someone
>> > >> >>could
>> > >> >>tell me. I try setting a new segment from 308000 to 30BFFF, but
>> > >> >>the
>> > >> >>linker
>> > >> >>complains that it is not allowed to allocate to this address in
>> > >> >>small
>> > >> >>memory
>> > >> >>model mode. It does not complain if I set the segment from 8000 to
>> > >> >>BFFF,
>> > >> >>but
>> > >> >>I have no idea which page it will stick the code into (if any) to
>> > >> >>correctly
>> > >> >>initialise the PPAGE register.
>> > >> >>
>> > >> >>If someone can advise if what I want to do is possible, and if so
>> > >> >>the
>> > >> >>best
>> > >> >>way to achieve it, that would be appreciated.
>> > >> >>
>> > >> >>Cheers,
>> > >> >>
>> > >> >>Adrian
>> > >> >>
>> > >> >>Send instant messages to your online friends
>> > >> >>http://au.messenger.yahoo.com
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >>Yahoo! Groups Links
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> > Yahoo! Groups Links
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >>
>> > >>Send instant messages to your online friends
>> http://au.messenger.yahoo.com
>> > >>
>> > >>
>> > >>
>> > >>Yahoo! Groups Links
>> > >>
>> > >>
>> > >>
>> > >>
>> > >
>> > >
>> > >
>> > >
>> > > Yahoo! Groups Links
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> >Send instant messages to your online friends
>> >http://au.messenger.yahoo.com
>> >
>> >
>> >
>> >Yahoo! Groups Links
>> >
>> >
>> >
>> >
>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
> >
>
> Yahoo! Groups Links >
>
Send instant messages to your online friends http://au.messenger.yahoo.com
As stated previously, your driver fix soughted the problem I was having, and
there has been no further problems, and it all works great. The only thing I
have noticed now is that by selecting to map the area 8000 to BFFF to PPAGE
30, I have a minor issue in that this PPAGE is in a different Flash block to
the fixed pages. Pages 3C,3D,3E and 3F are all flash block 0, and the fixed
pages are 3E and 3F. I have a bootloader in this application, and the code
was written previously on the assumption that all code was in flash block 0.
I can modify this code to treat the area 8000-BFFF as a different falsh
block, but this complicates things quite a bit. I would prefer to do things
in one loop for the whole memory space. I would be able to do this if the
area 8000-BFFF was mapped to an area in flash block 0.
Would it be possible for you to regenerate this driver exactly as before in
terms of v2.0 byte addressing capability, but with the area 8000-BFFF mapped
to page 3D or 3C to put it in the same flash block as the fixed pages.
So map 8000-BFFF to 3D8000-3DBFFF
Thanks,
Adrian
----- Original Message -----
From: "Gilles Blanquin" <gilles.blanquin@gill...>
To: <68HC12@68HC...>
Sent: Tuesday, July 19, 2005 7:09 PM
Subject: Re: [68HC12] Metrowerks small memory model banked memory >
> Hi again, Adrian.
>
> I just posted a new driver compliant with CW12V2.x
>
> ftp://ftp3.metrowerks.com/pub/dropzone/Mcu03c6_fpp_flat8000_p30_proto_19Jul0
> 5.zip
>
> Just for info: The CW12V31 drivers program only words and the debugger
> asserts byte patterning for uncompleted words. In CW12V2.x, this is done
> by
> the driver itself, allowing byte programming. We had to eliminate word
> rewriting in some cases.
>
> Adrian, if this still does not work, you can send me your project or an
> example project showing this problem.
>
> You can also try the following mapping defining one single block of flash.
>
> Regards,
> Gilles > DEFAULT_RAM INTO READ_WRITE 0x1000 TO 0x3FFF;
>
> DEFAULT_ROM,_PRESTART, STARTUP,
> ROM_VAR, STRINGS,
> NON_BANKED, COPY INTO READ_ONLY 0x4000 TO 0xFEFF; >
> At 10:04 AM 7/19/2005, Gilles Blanquin wrote:
>>Hi Adrian.
>>
>>I am going to check the driver.
>>Indeed, the driver is design for CW12 V3.1 release, where the debugger
>>asserts WORD programming of the memory instead of Byte programming.
>>This is a flash strict restriction.
>>The new module I added is programming only word aligned code, but this
>>restriction does not exist in CW12 V2.0. While testing, I could not detect
>>that.
>>Let me regenerate the driver. I post it asap.
>>
>>Regards,
>>Gilles
>>
>>
>>
>>
>>
>>At 09:39 AM 7/19/2005, you wrote:
>> >Thanks Giles and all for your help.
>> >
>> >I loaded the driver from giles and it does seem to work, however I am
>> >having
>> >the strangest problem I encountered yet on the HCS12, and I am unaware
>> >of
>> >how to fix it.
>> >
>> >Basically I have 3 flash memories setup in the PRM file, and I load my
>> >main
>> >code first into the 4000-8000 range, and then the 8000-C000 range, and
>> >finally the C000-F000 range in link order. The code seemed the load in
>> >correctly using the new driver, and I have set the PPAGE register to 30
>> >in
>> >my startup code. However it would crash and not run.... so after a lot
>> >of
>> >stuffing around, I reduced the size of the 8000-C000 page to 8000-ADC1
>> >and
>> >it works correctly. I tracked it down to the linker placing one function
>> >in
>> >the middle page or the final. Anyway, I wanted to use the whole space,
>> >and
>> >unexplained issues like this annoy me, so I have been trying to work out
>> >why. I currently have the project setup so that on the last function
>> >before
>> >the end of the middle page, if I add a NOP in, it crashes, but if I
>> >remove
>> >it, it runs fine. All other functions remain unchanged and linked in the
>> >same position since this function I am working on is the last that fits
>> >into
>> >that page.
>> >
>> >I thought that maybe there was something about the address at the end of
>> >the
>> >function, so I left the NOP out, altered the Segments and used a VECTOR
>> >instruction in the PRM file to set that extra byte filled out by the NOP
>> >with the same data as when the NOP is in place... it works fine... no
>> >crash.... but if I add the NOP back in and remove the vector, it crashed
>> >again. There is literally 4 bytes different in the binary file output
>> >from
>> >the linker between the working and crashing files. The 4 bytes equate to
>> >the
>> >NOP, stack clean up and the RTS instruction for the function.
>> >
>> >It is crasy, but no matter what I do, it repeatably crashes (must jump
>> >out
>> >of my code) if I have the NOP, and repeatably works without it.
>> >
>> >The only conclusions I can come to are that the flash loader is doing
>> >something funny with my files at that address, or the S12 has some funny
>> >to
>> >do with trying to run code of out the paged memory in non banked small
>> >memory model code... but modt of the code works that resides in this
>> >area...
>> >just not at the later addresses. It is very frustrating, and I am happy
>> >for
>> >any debugging ideas... Unfortunately I cannot step my code at normal
>> >speed
>> >with the BDN I have, and in slow speed, I get strange operation... it
>> >will
>> >step the code as long as I do not step over a function, otehrwise it
>> >loses
>> >control of it.
>> >
>> >ANyway, as you can see, I am quite perplexed. Any advice appreciated.
>> >
>> >Gilles is it possible that driver is doing something unexpected?
>> >
>> >Cheers,
>> >
>> >Adrian
>> >
>> >----- Original Message -----
>> >From: "Gilles Blanquin" <gilles.blanquin@gill...>
>> >To: <68HC12@68HC...>
>> >Sent: Monday, July 18, 2005 5:32 PM
>> >Subject: Re: [68HC12] Metrowerks small memory model banked memory
>> >
>> >
>> > > Hi Adrian.
>> > >
>> > > Please find here the prototype driver I just tested.
>> > >
>> > > To be installed in "prog\fpp" folder of your CodeWarrior (backup the
>> > > previous file).
>> > >
>> > >
>> >
>> ftp://ftp3.metrowerks.com/pub/dropzone/Mcu03c6.fpp-flat8000_p30-proto-18-Jul
>> > > -05.zip
>> > >
>> > > Note that the chip has by default/reset the ppage $00 is set, which
>> > > is a
>> > > mirror of ppage $30 !
>> > >
>> > > The driver flashes the ppage $30.
>> > >
>> > > I just flashed the chip with a test srecord from $4000 to $ffff. You
>> > > can
>> > > then scroll the memory and see all the code flashed linearly.
>> > >
>> > > To my opinion, you don't even need to preset the ppage anywhere.
>> > >
>> > > Please try my prm setup, try to flash and give me your feedback.
>> > > Note that erasing is disabled in FLAT8000_P30. You can still erase
>> > > via
>> > > FLASH_3 module.
>> > >
>> > > Regards,
>> > > Gilles
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > At 09:04 AM 7/18/2005, you wrote:
>> > >>Hi Gilles,
>> > >>
>> > >>That is almost exactly what I am after. I was planning on seperating
>> > >>the
>> > >>linear space from 4000 to FFFF into 3 subsections:
>> > >>
>> > >>* 4000-7FFF
>> > >>* 8000-BFFF
>> > >>* C000-FEFF
>> > >>
>> > >>The reason for this is that I still wanted to be able to place
>> > >>startup
>> > >>code
>> > >>into a known fixed page (4000-7FFF or C000-FEFF), as the area
>> > >>8000-BFFF
>> > >>would not be available until initialisation code had initialised
>> > >>PPAGE to
>> > >>30.
>> > >>
>> > >>If I make it one continuous space, then the startup code may end up
>> in the
>> > >>paged section, which would be invalid before PPAGE was set (Can't
>> have the
>> > >>reset vector pointing to the range 8000-BFFF)
>> > >>
>> > >>The thing I am lacking at the moment is a method to tell the linker
>> > >>and
>> > >>true
>> > >>time simulator to allocate the code space in the 8000-BFFF range to
>> > >>the
>> > >>first page 30800 to 30BFFF (In the case of linking it should treat
>> > >>this
>> > >>range as 8000-BFFF, but the flash programmer should write it to
>> > >>308000 to
>> > >>30BFFF). If I can get this sorted, I believe it will all fall out
>> > >>nicely.
>> > >>I
>> > >>believe the driver changes you propose would solve my problem. The
>> > >>processor
>> > >>I am using is the DP256.
>> > >>
>> > >>Interestingly I get some other funny errors when I try to set this
>> > >>up.
>> > >>When
>> > >>I add the segment 8000-BFFF, and then allocate data to it in the
>> placement
>> > >>section, for some reason I get an L1903 "Unexpected symbol" error on
>> > >>linking
>> > >>pointing at one of my vector lines at the bottom of the PRM files.
>> > >>Seems
>> > >>to
>> > >>me be some sort of bug in parsing the PRM file. Not sure if your
>> > >>proposed
>> > >>changes will fix this linking issue or not. Let me know if you want
>> my PRM
>> > >>file.
>> > >>
>> > >>You are correct that the small memory model does not support banked
>> > >>mode.
>> > >>I
>> > >>do not wish to use banked mode as it has other limitations... I just
>> > >>want
>> > >>to
>> > >>use all the available ROM for small memory model non-banked mode.
>> > >>Unfortunately I can only get to 32k of the available 48k on the
>> memory map
>> > >>currently.
>> > >>
>> > >>Thanks,
>> > >>
>> > >>Adrian
>> > >>
>> > >>
>> > >>
>> > >>----- Original Message -----
>> > >>From: "Gilles Blanquin" <gilles.blanquin@gill...>
>> > >>To: <68HC12@68HC...>
>> > >>Sent: Monday, July 18, 2005 4:42 PM
>> > >>Subject: Re: [68HC12] Metrowerks small memory model banked memory
>> > >>
>> > >>
>> > >> > Hi Adrian.
>> > >> >
>> > >> > I guess, from your previous email, that you use a DP256. Indeed,
>> > >> > it
>> > >> > would
>> > >> > be possible to program the flash in a linear way from $4000 to
>> > >> > $FFFF,
>> > >> > saying that for DP256, the reset PPAGE is $30.
>> > >> > The Flash Programmer does not handle the default (reset) page
>> > >> > programming
>> > >> > in $8000-BFFF, so I would have to provide you this driver upgrade
>> which
>> > >> > will be available in next CodeWarrior release.
>> > >> >
>> > >> > I presume you would like to have a similar (small / non banked)
>> > >> > prm
>> > >> > mapping:
>> > >> >
>> > >> > DEFAULT_RAM INTO READ_WRITE 0x1000 TO 0x3FFF;
>> > >> >
>> > >> > DEFAULT_ROM,_PRESTART, STARTUP,
>> > >> > ROM_VAR, STRINGS,
>> > >> > NON_BANKED, COPY INTO READ_ONLY 0x4000 TO 0xFEFF;
>> > >> >
>> > >> > Please confirm this and the derivative used and I will make a
>> > >> > CW12V2.x
>> > >> > flash driver programming addresses $8000-bfff remapped to logical
>> > >> > $308000-30bfff.
>> > >> >
>> > >> > Regards,
>> > >> > Gilles
>> > >> >
>> > >> > P.S. As far as I remember, the small memory model is not
>> > >> > compatible
>> > >> > with
>> > >> > banked model.
>> > >> >
>> > >> >
>> > >> >
>> > >> > At 07:38 AM 7/18/2005, Adrian Vos wrote:
>> > >> >>Hi All,
>> > >> >>
>> > >> >>I am using Metrowerks for HCS12 v2.0. In the small memory model it
>> > >> >>is
>> > >> >>easy
>> > >> >>to get access to the 2 16k fixed flash pages, but I am running out
>> > >> >>of
>> > >> >>code
>> > >> >>space as I quickly approach 32k code size. I was hoping to write
>> > >> >>into
>> > >> >>my
>> > >> >>start code some code to fix the PPAGE register at a particular
>> > >> >>page
>> > >> >>(not
>> > >> >>3E
>> > >> >>of 3F which are the fixed pages), and then utilise the banked
>> > >> >>memory
>> > >> >>range
>> > >> >>to extend to 48k of usable ROM whilst still using the small memory
>> > >> >>model.
>> > >> >>I
>> > >> >>am not sure how to do this with the PRM file, and I was hoping
>> > >> >>someone
>> > >> >>could
>> > >> >>tell me. I try setting a new segment from 308000 to 30BFFF, but
>> > >> >>the
>> > >> >>linker
>> > >> >>complains that it is not allowed to allocate to this address in
>> > >> >>small
>> > >> >>memory
>> > >> >>model mode. It does not complain if I set the segment from 8000 to
>> > >> >>BFFF,
>> > >> >>but
>> > >> >>I have no idea which page it will stick the code into (if any) to
>> > >> >>correctly
>> > >> >>initialise the PPAGE register.
>> > >> >>
>> > >> >>If someone can advise if what I want to do is possible, and if so
>> > >> >>the
>> > >> >>best
>> > >> >>way to achieve it, that would be appreciated.
>> > >> >>
>> > >> >>Cheers,
>> > >> >>
>> > >> >>Adrian
>> > >> >>
>> > >> >>Send instant messages to your online friends
>> > >> >>http://au.messenger.yahoo.com
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >>Yahoo! Groups Links
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> > Yahoo! Groups Links
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >>
>> > >>Send instant messages to your online friends
>> http://au.messenger.yahoo.com
>> > >>
>> > >>
>> > >>
>> > >>Yahoo! Groups Links
>> > >>
>> > >>
>> > >>
>> > >>
>> > >
>> > >
>> > >
>> > >
>> > > Yahoo! Groups Links
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> >Send instant messages to your online friends
>> >http://au.messenger.yahoo.com
>> >
>> >
>> >
>> >Yahoo! Groups Links
>> >
>> >
>> >
>> >
>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
> >
>
> Yahoo! Groups Links >
>
Send instant messages to your online friends http://au.messenger.yahoo.com
