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
>
>
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
>
>
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
> >
> >
> >
> >
> >
> > >.
> >
> >
> >
>
>
Reply by Dave Perreault●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
> >.
>
>
Reply by Al Grippo●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.
>
Reply by Daniel Friededrich●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
>
Reply by Jefferson Smith●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
Reply by Jefferson Smith●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 ?
>
Reply by Al Grippo●July 19, 20052005-07-19
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
>
Reply by Gilles Blanquin●July 19, 20052005-07-19
Hi again, Adrian.
I just posted a new driver compliant with CW12V2.x
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
>
>