I am working with a legacy program written in HC11 assembler and ported to
HC9S12D64 assembler using MiniIDE and using TwinPeeks2.0 as the monitor residing
at $F000-$FFFF.
The program is growing and I need extra space in Flash. How do I program for
and access PPAGE=$3D? Can this be done using MiniIDE and TwinPeeks?
When MiniIDE detects ORG statement beyond FFFF it starts generating S2 records
instead of S1 records. But when it does that, the pages get scrambled:
3C:8000 gets located at $0000
3D:8000 gets located at $4000
3E:8000 (normally $4000) gets located at $8000
3F:8000 (normally $C000) stays located at $C000
TwinPeeks sees the S2 records and takes the address first byte as the page, but
then addressing gets really strange, because all my accesses to $4000-7FFF and
$C000-DFFF get lost in the translation
And then there is the EEPROM scramble. EEPROM code programmed for $0400 now
resides at $8400 which conflicts with the code that gets put into $8400 (which
is what was supposed to be at $4400).
Do I need to break the program up into multiple files, one for each page and one
for EEPROM, and program them semarately via TwinPeeks?
I did convert the startup code and some parts of the code to ICC12 v7 (Std,
handles a max of 64K Flash), but what little I have takes up almost all of flash
without moving into page $3D, and I havent figured out how to do that yet. So
moving to ICC would require moving to a HC9S12D256 chip and upgrading to the
more expensive ICC. ouch, new board and all.
wade
legacy: MiniIDE and HC9S12D64
Started by ●September 24, 2009
Reply by ●September 24, 20092009-09-24
"warm38spl" wrote:
>I am working with a legacy program written in HC11 assembler and ported to
>HC9S12D64 assembler using MiniIDE and using TwinPeeks2.0 as the monitor
>residing at $F000-$FFFF.
>
> The program is growing and I need extra space in Flash. How do I program
> for and access PPAGE=$3D? Can this be done using MiniIDE and TwinPeeks?
>
> When MiniIDE detects ORG statement beyond FFFF it starts generating S2
> records instead of S1 records. But when it does that, the pages get
> scrambled:
> 3C:8000 gets located at $0000
How did you detect this? D64 has no flash between $0 and $3FFF.
> 3D:8000 gets located at $4000
> 3E:8000 (normally $4000) gets located at $8000
> 3F:8000 (normally $C000) stays located at $C000
>
> TwinPeeks sees the S2 records and takes the address first byte as the
> page, but then addressing gets really strange, because all my accesses to
> $4000-7FFF and $C000-DFFF get lost in the translation
This ^^ is contrary a bit to TwinPEEKs manual:
"S2-Records use ***linear*** adresses according to Freescale guidelines.
The valid address range for the MC9S12D64 starts at 0xF0000 (0x3C *
16KB) and ends at 0xFFFFF (0x40 * 16 KB - 1)."
So highest order S2 address byte isn't taken as ppage. Ppage value can be
calculated from linear S2 address dividing address by page size ($4000).
>
> And then there is the EEPROM scramble. EEPROM code programmed for $0400
> now resides at $8400 which conflicts with the code that gets put into
> $8400 (which is what was supposed to be at $4400).
>
> Do I need to break the program up into multiple files, one for each page
> and one for EEPROM, and program them semarately via TwinPeeks?
I guess MiniIDE creates banked S2 records (ppage + offset) instead of linear
S2 records. You may have to convert them. P&E Log2Phy utility can do it.
>
> I did convert the startup code and some parts of the code to ICC12 v7
> (Std, handles a max of 64K Flash), but what little I have takes up almost
> all of flash without moving into page $3D, and I havent figured out how to
> do that yet. So moving to ICC would require moving to a HC9S12D256 chip
> and upgrading to the more expensive ICC. ouch, new board and all.
As far as I know, ICC12 V7 STD handles unlimited amount of nonpaged memory
($0..$FFFF) and max 64K of paged code (64K in routines callable using CALL
instructions). STD should handle all available D64 memory and even 3/4 of
D128 flash.
>
> wade
Edward
>I am working with a legacy program written in HC11 assembler and ported to
>HC9S12D64 assembler using MiniIDE and using TwinPeeks2.0 as the monitor
>residing at $F000-$FFFF.
>
> The program is growing and I need extra space in Flash. How do I program
> for and access PPAGE=$3D? Can this be done using MiniIDE and TwinPeeks?
>
> When MiniIDE detects ORG statement beyond FFFF it starts generating S2
> records instead of S1 records. But when it does that, the pages get
> scrambled:
> 3C:8000 gets located at $0000
How did you detect this? D64 has no flash between $0 and $3FFF.
> 3D:8000 gets located at $4000
> 3E:8000 (normally $4000) gets located at $8000
> 3F:8000 (normally $C000) stays located at $C000
>
> TwinPeeks sees the S2 records and takes the address first byte as the
> page, but then addressing gets really strange, because all my accesses to
> $4000-7FFF and $C000-DFFF get lost in the translation
This ^^ is contrary a bit to TwinPEEKs manual:
"S2-Records use ***linear*** adresses according to Freescale guidelines.
The valid address range for the MC9S12D64 starts at 0xF0000 (0x3C *
16KB) and ends at 0xFFFFF (0x40 * 16 KB - 1)."
So highest order S2 address byte isn't taken as ppage. Ppage value can be
calculated from linear S2 address dividing address by page size ($4000).
>
> And then there is the EEPROM scramble. EEPROM code programmed for $0400
> now resides at $8400 which conflicts with the code that gets put into
> $8400 (which is what was supposed to be at $4400).
>
> Do I need to break the program up into multiple files, one for each page
> and one for EEPROM, and program them semarately via TwinPeeks?
I guess MiniIDE creates banked S2 records (ppage + offset) instead of linear
S2 records. You may have to convert them. P&E Log2Phy utility can do it.
>
> I did convert the startup code and some parts of the code to ICC12 v7
> (Std, handles a max of 64K Flash), but what little I have takes up almost
> all of flash without moving into page $3D, and I havent figured out how to
> do that yet. So moving to ICC would require moving to a HC9S12D256 chip
> and upgrading to the more expensive ICC. ouch, new board and all.
As far as I know, ICC12 V7 STD handles unlimited amount of nonpaged memory
($0..$FFFF) and max 64K of paged code (64K in routines callable using CALL
instructions). STD should handle all available D64 memory and even 3/4 of
D128 flash.
>
> wade
Edward
Reply by ●September 24, 20092009-09-24
--- In 6..., "Edward Karpicz" wrote:
>
> "warm38spl" wrote:
>
> >I am working with a legacy program written in HC11 assembler and ported to
> >HC9S12D64 assembler using MiniIDE and using TwinPeeks2.0 as the monitor
> >residing at $F000-$FFFF.
> >
> > The program is growing and I need extra space in Flash. How do I program
> > for and access PPAGE=$3D? Can this be done using MiniIDE and TwinPeeks?
> >
> > When MiniIDE detects ORG statement beyond FFFF it starts generating S2
> > records instead of S1 records. But when it does that, the pages get
> > scrambled:
> > 3C:8000 gets located at $0000
>
> How did you detect this? D64 has no flash between $0 and $3FFF.
#1 experience.
---------------
In my first attempt I put one small piece of code over $FFFF. When I loaded the S19 file (full of S2 records) the code for "ORG $8000" never showed up. The code for "ORG $C000" showed up at $C000. The code for "ORG $4000" showed up at $8000. I couldn't find the 3D code anywhere.
#2 Document S12FTS64KV1/D pdf file page 18 Table 3-2 Memory Maps Summary "Block Relative Address" Which lines up with what I was seeing when S2 records are used with TwinPeeks loading the S2 records.
MCU PPage Block Rel
$4000 3E $8000 (ouch)
$8000 3C $0000 (ouch)
3D $4000 (ouch)
$C000 3F $C000
So, no matter what address I try to set in my asm file, the assembler and the S2 effect on TwinPeeks scramble the addresses.
To get TwinPeeks to put it in the correct places, I have to use
$4000 = ORG $xx8000
$8000 = ORG $xx0000
3D = ORG $xx04000
$C000 = ORG $xxC000
I haven't noticed any difference as to what I put in place of "$xx" in the ORG statements because it is the last 4 that determine were it shows up when I set PPAGE. Now THAT really messes up where I go to call a function ar access a constant. :-b
Oh, and MiniIDE gives 300+ warnings showing that the 3-byte address is truncated to a two-byte address. (but in the wrong location).
> > 3D:8000 gets located at $4000
> > 3E:8000 (normally $4000) gets located at $8000
> > 3F:8000 (normally $C000) stays located at $C000
> >
> > TwinPeeks sees the S2 records and takes the address first byte as the
> > page, but then addressing gets really strange, because all my accesses to
> > $4000-7FFF and $C000-DFFF get lost in the translation
> This ^^ is contrary a bit to TwinPEEKs manual:
>
> "S2-Records use ***linear*** adresses according to Freescale guidelines.
> The valid address range for the MC9S12D64 starts at 0xF0000 (0x3C *
> 16KB) and ends at 0xFFFFF (0x40 * 16 KB - 1)."
>
> So highest order S2 address byte isn't taken as ppage. Ppage value can be
> calculated from linear S2 address dividing address by page size ($4000).
As I traced through the TwinPeeks source code listing, I saw that it just ignored the first byte of the address, i.e. truncation just like MiniIDE, but at least it shows up where I expect it to -- just all references are now scrambled.
> >
> > And then there is the EEPROM scramble. EEPROM code programmed for $0400
> > now resides at $8400 which conflicts with the code that gets put into
> > $8400 (which is what was supposed to be at $4400).
> >
> > Do I need to break the program up into multiple files, one for each page
> > and one for EEPROM, and program them semarately via TwinPeeks?
>
> I guess MiniIDE creates banked S2 records (ppage + offset) instead of linear
> S2 records. You may have to convert them. P&E Log2Phy utility can do it.
the MiniIDE generates S214000400... records for EEPROM. But TwinPeeks is the one that complains that $8400 is already programmed. That tells me that 000400 gets translated to 008400, which also supports the S12FTS64KV1/D pdf file. :-b
Is the P&E utility downloadable and free? The company I do work for has a CyclonePro, but I do not.
> >
> > I did convert the startup code and some parts of the code to ICC12 v7
> > (Std, handles a max of 64K Flash), but what little I have takes up almost
> > all of flash without moving into page $3D, and I havent figured out how to
> > do that yet. So moving to ICC would require moving to a HC9S12D256 chip
> > and upgrading to the more expensive ICC. ouch, new board and all.
> As far as I know, ICC12 V7 STD handles unlimited amount of nonpaged memory
> ($0..$FFFF) and max 64K of paged code (64K in routines callable using CALL
> instructions). STD should handle all available D64 memory and even 3/4 of
> D128 flash.
Now if I ONLY knew how to do paged stuff in ICC, I'd be set. :-)
I have no problem with using $4000-$DFFF, but no paging involved.
Got any suggestions as to how to do paged code in ICC to fix my ignernts?
> >
> > wade
> >
> > Edward
>
>
> "warm38spl" wrote:
>
> >I am working with a legacy program written in HC11 assembler and ported to
> >HC9S12D64 assembler using MiniIDE and using TwinPeeks2.0 as the monitor
> >residing at $F000-$FFFF.
> >
> > The program is growing and I need extra space in Flash. How do I program
> > for and access PPAGE=$3D? Can this be done using MiniIDE and TwinPeeks?
> >
> > When MiniIDE detects ORG statement beyond FFFF it starts generating S2
> > records instead of S1 records. But when it does that, the pages get
> > scrambled:
> > 3C:8000 gets located at $0000
>
> How did you detect this? D64 has no flash between $0 and $3FFF.
#1 experience.
---------------
In my first attempt I put one small piece of code over $FFFF. When I loaded the S19 file (full of S2 records) the code for "ORG $8000" never showed up. The code for "ORG $C000" showed up at $C000. The code for "ORG $4000" showed up at $8000. I couldn't find the 3D code anywhere.
#2 Document S12FTS64KV1/D pdf file page 18 Table 3-2 Memory Maps Summary "Block Relative Address" Which lines up with what I was seeing when S2 records are used with TwinPeeks loading the S2 records.
MCU PPage Block Rel
$4000 3E $8000 (ouch)
$8000 3C $0000 (ouch)
3D $4000 (ouch)
$C000 3F $C000
So, no matter what address I try to set in my asm file, the assembler and the S2 effect on TwinPeeks scramble the addresses.
To get TwinPeeks to put it in the correct places, I have to use
$4000 = ORG $xx8000
$8000 = ORG $xx0000
3D = ORG $xx04000
$C000 = ORG $xxC000
I haven't noticed any difference as to what I put in place of "$xx" in the ORG statements because it is the last 4 that determine were it shows up when I set PPAGE. Now THAT really messes up where I go to call a function ar access a constant. :-b
Oh, and MiniIDE gives 300+ warnings showing that the 3-byte address is truncated to a two-byte address. (but in the wrong location).
> > 3D:8000 gets located at $4000
> > 3E:8000 (normally $4000) gets located at $8000
> > 3F:8000 (normally $C000) stays located at $C000
> >
> > TwinPeeks sees the S2 records and takes the address first byte as the
> > page, but then addressing gets really strange, because all my accesses to
> > $4000-7FFF and $C000-DFFF get lost in the translation
> This ^^ is contrary a bit to TwinPEEKs manual:
>
> "S2-Records use ***linear*** adresses according to Freescale guidelines.
> The valid address range for the MC9S12D64 starts at 0xF0000 (0x3C *
> 16KB) and ends at 0xFFFFF (0x40 * 16 KB - 1)."
>
> So highest order S2 address byte isn't taken as ppage. Ppage value can be
> calculated from linear S2 address dividing address by page size ($4000).
As I traced through the TwinPeeks source code listing, I saw that it just ignored the first byte of the address, i.e. truncation just like MiniIDE, but at least it shows up where I expect it to -- just all references are now scrambled.
> >
> > And then there is the EEPROM scramble. EEPROM code programmed for $0400
> > now resides at $8400 which conflicts with the code that gets put into
> > $8400 (which is what was supposed to be at $4400).
> >
> > Do I need to break the program up into multiple files, one for each page
> > and one for EEPROM, and program them semarately via TwinPeeks?
>
> I guess MiniIDE creates banked S2 records (ppage + offset) instead of linear
> S2 records. You may have to convert them. P&E Log2Phy utility can do it.
the MiniIDE generates S214000400... records for EEPROM. But TwinPeeks is the one that complains that $8400 is already programmed. That tells me that 000400 gets translated to 008400, which also supports the S12FTS64KV1/D pdf file. :-b
Is the P&E utility downloadable and free? The company I do work for has a CyclonePro, but I do not.
> >
> > I did convert the startup code and some parts of the code to ICC12 v7
> > (Std, handles a max of 64K Flash), but what little I have takes up almost
> > all of flash without moving into page $3D, and I havent figured out how to
> > do that yet. So moving to ICC would require moving to a HC9S12D256 chip
> > and upgrading to the more expensive ICC. ouch, new board and all.
> As far as I know, ICC12 V7 STD handles unlimited amount of nonpaged memory
> ($0..$FFFF) and max 64K of paged code (64K in routines callable using CALL
> instructions). STD should handle all available D64 memory and even 3/4 of
> D128 flash.
Now if I ONLY knew how to do paged stuff in ICC, I'd be set. :-)
I have no problem with using $4000-$DFFF, but no paging involved.
Got any suggestions as to how to do paged code in ICC to fix my ignernts?
> >
> > wade
> >
> > Edward
>
Reply by ●September 25, 20092009-09-25
"warm38spl" wrote:
> --- In 6..., "Edward Karpicz" wrote:
>>
>> "warm38spl" wrote:
>>
>> >I am working with a legacy program written in HC11 assembler and ported
>> >to
>> >HC9S12D64 assembler using MiniIDE and using TwinPeeks2.0 as the monitor
>> >residing at $F000-$FFFF.
>> >
>> > The program is growing and I need extra space in Flash. How do I
>> > program
>> > for and access PPAGE=$3D? Can this be done using MiniIDE and
>> > TwinPeeks?
>> >
>> > When MiniIDE detects ORG statement beyond FFFF it starts generating S2
>> > records instead of S1 records. But when it does that, the pages get
>> > scrambled:
>> > 3C:8000 gets located at $0000
>>
>> How did you detect this? D64 has no flash between $0 and $3FFF.
>
> #1 experience.
> ---------------
> In my first attempt I put one small piece of code over $FFFF. When I
> loaded the S19 file (full of S2 records) the code for "ORG $8000" never
> showed up. The code for "ORG $C000" showed up at $C000. The code for
> "ORG $4000" showed up at $8000. I couldn't find the 3D code anywhere.
I didn't try S12 Elmicro/Elektronikladen board, but MC912DG128. It also came
with TwinPEEks. S1 records were directly translated to nonpaged CPU memory.
Linear S2 records were translated to ppage+page window offset. You write
below that eeprom S record looks like this:
S214000400
=> PPAGE = 0, CPU address 8400. D64 has 4 pages, that means PPAGE bits above
bits bit1-bit0 are ignored. PPAGE 0 is the same like PPAGE 3C.
Now if org C000 is also put at wrong linear address 00C000, PPAGE will be 3
(the same like 3F) and you will see your code at C000.
4000 - PPAGE 3D
0 - PPAGE 3C
8000 - PPAGE 3E
I think you should either translate addresses from banked to linear format,
or tell MiniIDE to not produce S2 records.
>
> #2 Document S12FTS64KV1/D pdf file page 18 Table 3-2 Memory Maps Summary
> "Block Relative Address" Which lines up with what I was seeing when S2
> records are used with TwinPeeks loading the S2 records.
>
> MCU PPage Block Rel
> $4000 3E $8000 (ouch)
> $8000 3C $0000 (ouch)
> 3D $4000 (ouch)
> $C000 3F $C000
>
> So, no matter what address I try to set in my asm file, the assembler and
> the S2 effect on TwinPeeks scramble the addresses.
>
> To get TwinPeeks to put it in the correct places, I have to use
>
> $4000 = ORG $xx8000
> $8000 = ORG $xx0000
> 3D = ORG $xx04000
> $C000 = ORG $xxC000
>
> I haven't noticed any difference as to what I put in place of "$xx" in the
> ORG statements because it is the last 4 that determine were it shows up
> when I set PPAGE. Now THAT really messes up where I go to call a function
> ar access a constant. :-b
>
> Oh, and MiniIDE gives 300+ warnings showing that the 3-byte address is
> truncated to a two-byte address. (but in the wrong location).
>
>> > 3D:8000 gets located at $4000
>> > 3E:8000 (normally $4000) gets located at $8000
>> > 3F:8000 (normally $C000) stays located at $C000
>> >
>> > TwinPeeks sees the S2 records and takes the address first byte as the
>> > page, but then addressing gets really strange, because all my accesses
>> > to
>> > $4000-7FFF and $C000-DFFF get lost in the translation
>> This ^^ is contrary a bit to TwinPEEKs manual:
>>
>> "S2-Records use ***linear*** adresses according to Freescale
>> guidelines.
>> The valid address range for the MC9S12D64 starts at 0xF0000 (0x3C *
>> 16KB) and ends at 0xFFFFF (0x40 * 16 KB - 1)."
>>
>> So highest order S2 address byte isn't taken as ppage. Ppage value can be
>> calculated from linear S2 address dividing address by page size ($4000).
>
> As I traced through the TwinPeeks source code listing, I saw that it just
> ignored the first byte of the address, i.e. truncation just like MiniIDE,
> but at least it shows up where I expect it to -- just all references are
> now scrambled.
I doubt it. It may and should "discard" highest order byte in case of S1
record.
>
>> >
>> > And then there is the EEPROM scramble. EEPROM code programmed for
>> > $0400
>> > now resides at $8400 which conflicts with the code that gets put into
>> > $8400 (which is what was supposed to be at $4400).
>> >
>> > Do I need to break the program up into multiple files, one for each
>> > page
>> > and one for EEPROM, and program them semarately via TwinPeeks?
>>
>> I guess MiniIDE creates banked S2 records (ppage + offset) instead of
>> linear
>> S2 records. You may have to convert them. P&E Log2Phy utility can do it.
>
> the MiniIDE generates S214000400... records for EEPROM. But TwinPeeks is
> the one that complains that $8400 is already programmed. That tells me
> that 000400 gets translated to 008400, which also supports the
> S12FTS64KV1/D pdf file. :-b
>
> Is the P&E utility downloadable and free? The company I do work for has a
> CyclonePro, but I do not.
Have a look at www.pemicro.com . It should be free
>
>> >
>> > I did convert the startup code and some parts of the code to ICC12 v7
>> > (Std, handles a max of 64K Flash), but what little I have takes up
>> > almost
>> > all of flash without moving into page $3D, and I havent figured out how
>> > to
>> > do that yet. So moving to ICC would require moving to a HC9S12D256
>> > chip
>> > and upgrading to the more expensive ICC. ouch, new board and all.
>> As far as I know, ICC12 V7 STD handles unlimited amount of nonpaged
>> memory
>> ($0..$FFFF) and max 64K of paged code (64K in routines callable using
>> CALL
>> instructions). STD should handle all available D64 memory and even 3/4 of
>> D128 flash.
>
> Now if I ONLY knew how to do paged stuff in ICC, I'd be set. :-)
In compiler options dialog check Enable Expanded Memory. Also check Make
Paged Functions Default. If you don't want all functions to be paged or
nonpaged, to force specific functions to be paged/nonpaged, use pragmas like
this:
#pragma paged_function foo1 // foo1() will be paged
foo1()
{
}
#pragma nonpaged_function foo2 // foo2() will be forced nonpaged
foo2()
{
}
> I have no problem with using $4000-$DFFF, but no paging involved.
> Got any suggestions as to how to do paged code in ICC to fix my ignernts?
>
>> >
>> > wade
>> >
>> >
>>
>> Edward
>>
Edward
> --- In 6..., "Edward Karpicz" wrote:
>>
>> "warm38spl" wrote:
>>
>> >I am working with a legacy program written in HC11 assembler and ported
>> >to
>> >HC9S12D64 assembler using MiniIDE and using TwinPeeks2.0 as the monitor
>> >residing at $F000-$FFFF.
>> >
>> > The program is growing and I need extra space in Flash. How do I
>> > program
>> > for and access PPAGE=$3D? Can this be done using MiniIDE and
>> > TwinPeeks?
>> >
>> > When MiniIDE detects ORG statement beyond FFFF it starts generating S2
>> > records instead of S1 records. But when it does that, the pages get
>> > scrambled:
>> > 3C:8000 gets located at $0000
>>
>> How did you detect this? D64 has no flash between $0 and $3FFF.
>
> #1 experience.
> ---------------
> In my first attempt I put one small piece of code over $FFFF. When I
> loaded the S19 file (full of S2 records) the code for "ORG $8000" never
> showed up. The code for "ORG $C000" showed up at $C000. The code for
> "ORG $4000" showed up at $8000. I couldn't find the 3D code anywhere.
I didn't try S12 Elmicro/Elektronikladen board, but MC912DG128. It also came
with TwinPEEks. S1 records were directly translated to nonpaged CPU memory.
Linear S2 records were translated to ppage+page window offset. You write
below that eeprom S record looks like this:
S214000400
=> PPAGE = 0, CPU address 8400. D64 has 4 pages, that means PPAGE bits above
bits bit1-bit0 are ignored. PPAGE 0 is the same like PPAGE 3C.
Now if org C000 is also put at wrong linear address 00C000, PPAGE will be 3
(the same like 3F) and you will see your code at C000.
4000 - PPAGE 3D
0 - PPAGE 3C
8000 - PPAGE 3E
I think you should either translate addresses from banked to linear format,
or tell MiniIDE to not produce S2 records.
>
> #2 Document S12FTS64KV1/D pdf file page 18 Table 3-2 Memory Maps Summary
> "Block Relative Address" Which lines up with what I was seeing when S2
> records are used with TwinPeeks loading the S2 records.
>
> MCU PPage Block Rel
> $4000 3E $8000 (ouch)
> $8000 3C $0000 (ouch)
> 3D $4000 (ouch)
> $C000 3F $C000
>
> So, no matter what address I try to set in my asm file, the assembler and
> the S2 effect on TwinPeeks scramble the addresses.
>
> To get TwinPeeks to put it in the correct places, I have to use
>
> $4000 = ORG $xx8000
> $8000 = ORG $xx0000
> 3D = ORG $xx04000
> $C000 = ORG $xxC000
>
> I haven't noticed any difference as to what I put in place of "$xx" in the
> ORG statements because it is the last 4 that determine were it shows up
> when I set PPAGE. Now THAT really messes up where I go to call a function
> ar access a constant. :-b
>
> Oh, and MiniIDE gives 300+ warnings showing that the 3-byte address is
> truncated to a two-byte address. (but in the wrong location).
>
>> > 3D:8000 gets located at $4000
>> > 3E:8000 (normally $4000) gets located at $8000
>> > 3F:8000 (normally $C000) stays located at $C000
>> >
>> > TwinPeeks sees the S2 records and takes the address first byte as the
>> > page, but then addressing gets really strange, because all my accesses
>> > to
>> > $4000-7FFF and $C000-DFFF get lost in the translation
>> This ^^ is contrary a bit to TwinPEEKs manual:
>>
>> "S2-Records use ***linear*** adresses according to Freescale
>> guidelines.
>> The valid address range for the MC9S12D64 starts at 0xF0000 (0x3C *
>> 16KB) and ends at 0xFFFFF (0x40 * 16 KB - 1)."
>>
>> So highest order S2 address byte isn't taken as ppage. Ppage value can be
>> calculated from linear S2 address dividing address by page size ($4000).
>
> As I traced through the TwinPeeks source code listing, I saw that it just
> ignored the first byte of the address, i.e. truncation just like MiniIDE,
> but at least it shows up where I expect it to -- just all references are
> now scrambled.
I doubt it. It may and should "discard" highest order byte in case of S1
record.
>
>> >
>> > And then there is the EEPROM scramble. EEPROM code programmed for
>> > $0400
>> > now resides at $8400 which conflicts with the code that gets put into
>> > $8400 (which is what was supposed to be at $4400).
>> >
>> > Do I need to break the program up into multiple files, one for each
>> > page
>> > and one for EEPROM, and program them semarately via TwinPeeks?
>>
>> I guess MiniIDE creates banked S2 records (ppage + offset) instead of
>> linear
>> S2 records. You may have to convert them. P&E Log2Phy utility can do it.
>
> the MiniIDE generates S214000400... records for EEPROM. But TwinPeeks is
> the one that complains that $8400 is already programmed. That tells me
> that 000400 gets translated to 008400, which also supports the
> S12FTS64KV1/D pdf file. :-b
>
> Is the P&E utility downloadable and free? The company I do work for has a
> CyclonePro, but I do not.
Have a look at www.pemicro.com . It should be free
>
>> >
>> > I did convert the startup code and some parts of the code to ICC12 v7
>> > (Std, handles a max of 64K Flash), but what little I have takes up
>> > almost
>> > all of flash without moving into page $3D, and I havent figured out how
>> > to
>> > do that yet. So moving to ICC would require moving to a HC9S12D256
>> > chip
>> > and upgrading to the more expensive ICC. ouch, new board and all.
>> As far as I know, ICC12 V7 STD handles unlimited amount of nonpaged
>> memory
>> ($0..$FFFF) and max 64K of paged code (64K in routines callable using
>> CALL
>> instructions). STD should handle all available D64 memory and even 3/4 of
>> D128 flash.
>
> Now if I ONLY knew how to do paged stuff in ICC, I'd be set. :-)
In compiler options dialog check Enable Expanded Memory. Also check Make
Paged Functions Default. If you don't want all functions to be paged or
nonpaged, to force specific functions to be paged/nonpaged, use pragmas like
this:
#pragma paged_function foo1 // foo1() will be paged
foo1()
{
}
#pragma nonpaged_function foo2 // foo2() will be forced nonpaged
foo2()
{
}
> I have no problem with using $4000-$DFFF, but no paging involved.
> Got any suggestions as to how to do paged code in ICC to fix my ignernts?
>
>> >
>> > wade
>> >
>> >
>>
>> Edward
>>
Edward
Reply by ●September 25, 20092009-09-25
--- In 6..., "Edward Karpicz" wrote:
>
> "warm38spl" wrote:
>
> > --- In 6..., "Edward Karpicz" wrote:
> >>
> >> "warm38spl" wrote:
> >>
> >> >I am working with a legacy program written in HC11 assembler and ported
> >> >to
> >> >HC9S12D64 assembler using MiniIDE and using TwinPeeks2.0 as the monitor
> >> >residing at $F000-$FFFF.
>
> I didn't try S12 Elmicro/Elektronikladen board, but MC912DG128. It also came
The company bought the cards12 D64 board and their CPU board is based on that design.
> with TwinPEEks. S1 records were directly translated to nonpaged CPU memory.
> Linear S2 records were translated to ppage+page window offset. You write
> below that eeprom S record looks like this:
>
> S214000400
>
> => PPAGE = 0, CPU address 8400. D64 has 4 pages, that means PPAGE bits above
> bits bit1-bit0 are ignored. PPAGE 0 is the same like PPAGE 3C.
>
> Now if org C000 is also put at wrong linear address 00C000, PPAGE will be 3
> (the same like 3F) and you will see your code at C000.
> 4000 - PPAGE 3D
> 0 - PPAGE 3C
> 8000 - PPAGE 3E
>
> I think you should either translate addresses from banked to linear format,
> or tell MiniIDE to not produce S2 records.
OK. With all that being said, I tried a few experiments and GOT IT TO WORK:
Step 1:
set up for a "normal" $4000-DFFF
put the 3D code at the end and "ORG $8000"
kill "-page" on the command line of ASM12
compile it
Step 2:
strip off the end of the code with the second $8000
load that code using TwinPeeks (Y command; X command; L command)
verify that 3C code is there (and $4000 and $C000) and 3D is empty
P 3D
D 8000 (all "FF FF...")
P 3C
D 8000 (see code)
D 4000 (see code)
D C000 (see code)
D 0400 (see EEPROM)
Step 3:
change the 3D code to be "ORG $4000"
put "-page" on the command line of ASM12
compile it
Step 4:
strip off everything between the first line and the start of the last piece of code that starts with S214xx4000XXXXX (It does not matter what is in xx, because 4000 is what determines where it goes)
lode that S19 file (ONLY using L command)
TwinPeeks now comes up with a prompt of "00>" after S2 records loaded
enter "P 3C" and "D 8000" and the correct code is there
enter "P 3D" and "D 8000" and the correct code is there
TwinPeeks did what I thought it would. TwinPeeks does not care what "page" is in the S2. It only looks at the "block relative address" per S12FTS64KV1/D pdf file page 18.
BTW, the company I work for licensed the TwinPeeks source. He did a lot of work in that monitor. The company has only made VERY minor modifications to the code for their use.
I had tried the 3D8000 and it said 8000 is already programmed (by what will be seen in $4000/PPage>). If I strip out the S1 records for S1134000... then the S2143D8000 records load just fine, but in the wrong place.
Well, in any event, Edward, you HAVE helped me to accomplish what I needed to work with and load HC12 asm code into Page 3D.
THANK YOU! I REALLY could not have done this without your questoning my sanity and logic. You got me looking/thinking of other possibilities beyond my narrow, frustrated view ("it's just gotta be this way!").
> > #2 Document S12FTS64KV1/D pdf file page 18 Table 3-2 Memory Maps Summary
> >
> > As I traced through the TwinPeeks source code listing, I saw that it just
> > ignored the first byte of the address, i.e. truncation just like MiniIDE,
> > but at least it shows up where I expect it to -- just all references are
> > now scrambled.
> I doubt it. It may and should "discard" highest order byte in case of S1
> record.
> >
> >> >
> >> > And then there is the EEPROM scramble. EEPROM code programmed for
> >> > $0400
> >> > now resides at $8400 which conflicts with the code that gets put into
> >> > $8400 (which is what was supposed to be at $4400).
> >> >
> >> > Do I need to break the program up into multiple files, one for each
> >> > page
> >> > and one for EEPROM, and program them semarately via TwinPeeks?
> >>
> >> I guess MiniIDE creates banked S2 records (ppage + offset) instead of
> >> linear
> >> S2 records. You may have to convert them. P&E Log2Phy utility can do it.
> >
> > the MiniIDE generates S214000400... records for EEPROM. But TwinPeeks is
> > the one that complains that $8400 is already programmed. That tells me
> > that 000400 gets translated to 008400, which also supports the
> > S12FTS64KV1/D pdf file. :-b
> >
> > Is the P&E utility downloadable and free? The company I do work for has a
> > CyclonePro, but I do not.
>
> Have a look at www.pemicro.com . It should be free
I shall. Thanks.
> >> > I did convert the startup code and some parts of the code to ICC12 v7
> >> > (Std, handles a max of 64K Flash), but what little I have takes up
> >> > almost
> >> > all of flash without moving into page $3D, and I havent figured out how
> >> > to
> >> > do that yet. So moving to ICC would require moving to a HC9S12D256
> >> > chip
> >> > and upgrading to the more expensive ICC. ouch, new board and all.
> >>
> >>
> >> As far as I know, ICC12 V7 STD handles unlimited amount of nonpaged
> >> memory
> >> ($0..$FFFF) and max 64K of paged code (64K in routines callable using
> >> CALL
> >> instructions). STD should handle all available D64 memory and even 3/4 of
> >> D128 flash.
> >
> > Now if I ONLY knew how to do paged stuff in ICC, I'd be set. :-)
>
> In compiler options dialog check Enable Expanded Memory. Also check Make
> Paged Functions Default. If you don't want all functions to be paged or
> nonpaged, to force specific functions to be paged/nonpaged, use pragmas like
> this:
>
> #pragma paged_function foo1 // foo1() will be paged
> foo1()
> {
> }
>
> #pragma nonpaged_function foo2 // foo2() will be forced nonpaged
> foo2()
> {
> }
This has now been kept as a text file in my ICC12v7 directory and I'll try it as soon as my ASM stuff is working...
Edward, you are an excellent resource. Thank you!
> > I have no problem with using $4000-$DFFF, but no paging involved.
> > Got any suggestions as to how to do paged code in ICC to fix my ignernts?
> >
> >> >
> >> > wade
> >> >
> >> >
> >>
> >> Edward
> >> Edward
>
>
> "warm38spl" wrote:
>
> > --- In 6..., "Edward Karpicz" wrote:
> >>
> >> "warm38spl" wrote:
> >>
> >> >I am working with a legacy program written in HC11 assembler and ported
> >> >to
> >> >HC9S12D64 assembler using MiniIDE and using TwinPeeks2.0 as the monitor
> >> >residing at $F000-$FFFF.
>
> I didn't try S12 Elmicro/Elektronikladen board, but MC912DG128. It also came
The company bought the cards12 D64 board and their CPU board is based on that design.
> with TwinPEEks. S1 records were directly translated to nonpaged CPU memory.
> Linear S2 records were translated to ppage+page window offset. You write
> below that eeprom S record looks like this:
>
> S214000400
>
> => PPAGE = 0, CPU address 8400. D64 has 4 pages, that means PPAGE bits above
> bits bit1-bit0 are ignored. PPAGE 0 is the same like PPAGE 3C.
>
> Now if org C000 is also put at wrong linear address 00C000, PPAGE will be 3
> (the same like 3F) and you will see your code at C000.
> 4000 - PPAGE 3D
> 0 - PPAGE 3C
> 8000 - PPAGE 3E
>
> I think you should either translate addresses from banked to linear format,
> or tell MiniIDE to not produce S2 records.
OK. With all that being said, I tried a few experiments and GOT IT TO WORK:
Step 1:
set up for a "normal" $4000-DFFF
put the 3D code at the end and "ORG $8000"
kill "-page" on the command line of ASM12
compile it
Step 2:
strip off the end of the code with the second $8000
load that code using TwinPeeks (Y command; X command; L command)
verify that 3C code is there (and $4000 and $C000) and 3D is empty
P 3D
D 8000 (all "FF FF...")
P 3C
D 8000 (see code)
D 4000 (see code)
D C000 (see code)
D 0400 (see EEPROM)
Step 3:
change the 3D code to be "ORG $4000"
put "-page" on the command line of ASM12
compile it
Step 4:
strip off everything between the first line and the start of the last piece of code that starts with S214xx4000XXXXX (It does not matter what is in xx, because 4000 is what determines where it goes)
lode that S19 file (ONLY using L command)
TwinPeeks now comes up with a prompt of "00>" after S2 records loaded
enter "P 3C" and "D 8000" and the correct code is there
enter "P 3D" and "D 8000" and the correct code is there
TwinPeeks did what I thought it would. TwinPeeks does not care what "page" is in the S2. It only looks at the "block relative address" per S12FTS64KV1/D pdf file page 18.
BTW, the company I work for licensed the TwinPeeks source. He did a lot of work in that monitor. The company has only made VERY minor modifications to the code for their use.
I had tried the 3D8000 and it said 8000 is already programmed (by what will be seen in $4000/PPage>). If I strip out the S1 records for S1134000... then the S2143D8000 records load just fine, but in the wrong place.
Well, in any event, Edward, you HAVE helped me to accomplish what I needed to work with and load HC12 asm code into Page 3D.
THANK YOU! I REALLY could not have done this without your questoning my sanity and logic. You got me looking/thinking of other possibilities beyond my narrow, frustrated view ("it's just gotta be this way!").
> > #2 Document S12FTS64KV1/D pdf file page 18 Table 3-2 Memory Maps Summary
> >
> > As I traced through the TwinPeeks source code listing, I saw that it just
> > ignored the first byte of the address, i.e. truncation just like MiniIDE,
> > but at least it shows up where I expect it to -- just all references are
> > now scrambled.
> I doubt it. It may and should "discard" highest order byte in case of S1
> record.
> >
> >> >
> >> > And then there is the EEPROM scramble. EEPROM code programmed for
> >> > $0400
> >> > now resides at $8400 which conflicts with the code that gets put into
> >> > $8400 (which is what was supposed to be at $4400).
> >> >
> >> > Do I need to break the program up into multiple files, one for each
> >> > page
> >> > and one for EEPROM, and program them semarately via TwinPeeks?
> >>
> >> I guess MiniIDE creates banked S2 records (ppage + offset) instead of
> >> linear
> >> S2 records. You may have to convert them. P&E Log2Phy utility can do it.
> >
> > the MiniIDE generates S214000400... records for EEPROM. But TwinPeeks is
> > the one that complains that $8400 is already programmed. That tells me
> > that 000400 gets translated to 008400, which also supports the
> > S12FTS64KV1/D pdf file. :-b
> >
> > Is the P&E utility downloadable and free? The company I do work for has a
> > CyclonePro, but I do not.
>
> Have a look at www.pemicro.com . It should be free
I shall. Thanks.
> >> > I did convert the startup code and some parts of the code to ICC12 v7
> >> > (Std, handles a max of 64K Flash), but what little I have takes up
> >> > almost
> >> > all of flash without moving into page $3D, and I havent figured out how
> >> > to
> >> > do that yet. So moving to ICC would require moving to a HC9S12D256
> >> > chip
> >> > and upgrading to the more expensive ICC. ouch, new board and all.
> >>
> >>
> >> As far as I know, ICC12 V7 STD handles unlimited amount of nonpaged
> >> memory
> >> ($0..$FFFF) and max 64K of paged code (64K in routines callable using
> >> CALL
> >> instructions). STD should handle all available D64 memory and even 3/4 of
> >> D128 flash.
> >
> > Now if I ONLY knew how to do paged stuff in ICC, I'd be set. :-)
>
> In compiler options dialog check Enable Expanded Memory. Also check Make
> Paged Functions Default. If you don't want all functions to be paged or
> nonpaged, to force specific functions to be paged/nonpaged, use pragmas like
> this:
>
> #pragma paged_function foo1 // foo1() will be paged
> foo1()
> {
> }
>
> #pragma nonpaged_function foo2 // foo2() will be forced nonpaged
> foo2()
> {
> }
This has now been kept as a text file in my ICC12v7 directory and I'll try it as soon as my ASM stuff is working...
Edward, you are an excellent resource. Thank you!
> > I have no problem with using $4000-$DFFF, but no paging involved.
> > Got any suggestions as to how to do paged code in ICC to fix my ignernts?
> >
> >> >
> >> > wade
> >> >
> >> >
> >>
> >> Edward
> >> Edward
>
Reply by ●September 26, 20092009-09-26
This explanation doesn't directly help with this problem, but it gives you
some background and words to describe the addressing.
When EEPROMS and flash memory were in separate chips as in the 68HC12A4, the program files were written for separate device programmers that programmed the separate EEPROM.
For this they needed to use the addressing of the external EEPROM after translation by the HC12 memory control. This addressing is called "physical" and that is what you are reporting.
When HC12 parts with on-board flash arrived, this addressing continued to be used for the newer parts.
Eventually the compilers and flash programming methods went to the combination of the page register(s) values with the 16-bit address used by normal HC12 instructions. For reasons lost in history this addressing is called "linear" or "logical" in various documentation.
(I can't defend either name, but the names are what is in the documentation. It isn't exactly linear, there are big holes in it and some flash locations appear at two different addresses. It may have been "logical" to someone, but it seems to produce some pretty counter-intuitive results.)
In an attempt to sort this out the latest parts have "global" addressing, however the definition of "global" addressing is quite different in the MC9S12X* parts and the MC9S12P128.
Steve
--- In 6..., "warm38spl" wrote:
>
> I am working with a legacy program written in HC11 assembler and ported to HC9S12D64 assembler using MiniIDE and using TwinPeeks2.0 as the monitor residing at $F000-$FFFF.
>
> The program is growing and I need extra space in Flash. How do I program for and access PPAGE=$3D? Can this be done using MiniIDE and TwinPeeks?
>
> When MiniIDE detects ORG statement beyond FFFF it starts generating S2 records instead of S1 records. But when it does that, the pages get scrambled:
> 3C:8000 gets located at $0000
> 3D:8000 gets located at $4000
> 3E:8000 (normally $4000) gets located at $8000
> 3F:8000 (normally $C000) stays located at $C000
>
> TwinPeeks sees the S2 records and takes the address first byte as the page, but then addressing gets really strange, because all my accesses to $4000-7FFF and $C000-DFFF get lost in the translation
>
> And then there is the EEPROM scramble. EEPROM code programmed for $0400 now resides at $8400 which conflicts with the code that gets put into $8400 (which is what was supposed to be at $4400).
>
> Do I need to break the program up into multiple files, one for each page and one for EEPROM, and program them semarately via TwinPeeks?
>
> I did convert the startup code and some parts of the code to ICC12 v7 (Std, handles a max of 64K Flash), but what little I have takes up almost all of flash without moving into page $3D, and I havent figured out how to do that yet. So moving to ICC would require moving to a HC9S12D256 chip and upgrading to the more expensive ICC. ouch, new board and all.
>
> wade
>
When EEPROMS and flash memory were in separate chips as in the 68HC12A4, the program files were written for separate device programmers that programmed the separate EEPROM.
For this they needed to use the addressing of the external EEPROM after translation by the HC12 memory control. This addressing is called "physical" and that is what you are reporting.
When HC12 parts with on-board flash arrived, this addressing continued to be used for the newer parts.
Eventually the compilers and flash programming methods went to the combination of the page register(s) values with the 16-bit address used by normal HC12 instructions. For reasons lost in history this addressing is called "linear" or "logical" in various documentation.
(I can't defend either name, but the names are what is in the documentation. It isn't exactly linear, there are big holes in it and some flash locations appear at two different addresses. It may have been "logical" to someone, but it seems to produce some pretty counter-intuitive results.)
In an attempt to sort this out the latest parts have "global" addressing, however the definition of "global" addressing is quite different in the MC9S12X* parts and the MC9S12P128.
Steve
--- In 6..., "warm38spl" wrote:
>
> I am working with a legacy program written in HC11 assembler and ported to HC9S12D64 assembler using MiniIDE and using TwinPeeks2.0 as the monitor residing at $F000-$FFFF.
>
> The program is growing and I need extra space in Flash. How do I program for and access PPAGE=$3D? Can this be done using MiniIDE and TwinPeeks?
>
> When MiniIDE detects ORG statement beyond FFFF it starts generating S2 records instead of S1 records. But when it does that, the pages get scrambled:
> 3C:8000 gets located at $0000
> 3D:8000 gets located at $4000
> 3E:8000 (normally $4000) gets located at $8000
> 3F:8000 (normally $C000) stays located at $C000
>
> TwinPeeks sees the S2 records and takes the address first byte as the page, but then addressing gets really strange, because all my accesses to $4000-7FFF and $C000-DFFF get lost in the translation
>
> And then there is the EEPROM scramble. EEPROM code programmed for $0400 now resides at $8400 which conflicts with the code that gets put into $8400 (which is what was supposed to be at $4400).
>
> Do I need to break the program up into multiple files, one for each page and one for EEPROM, and program them semarately via TwinPeeks?
>
> I did convert the startup code and some parts of the code to ICC12 v7 (Std, handles a max of 64K Flash), but what little I have takes up almost all of flash without moving into page $3D, and I havent figured out how to do that yet. So moving to ICC would require moving to a HC9S12D256 chip and upgrading to the more expensive ICC. ouch, new board and all.
>
> wade
>
