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
Metrowerks small memory model banked memory
Started by ●July 18, 2005
Reply by ●July 18, 20052005-07-18
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 >
>
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 >
>
Reply by ●July 18, 20052005-07-18
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
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
Reply by ●July 18, 20052005-07-18
Adrian,
Seems to me all you need to do is stick an assignment of PPAGE = 0x3D
somewhere very early in your code, and make sure that the code up until
this PPAGE assignment is found in the fixed Flash windows in 0xC000-0xFFFF
or 0x4000-0x7FFF.
You can add it also to the initialization module (the code that runs right
after Reset and before your main C function is started) in assembly using
the following instruction:
movb #$3D, PPAGE
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
At 15:38 18/07/2005 +1000, you 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
Seems to me all you need to do is stick an assignment of PPAGE = 0x3D
somewhere very early in your code, and make sure that the code up until
this PPAGE assignment is found in the fixed Flash windows in 0xC000-0xFFFF
or 0x4000-0x7FFF.
You can add it also to the initialization module (the code that runs right
after Reset and before your main C function is started) in assembly using
the following instruction:
movb #$3D, PPAGE
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
At 15:38 18/07/2005 +1000, you 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
Reply by ●July 18, 20052005-07-18
That is basically correct Doron. The problem I am having is getting the
Metroworks flash programmer to write the address range 8000-BFFF in one of
the pages from 30-3D. It seems to link it alright and put it in the S19 file
(under the address range 8000-BFFF)correctly so you could use another method
of programming to do it from the S19 file (as long as it could remap the
address range 8000-BFFF to a flash page), but unfortunately the flash
programmer that is part of the metrowerks package will not program this
address range. I believe Gilles is making changes so that the range
8000-BFFF is mapped to page 30.
Or am I missing something?????
-- Adrian
----- Original Message -----
From: "Doron Fael" <doronf@doro...>
To: <68HC12@68HC...>
Sent: Monday, July 18, 2005 5:20 PM
Subject: Re: [68HC12] Metrowerks small memory model banked memory > Adrian,
>
> Seems to me all you need to do is stick an assignment of PPAGE = 0x3D
> somewhere very early in your code, and make sure that the code up until
> this PPAGE assignment is found in the fixed Flash windows in 0xC000-0xFFFF
> or 0x4000-0x7FFF.
>
> You can add it also to the initialization module (the code that runs right
> after Reset and before your main C function is started) in assembly using
> the following instruction:
> movb #$3D, PPAGE
>
> Doron
> Nohau
> HC12 In-Circuit Emulators
> www.nohau.com/emul12pc.html
>
> At 15:38 18/07/2005 +1000, you 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 >
>
> Yahoo! Groups Links >
>
Send instant messages to your online friends http://au.messenger.yahoo.com
Metroworks flash programmer to write the address range 8000-BFFF in one of
the pages from 30-3D. It seems to link it alright and put it in the S19 file
(under the address range 8000-BFFF)correctly so you could use another method
of programming to do it from the S19 file (as long as it could remap the
address range 8000-BFFF to a flash page), but unfortunately the flash
programmer that is part of the metrowerks package will not program this
address range. I believe Gilles is making changes so that the range
8000-BFFF is mapped to page 30.
Or am I missing something?????
-- Adrian
----- Original Message -----
From: "Doron Fael" <doronf@doro...>
To: <68HC12@68HC...>
Sent: Monday, July 18, 2005 5:20 PM
Subject: Re: [68HC12] Metrowerks small memory model banked memory > Adrian,
>
> Seems to me all you need to do is stick an assignment of PPAGE = 0x3D
> somewhere very early in your code, and make sure that the code up until
> this PPAGE assignment is found in the fixed Flash windows in 0xC000-0xFFFF
> or 0x4000-0x7FFF.
>
> You can add it also to the initialization module (the code that runs right
> after Reset and before your main C function is started) in assembly using
> the following instruction:
> movb #$3D, PPAGE
>
> Doron
> Nohau
> HC12 In-Circuit Emulators
> www.nohau.com/emul12pc.html
>
> At 15:38 18/07/2005 +1000, you 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 >
>
> Yahoo! Groups Links >
>
Send instant messages to your online friends http://au.messenger.yahoo.com
Reply by ●July 18, 20052005-07-18
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 >
>
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 >
>
Reply by ●July 18, 20052005-07-18
Actually I did not use V2.0 for quite some time.
Currently 3.1 is the current one for HC12/HCS12 and V4.1 is the current
one for HCS12X.
Anyway, the point I want to make here is that I remember there was once
an linker error in the small memory model when you would use banked
addresses in a prm file. This message has been removed some time ago,
but I'm not sure about the status of V2.0.
Did you try to disable this message? That's what I would suggest (apart
from using a more current linker).
I think the prm file should allocate the 0x3D page at its paged address,
0x3D8000 TO 0x3DBFFF. Of course using 0x8000 to 0xBFFF looks nice, but
you do need some special treating while downloading the code so it does
get mapped to 0x3D8000 (or 0x308000, or wherever). Just using 0x3D8000
seems to be simpler.
There might however be some linker messages about cutting addresses from
the 0x3D8000 to 0x8000, but as this is what you want to do, you can
ignore them.
Daniel PS: Be aware that by manually moving the code from 0x8000 to 0x308000,
the debug information wont be matching anymore.
PPS: you could write a bbl file to perform the remapping, but I would
use banked addresses in the prm file instead.
PPPS: If you are using a device with 256k flash, then the small memory
model might not be the best choice anyway. Using the banked memory model
has not a large overhead compared with small, so maybe this would even
be the best/cleanest solution for you.
Adrian Vos wrote:
> That is basically correct Doron. The problem I am having is getting the
> Metroworks flash programmer to write the address range 8000-BFFF in one of
> the pages from 30-3D. It seems to link it alright and put it in the S19 file
> (under the address range 8000-BFFF)correctly so you could use another method
> of programming to do it from the S19 file (as long as it could remap the
> address range 8000-BFFF to a flash page), but unfortunately the flash
> programmer that is part of the metrowerks package will not program this
> address range. I believe Gilles is making changes so that the range
> 8000-BFFF is mapped to page 30.
>
> Or am I missing something?????
>
> -- Adrian
>
> ----- Original Message -----
> From: "Doron Fael" <doronf@doro...>
> To: <68HC12@68HC...>
> Sent: Monday, July 18, 2005 5:20 PM
> Subject: Re: [68HC12] Metrowerks small memory model banked memory >
>>Adrian,
>>
>>Seems to me all you need to do is stick an assignment of PPAGE = 0x3D
>>somewhere very early in your code, and make sure that the code up until
>>this PPAGE assignment is found in the fixed Flash windows in 0xC000-0xFFFF
>>or 0x4000-0x7FFF.
>>
>>You can add it also to the initialization module (the code that runs right
>>after Reset and before your main C function is started) in assembly using
>>the following instruction:
>>movb #$3D, PPAGE
>>
>>Doron
>>Nohau
>>HC12 In-Circuit Emulators
>>www.nohau.com/emul12pc.html
>>
>>At 15:38 18/07/2005 +1000, you 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
>>
>>
>>
>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
> > Send instant messages to your online friends http://au.messenger.yahoo.com >
> Yahoo! Groups Links >
Currently 3.1 is the current one for HC12/HCS12 and V4.1 is the current
one for HCS12X.
Anyway, the point I want to make here is that I remember there was once
an linker error in the small memory model when you would use banked
addresses in a prm file. This message has been removed some time ago,
but I'm not sure about the status of V2.0.
Did you try to disable this message? That's what I would suggest (apart
from using a more current linker).
I think the prm file should allocate the 0x3D page at its paged address,
0x3D8000 TO 0x3DBFFF. Of course using 0x8000 to 0xBFFF looks nice, but
you do need some special treating while downloading the code so it does
get mapped to 0x3D8000 (or 0x308000, or wherever). Just using 0x3D8000
seems to be simpler.
There might however be some linker messages about cutting addresses from
the 0x3D8000 to 0x8000, but as this is what you want to do, you can
ignore them.
Daniel PS: Be aware that by manually moving the code from 0x8000 to 0x308000,
the debug information wont be matching anymore.
PPS: you could write a bbl file to perform the remapping, but I would
use banked addresses in the prm file instead.
PPPS: If you are using a device with 256k flash, then the small memory
model might not be the best choice anyway. Using the banked memory model
has not a large overhead compared with small, so maybe this would even
be the best/cleanest solution for you.
Adrian Vos wrote:
> That is basically correct Doron. The problem I am having is getting the
> Metroworks flash programmer to write the address range 8000-BFFF in one of
> the pages from 30-3D. It seems to link it alright and put it in the S19 file
> (under the address range 8000-BFFF)correctly so you could use another method
> of programming to do it from the S19 file (as long as it could remap the
> address range 8000-BFFF to a flash page), but unfortunately the flash
> programmer that is part of the metrowerks package will not program this
> address range. I believe Gilles is making changes so that the range
> 8000-BFFF is mapped to page 30.
>
> Or am I missing something?????
>
> -- Adrian
>
> ----- Original Message -----
> From: "Doron Fael" <doronf@doro...>
> To: <68HC12@68HC...>
> Sent: Monday, July 18, 2005 5:20 PM
> Subject: Re: [68HC12] Metrowerks small memory model banked memory >
>>Adrian,
>>
>>Seems to me all you need to do is stick an assignment of PPAGE = 0x3D
>>somewhere very early in your code, and make sure that the code up until
>>this PPAGE assignment is found in the fixed Flash windows in 0xC000-0xFFFF
>>or 0x4000-0x7FFF.
>>
>>You can add it also to the initialization module (the code that runs right
>>after Reset and before your main C function is started) in assembly using
>>the following instruction:
>>movb #$3D, PPAGE
>>
>>Doron
>>Nohau
>>HC12 In-Circuit Emulators
>>www.nohau.com/emul12pc.html
>>
>>At 15:38 18/07/2005 +1000, you 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
>>
>>
>>
>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
> > Send instant messages to your online friends http://au.messenger.yahoo.com >
> Yahoo! Groups Links >
Reply by ●July 19, 20052005-07-19
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
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
Reply by ●July 19, 20052005-07-19
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 >
>
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 >
>
Reply by ●July 19, 20052005-07-19
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 >
>
