Gilles,
Cheers for your service. I had been critical overnight of the Metrowerks
service pages, but as usual this forum has proved worth its weight. The
algorithm plugged in a ran nicely.
My alternate solution from last post last night didn't work and I had
resorted to copying the table with a runtime function into EEPROM when
it detected the EEPROM was erased.
Thanks again,
Jonathan.
-----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
Of Gilles Blanquin
Sent: Thursday, 15 September 2005 12:19 AM
To: 68HC12@68HC...
Subject: RE: [68HC12] Codewarrior programming EEPROM in S12DG128
Jonathan,
I propose you an alternate solution.
I send you offline a special driver for the MC9S12DG128.
Please install the driver in your CodeWarrior "prog\fpp" folder, after
backuping/renaming the original one.
This driver is actually available in this folder with the name:
Mcu03dc_EB386.fpp. I just send you the renamed driver.
Then make sure to have in your command files:
wb 0x10 0x39
wb 0x12 0x09
And in your .prm file:
EEPROM INTO READ_ONLY 0x800 TO 0xFFF;
The debugger is then compliant to the EB386 "Figure 7 Example 1
Layout".
Note that you can make this special driver selection from the Flash
dialog,
pressing the Browse button to select, for example, the
"Mcu03dc_EB386.fpp"
file, and unchecking the "auto select according to MCU-ID".
This setup is saved in your project.
Regards,
Gilles
At 01:56 PM 9/14/2005, you wrote:
>Gilles,
>
>I have read EB386 - thanks for the pointer, the mapping problem now
>makes sense.
>
>However I don't think the current setup will fix my problem. My OS
>resides at 0xc000-0xffff. The core services (ie those which are always
>installed are located at 0x4000-0x8000. The re-installable services
>(downloaded and re-flashable by my system) are in the pages at
>0x8000-0xBFFF. I don't have a lot of flexibility in this setup.
>
>Naturally with my OS fixed over the vectors, I have placed a secondary
>table in the EEPROM. Services can re-vector interrupts by asking the OS
>to reprogram the EEPROM.
>
>This all works fine in DP256 where 12K RAM can be placed neatly from
>0x1000 to 0x3FFF and the EEPROM is tucked in from 0x0400 to 0x0FFF.
>
>Now in the DG128, I can only put the RAM at 0x0000, 0x2000, 0x4000 etc.
>With the flash map being what it is, 0x2000 is my only choice and
EEPROM
>goes into 0x0800. With the restrictions the flash
programmer is putting
>on the system the problem is that the PRM files is putting EEPROM over
>the RAM needed to program it.
>
>I have worked out that I can place the EEPROM at 0x0800 in the PRM
file,
>copy it to 0xB000 using the burner.bbl script,
setup the INITEE address
>as 0xb000 in the reset and startup command files and burn the EEPROM
>this way. The startup code then moves the EEPROM back to 0x0800. The
>whole thing's a bit messy.
>
>Jonathan.
>
>-----Original Message-----
>From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
>Of Jonathan Masters
>Sent: Wednesday, 14 September 2005 8:02 PM
>To: 68HC12@68HC...
>Subject: RE: [68HC12] Codewarrior programming EEPROM in S12DG128
>
>Gilles,
>
>I still have one thing I don't understand. I have mapped ram to
>0x0800-0x27ff (8k bytes) using INITRM=0x08. EEPROM is mapped to 0x2800
>to 0x2fff using INITEE=0x29. Curiously however, RAM stops at 0x1fff.
The
>final 2K is missing, unwritable and only reading
0x00. Are there some
>special rules to the mapping registers I have misunderstood?
>
>Jonathan
>
>-----Original Message-----
>From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
>Of Gilles Blanquin
>Sent: Wednesday, 14 September 2005 7:38 PM
>To: 68HC12@68HC...
>Subject: RE: [68HC12] Codewarrior programming EEPROM in S12DG128
>
>Jonathan,
>
>as you noticed, the flash drivers/algorithms have been setup to be
>downloaded in 0x400-0x1FFF.
>If you move the RAM at reset via a "WB" command to change INITRM,
the
>driver cannot be loaded and the diagnostic fails.
>This is a known problem that has already been covered for the next
>CodeWarrior release which has PIC code drivers and special commands for
>drivers relocation.
>
>However, the current drivers limitation is not conflictual with any
>application relocating resources when starting/running. But please keep
>currently the RAM at default location for programming.
>
>Regards,
>Gilles
>
>At 11:12 AM 9/14/2005, you wrote:
> >Gilles,
> >
> >Thanks for your quick response. I figured out the .cmd files for the
> >reset and preload. Then I put the ram at 0x0800-0x27ff and the
EEPROM
> >from 0x2800 to 0x2fff. I found (as you have pointed out) that if the
>RAM
> >does not cover the 0x0800 space then I get error messages from the
> >debugger about being unable to load the diagnostic algorithm. I see
>that
> >if your programming code is at 0x0800 and is not PIC then any other
> >option is a problem ;(
> >
> >Jonathan.
> >
> >-----Original Message-----
> >From: 68HC12@68HC... [mailto:68HC12@68HC...] On
Behalf
> >Of Gilles Blanquin
> >Sent: Wednesday, 14 September 2005 6:19 PM
> >To: 68HC12@68HC...
> >Subject: RE: [68HC12] Codewarrior programming EEPROM in S12DG128
> >
> >Hi Jonathan.
> >
> >I presume your silicon is an MC9S12DG128(B).
> >Indeed, we had to "workaround" the fact that the EEPROM is
below the
> >Registers and Ram blocks.
> >The Flash Programmer relocates automatically the EEPROM via INITEE
real
> >time change, when checking/programming, to
address 0x2000. This is
only
> >done if INITEE is 0x01, default value. If
changed by the user to
>another
> >
> >value, the user relocation is taken in account.
> >(*) To verify this, after starting a project on hardware, reset the
> >debugger and open the Flash dialog (in ICD-12 menu). You should see
the
> >current location of the EEPROM.
> >
> >So to program it, define in your .prm the EEPROM at 0x2000.
> >
> >As you already defined for your application the RAM at 0x2000, it is
>not
> >
> >possible to take advantage of this automatic relocation. The Linker
> >won't
> >accept to have 2 overlapped segments.
> >
> >So I propose to set the EEPROM for programming to another unused
range,
> >for
> >example, commenting out "ROM_4000", that you can allocate via
ppage
>$3E.
> >
> >
> >in your .prm:
> >
> >
> >SEGMENTS
> > /* ROM_4000 = READ_ONLY 0x4000 TO 0x7FFF; */ /* also ppage $3E
*/
> >END
> >
> >PLACEMENT
> > EEPROM INTO READ_ONLY 0x4000 TO 0x47FF;
> >END
> >
> >
> >Then add the following command in your Startup and Reset project
>command
> >files:
> >
> >wb 0x12 0x41 /* moves the eeprom at 0x4000 */
> >The Flash Programmer will then care of the code "routed" to
the
> >0x4000-47FF.
> >To make sure about the EEPROM relocation, proceed again as described
at
> >"*"
> >here above.
> >
> >N.B. The application should care about all blocks location (INITRM,
> >INITRG,
> >INITEE) so there won't be any discrepancy at execution time (you
can
> >read
> >the EEPROM were you define it).
> >
> >
> >Regards,
> >Gilles
> >
> >
> >
> >At 08:29 AM 9/14/2005, you wrote:
> > >(This is probably a stupid question and there is probably a
clever
> > >answer)
> > >
> > >I have been programming a Codewarrior project into an DP256 for
some
> > >time. In an alternative product, a
similar project is being put
into
>a
> > >DG128. However I am struggling to understand how to locate the
>EEPROM.
> > >
> > >The DG128 EEPROM is located at 0x0000 - 0x07ff on reset and is
not
> > >visible. My EEPROM section in my PRM file is 0x800. How does
the
> > >debugger know that this is where I want the EEPROM mapped and
> > >programmed? This is a non issue with the DP256 as the EEPROM is
>mapped
> > >out of reset.
> > >
> > >At present, the EEPROM data is appearing in RAM since the RAM
is
>mapped
> > >to 0x0800 out of reset. My program remaps the ram to 0x2000.
> > >
> > >I feel the answer lies somewhere in the works of Codewarrior. I
hate
>to
> > >criticize documentation when I am new to a system, but I have
been
> >using
> > >CodeWarrior for over two years in one form or another and still
find
> >the
> > >helpfiles a waste of disk space.
> > >
> > >Jonathan Masters
> > >JEMTECH Pty Ltd
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >> Terms of Service.
> >
> > _____
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >> Terms of Service.
>
> _____
>
>
>SPONSORED LINKS
>
>Freescale
><http://groups.yahoo.com/gads?t=ms
<http://groups.yahoo.com/gads?t=ms&k=Freescale+semiconductor+inc&w1=Free
> &k=Freescale+semiconductor+inc&w1=Free
>scale+semiconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w4=
8
>051+microprocessor&c=4&s6&.sig=K2HGv-zFlv5OYUv_QxIq_Q>
semiconductor
>inc
>Microcontrollers
><http://groups.yahoo.com/gads?t=ms
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Freescale+semic
> &k=Microcontrollers&w1=Freescale+semic
>onductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microp
r
>ocessor&c=4&s6&.sig=SYHwNJjjGQXRvtt_GybT4g>
>Pic
><http://groups.yahoo.com/gads?t=ms
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Freescale+s
> &k=Pic+microcontrollers&w1=Freescale+s
>emiconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+mi
c
>roprocessor&c=4&s6&.sig=umVbbnUwsPzEzKKD_pQfUw>
microcontrollers
>
>8051
><http://groups.yahoo.com/gads?t=ms
<http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Freescale+se
> &k51+microprocessor&w1=Freescale+se
>miconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+mic
r
>oprocessor&c=4&s6&.sig=NO-nSKjHoAlh9XtZ8LB1_A>
microprocessor
>
> _____
>
>> Terms of Service.
>
> _____
>
>> Terms of Service.
_____
Re: Codewarrior programming EEPROM in S12DG128
Started by ●December 9, 2004
Reply by ●September 14, 20052005-09-14
Hello all,
We are using S12DJ64 in an automotive application and I'd like to know how
many cycles of R/W we can do in EEPROM?
Regards
Erwan
We are using S12DJ64 in an automotive application and I'd like to know how
many cycles of R/W we can do in EEPROM?
Regards
Erwan
Reply by ●September 14, 20052005-09-14
Erwan,
This information is specified in table A-12 of the S12DJ64 device
user-guide on page 103. The link to the document is:
http://www.freescale.com/files/microcontrollers/doc/data_sheet/9S12DJ64DGV1.pdf
The maximum number of EEPROM Erase/Program cycles depend on the temperature.
At temperatures above 0C it is 100,000 cycles minimum.
At temperatures below 0c, it drops to 10,000 cycles minimum.
For the Flash, it is defined as 10,000 cycles minimum in all temperatures.
Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
At 08:11 14/09/2005 +0200, you wrote:
>Hello all,
>
>We are using S12DJ64 in an automotive application and I'd like to know how
>many cycles of R/W we can do in EEPROM?
>
>Regards
>
>Erwan
This information is specified in table A-12 of the S12DJ64 device
user-guide on page 103. The link to the document is:
http://www.freescale.com/files/microcontrollers/doc/data_sheet/9S12DJ64DGV1.pdf
The maximum number of EEPROM Erase/Program cycles depend on the temperature.
At temperatures above 0C it is 100,000 cycles minimum.
At temperatures below 0c, it drops to 10,000 cycles minimum.
For the Flash, it is defined as 10,000 cycles minimum in all temperatures.
Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
At 08:11 14/09/2005 +0200, you wrote:
>Hello all,
>
>We are using S12DJ64 in an automotive application and I'd like to know how
>many cycles of R/W we can do in EEPROM?
>
>Regards
>
>Erwan
Reply by ●September 14, 20052005-09-14
(This is probably a stupid question and there is probably a clever
answer)
I have been programming a Codewarrior project into an DP256 for some
time. In an alternative product, a similar project is being put into a
DG128. However I am struggling to understand how to locate the EEPROM.
The DG128 EEPROM is located at 0x0000 - 0x07ff on reset and is not
visible. My EEPROM section in my PRM file is 0x800. How does the
debugger know that this is where I want the EEPROM mapped and
programmed? This is a non issue with the DP256 as the EEPROM is mapped
out of reset.
At present, the EEPROM data is appearing in RAM since the RAM is mapped
to 0x0800 out of reset. My program remaps the ram to 0x2000.
I feel the answer lies somewhere in the works of Codewarrior. I hate to
criticize documentation when I am new to a system, but I have been using
CodeWarrior for over two years in one form or another and still find the
helpfiles a waste of disk space.
Jonathan Masters
JEMTECH Pty Ltd
answer)
I have been programming a Codewarrior project into an DP256 for some
time. In an alternative product, a similar project is being put into a
DG128. However I am struggling to understand how to locate the EEPROM.
The DG128 EEPROM is located at 0x0000 - 0x07ff on reset and is not
visible. My EEPROM section in my PRM file is 0x800. How does the
debugger know that this is where I want the EEPROM mapped and
programmed? This is a non issue with the DP256 as the EEPROM is mapped
out of reset.
At present, the EEPROM data is appearing in RAM since the RAM is mapped
to 0x0800 out of reset. My program remaps the ram to 0x2000.
I feel the answer lies somewhere in the works of Codewarrior. I hate to
criticize documentation when I am new to a system, but I have been using
CodeWarrior for over two years in one form or another and still find the
helpfiles a waste of disk space.
Jonathan Masters
JEMTECH Pty Ltd
Reply by ●September 14, 20052005-09-14
Hi Jonathan.
I presume your silicon is an MC9S12DG128(B).
Indeed, we had to "workaround" the fact that the EEPROM is below the
Registers and Ram blocks.
The Flash Programmer relocates automatically the EEPROM via INITEE real
time change, when checking/programming, to address 0x2000. This is only
done if INITEE is 0x01, default value. If changed by the user to another
value, the user relocation is taken in account.
(*) To verify this, after starting a project on hardware, reset the
debugger and open the Flash dialog (in ICD-12 menu). You should see the
current location of the EEPROM.
So to program it, define in your .prm the EEPROM at 0x2000.
As you already defined for your application the RAM at 0x2000, it is not
possible to take advantage of this automatic relocation. The Linker won't
accept to have 2 overlapped segments.
So I propose to set the EEPROM for programming to another unused range, for
example, commenting out "ROM_4000", that you can allocate via ppage $3E. in your .prm: SEGMENTS
/* ROM_4000 = READ_ONLY 0x4000 TO 0x7FFF; */ /* also ppage $3E */
END
PLACEMENT
EEPROM INTO READ_ONLY 0x4000 TO 0x47FF;
END Then add the following command in your Startup and Reset project command files:
wb 0x12 0x41 /* moves the eeprom at 0x4000 */
The Flash Programmer will then care of the code "routed" to the 0x4000-47FF.
To make sure about the EEPROM relocation, proceed again as described at "*"
here above.
N.B. The application should care about all blocks location (INITRM, INITRG,
INITEE) so there won't be any discrepancy at execution time (you can read
the EEPROM were you define it). Regards,
Gilles
At 08:29 AM 9/14/2005, you wrote:
>(This is probably a stupid question and there is probably a clever
>answer)
>
>I have been programming a Codewarrior project into an DP256 for some
>time. In an alternative product, a similar project is being put into a
>DG128. However I am struggling to understand how to locate the EEPROM.
>
>The DG128 EEPROM is located at 0x0000 - 0x07ff on reset and is not
>visible. My EEPROM section in my PRM file is 0x800. How does the
>debugger know that this is where I want the EEPROM mapped and
>programmed? This is a non issue with the DP256 as the EEPROM is mapped
>out of reset.
>
>At present, the EEPROM data is appearing in RAM since the RAM is mapped
>to 0x0800 out of reset. My program remaps the ram to 0x2000.
>
>I feel the answer lies somewhere in the works of Codewarrior. I hate to
>criticize documentation when I am new to a system, but I have been using
>CodeWarrior for over two years in one form or another and still find the
>helpfiles a waste of disk space.
>
>Jonathan Masters
>JEMTECH Pty Ltd >
>Yahoo! Groups Links >
>
I presume your silicon is an MC9S12DG128(B).
Indeed, we had to "workaround" the fact that the EEPROM is below the
Registers and Ram blocks.
The Flash Programmer relocates automatically the EEPROM via INITEE real
time change, when checking/programming, to address 0x2000. This is only
done if INITEE is 0x01, default value. If changed by the user to another
value, the user relocation is taken in account.
(*) To verify this, after starting a project on hardware, reset the
debugger and open the Flash dialog (in ICD-12 menu). You should see the
current location of the EEPROM.
So to program it, define in your .prm the EEPROM at 0x2000.
As you already defined for your application the RAM at 0x2000, it is not
possible to take advantage of this automatic relocation. The Linker won't
accept to have 2 overlapped segments.
So I propose to set the EEPROM for programming to another unused range, for
example, commenting out "ROM_4000", that you can allocate via ppage $3E. in your .prm: SEGMENTS
/* ROM_4000 = READ_ONLY 0x4000 TO 0x7FFF; */ /* also ppage $3E */
END
PLACEMENT
EEPROM INTO READ_ONLY 0x4000 TO 0x47FF;
END Then add the following command in your Startup and Reset project command files:
wb 0x12 0x41 /* moves the eeprom at 0x4000 */
The Flash Programmer will then care of the code "routed" to the 0x4000-47FF.
To make sure about the EEPROM relocation, proceed again as described at "*"
here above.
N.B. The application should care about all blocks location (INITRM, INITRG,
INITEE) so there won't be any discrepancy at execution time (you can read
the EEPROM were you define it). Regards,
Gilles
At 08:29 AM 9/14/2005, you wrote:
>(This is probably a stupid question and there is probably a clever
>answer)
>
>I have been programming a Codewarrior project into an DP256 for some
>time. In an alternative product, a similar project is being put into a
>DG128. However I am struggling to understand how to locate the EEPROM.
>
>The DG128 EEPROM is located at 0x0000 - 0x07ff on reset and is not
>visible. My EEPROM section in my PRM file is 0x800. How does the
>debugger know that this is where I want the EEPROM mapped and
>programmed? This is a non issue with the DP256 as the EEPROM is mapped
>out of reset.
>
>At present, the EEPROM data is appearing in RAM since the RAM is mapped
>to 0x0800 out of reset. My program remaps the ram to 0x2000.
>
>I feel the answer lies somewhere in the works of Codewarrior. I hate to
>criticize documentation when I am new to a system, but I have been using
>CodeWarrior for over two years in one form or another and still find the
>helpfiles a waste of disk space.
>
>Jonathan Masters
>JEMTECH Pty Ltd >
>Yahoo! Groups Links >
>
Reply by ●September 14, 20052005-09-14
Gilles,
Thanks for your quick response. I figured out the .cmd files for the
reset and preload. Then I put the ram at 0x0800-0x27ff and the EEPROM
from 0x2800 to 0x2fff. I found (as you have pointed out) that if the RAM
does not cover the 0x0800 space then I get error messages from the
debugger about being unable to load the diagnostic algorithm. I see that
if your programming code is at 0x0800 and is not PIC then any other
option is a problem ;(
Jonathan.
-----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
Of Gilles Blanquin
Sent: Wednesday, 14 September 2005 6:19 PM
To: 68HC12@68HC...
Subject: RE: [68HC12] Codewarrior programming EEPROM in S12DG128
Hi Jonathan.
I presume your silicon is an MC9S12DG128(B).
Indeed, we had to "workaround" the fact that the EEPROM is below the
Registers and Ram blocks.
The Flash Programmer relocates automatically the EEPROM via INITEE real
time change, when checking/programming, to address 0x2000. This is only
done if INITEE is 0x01, default value. If changed by the user to another
value, the user relocation is taken in account.
(*) To verify this, after starting a project on hardware, reset the
debugger and open the Flash dialog (in ICD-12 menu). You should see the
current location of the EEPROM.
So to program it, define in your .prm the EEPROM at 0x2000.
As you already defined for your application the RAM at 0x2000, it is not
possible to take advantage of this automatic relocation. The Linker
won't
accept to have 2 overlapped segments.
So I propose to set the EEPROM for programming to another unused range,
for
example, commenting out "ROM_4000", that you can allocate via ppage $3E. in your .prm: SEGMENTS
/* ROM_4000 = READ_ONLY 0x4000 TO 0x7FFF; */ /* also ppage $3E */
END
PLACEMENT
EEPROM INTO READ_ONLY 0x4000 TO 0x47FF;
END Then add the following command in your Startup and Reset project command
files:
wb 0x12 0x41 /* moves the eeprom at 0x4000 */
The Flash Programmer will then care of the code "routed" to the
0x4000-47FF.
To make sure about the EEPROM relocation, proceed again as described at
"*"
here above.
N.B. The application should care about all blocks location (INITRM,
INITRG,
INITEE) so there won't be any discrepancy at execution time (you can
read
the EEPROM were you define it). Regards,
Gilles
At 08:29 AM 9/14/2005, you wrote:
>(This is probably a stupid question and there is probably a clever
>answer)
>
>I have been programming a Codewarrior project into an DP256 for some
>time. In an alternative product, a similar project is being put into a
>DG128. However I am struggling to understand how to locate the EEPROM.
>
>The DG128 EEPROM is located at 0x0000 - 0x07ff on reset and is not
>visible. My EEPROM section in my PRM file is 0x800. How does the
>debugger know that this is where I want the EEPROM mapped and
>programmed? This is a non issue with the DP256 as the EEPROM is mapped
>out of reset.
>
>At present, the EEPROM data is appearing in RAM since the RAM is mapped
>to 0x0800 out of reset. My program remaps the ram to 0x2000.
>
>I feel the answer lies somewhere in the works of Codewarrior. I hate to
>criticize documentation when I am new to a system, but I have been
using
>CodeWarrior for over two years in one form or another and still find
the
>helpfiles a waste of disk space.
>
>Jonathan Masters
>JEMTECH Pty Ltd >
>> Terms of Service.
_____
Thanks for your quick response. I figured out the .cmd files for the
reset and preload. Then I put the ram at 0x0800-0x27ff and the EEPROM
from 0x2800 to 0x2fff. I found (as you have pointed out) that if the RAM
does not cover the 0x0800 space then I get error messages from the
debugger about being unable to load the diagnostic algorithm. I see that
if your programming code is at 0x0800 and is not PIC then any other
option is a problem ;(
Jonathan.
-----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
Of Gilles Blanquin
Sent: Wednesday, 14 September 2005 6:19 PM
To: 68HC12@68HC...
Subject: RE: [68HC12] Codewarrior programming EEPROM in S12DG128
Hi Jonathan.
I presume your silicon is an MC9S12DG128(B).
Indeed, we had to "workaround" the fact that the EEPROM is below the
Registers and Ram blocks.
The Flash Programmer relocates automatically the EEPROM via INITEE real
time change, when checking/programming, to address 0x2000. This is only
done if INITEE is 0x01, default value. If changed by the user to another
value, the user relocation is taken in account.
(*) To verify this, after starting a project on hardware, reset the
debugger and open the Flash dialog (in ICD-12 menu). You should see the
current location of the EEPROM.
So to program it, define in your .prm the EEPROM at 0x2000.
As you already defined for your application the RAM at 0x2000, it is not
possible to take advantage of this automatic relocation. The Linker
won't
accept to have 2 overlapped segments.
So I propose to set the EEPROM for programming to another unused range,
for
example, commenting out "ROM_4000", that you can allocate via ppage $3E. in your .prm: SEGMENTS
/* ROM_4000 = READ_ONLY 0x4000 TO 0x7FFF; */ /* also ppage $3E */
END
PLACEMENT
EEPROM INTO READ_ONLY 0x4000 TO 0x47FF;
END Then add the following command in your Startup and Reset project command
files:
wb 0x12 0x41 /* moves the eeprom at 0x4000 */
The Flash Programmer will then care of the code "routed" to the
0x4000-47FF.
To make sure about the EEPROM relocation, proceed again as described at
"*"
here above.
N.B. The application should care about all blocks location (INITRM,
INITRG,
INITEE) so there won't be any discrepancy at execution time (you can
read
the EEPROM were you define it). Regards,
Gilles
At 08:29 AM 9/14/2005, you wrote:
>(This is probably a stupid question and there is probably a clever
>answer)
>
>I have been programming a Codewarrior project into an DP256 for some
>time. In an alternative product, a similar project is being put into a
>DG128. However I am struggling to understand how to locate the EEPROM.
>
>The DG128 EEPROM is located at 0x0000 - 0x07ff on reset and is not
>visible. My EEPROM section in my PRM file is 0x800. How does the
>debugger know that this is where I want the EEPROM mapped and
>programmed? This is a non issue with the DP256 as the EEPROM is mapped
>out of reset.
>
>At present, the EEPROM data is appearing in RAM since the RAM is mapped
>to 0x0800 out of reset. My program remaps the ram to 0x2000.
>
>I feel the answer lies somewhere in the works of Codewarrior. I hate to
>criticize documentation when I am new to a system, but I have been
using
>CodeWarrior for over two years in one form or another and still find
the
>helpfiles a waste of disk space.
>
>Jonathan Masters
>JEMTECH Pty Ltd >
>> Terms of Service.
_____
Reply by ●September 14, 20052005-09-14
Jonathan,
as you noticed, the flash drivers/algorithms have been setup to be
downloaded in 0x400-0x1FFF.
If you move the RAM at reset via a "WB" command to change INITRM, the
driver cannot be loaded and the diagnostic fails.
This is a known problem that has already been covered for the next
CodeWarrior release which has PIC code drivers and special commands for
drivers relocation.
However, the current drivers limitation is not conflictual with any
application relocating resources when starting/running. But please keep
currently the RAM at default location for programming.
Regards,
Gilles
At 11:12 AM 9/14/2005, you wrote:
>Gilles,
>
>Thanks for your quick response. I figured out the .cmd files for the
>reset and preload. Then I put the ram at 0x0800-0x27ff and the EEPROM
>from 0x2800 to 0x2fff. I found (as you have pointed out) that if the RAM
>does not cover the 0x0800 space then I get error messages from the
>debugger about being unable to load the diagnostic algorithm. I see that
>if your programming code is at 0x0800 and is not PIC then any other
>option is a problem ;(
>
>Jonathan.
>
>-----Original Message-----
>From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
>Of Gilles Blanquin
>Sent: Wednesday, 14 September 2005 6:19 PM
>To: 68HC12@68HC...
>Subject: RE: [68HC12] Codewarrior programming EEPROM in S12DG128
>
>Hi Jonathan.
>
>I presume your silicon is an MC9S12DG128(B).
>Indeed, we had to "workaround" the fact that the EEPROM is below the
>Registers and Ram blocks.
>The Flash Programmer relocates automatically the EEPROM via INITEE real
>time change, when checking/programming, to address 0x2000. This is only
>done if INITEE is 0x01, default value. If changed by the user to another
>
>value, the user relocation is taken in account.
>(*) To verify this, after starting a project on hardware, reset the
>debugger and open the Flash dialog (in ICD-12 menu). You should see the
>current location of the EEPROM.
>
>So to program it, define in your .prm the EEPROM at 0x2000.
>
>As you already defined for your application the RAM at 0x2000, it is not
>
>possible to take advantage of this automatic relocation. The Linker
>won't
>accept to have 2 overlapped segments.
>
>So I propose to set the EEPROM for programming to another unused range,
>for
>example, commenting out "ROM_4000", that you can allocate via ppage $3E. >in your .prm: >SEGMENTS
> /* ROM_4000 = READ_ONLY 0x4000 TO 0x7FFF; */ /* also ppage $3E */
>END
>
>PLACEMENT
> EEPROM INTO READ_ONLY 0x4000 TO 0x47FF;
>END >Then add the following command in your Startup and Reset project command
>files:
>
>wb 0x12 0x41 /* moves the eeprom at 0x4000 */
>The Flash Programmer will then care of the code "routed" to the
>0x4000-47FF.
>To make sure about the EEPROM relocation, proceed again as described at
>"*"
>here above.
>
>N.B. The application should care about all blocks location (INITRM,
>INITRG,
>INITEE) so there won't be any discrepancy at execution time (you can
>read
>the EEPROM were you define it). >Regards,
>Gilles >
>At 08:29 AM 9/14/2005, you wrote:
> >(This is probably a stupid question and there is probably a clever
> >answer)
> >
> >I have been programming a Codewarrior project into an DP256 for some
> >time. In an alternative product, a similar project is being put into a
> >DG128. However I am struggling to understand how to locate the EEPROM.
> >
> >The DG128 EEPROM is located at 0x0000 - 0x07ff on reset and is not
> >visible. My EEPROM section in my PRM file is 0x800. How does the
> >debugger know that this is where I want the EEPROM mapped and
> >programmed? This is a non issue with the DP256 as the EEPROM is mapped
> >out of reset.
> >
> >At present, the EEPROM data is appearing in RAM since the RAM is mapped
> >to 0x0800 out of reset. My program remaps the ram to 0x2000.
> >
> >I feel the answer lies somewhere in the works of Codewarrior. I hate to
> >criticize documentation when I am new to a system, but I have been
>using
> >CodeWarrior for over two years in one form or another and still find
>the
> >helpfiles a waste of disk space.
> >
> >Jonathan Masters
> >JEMTECH Pty Ltd
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >> Terms of Service.
>
> _____ >
>Yahoo! Groups Links >
>
as you noticed, the flash drivers/algorithms have been setup to be
downloaded in 0x400-0x1FFF.
If you move the RAM at reset via a "WB" command to change INITRM, the
driver cannot be loaded and the diagnostic fails.
This is a known problem that has already been covered for the next
CodeWarrior release which has PIC code drivers and special commands for
drivers relocation.
However, the current drivers limitation is not conflictual with any
application relocating resources when starting/running. But please keep
currently the RAM at default location for programming.
Regards,
Gilles
At 11:12 AM 9/14/2005, you wrote:
>Gilles,
>
>Thanks for your quick response. I figured out the .cmd files for the
>reset and preload. Then I put the ram at 0x0800-0x27ff and the EEPROM
>from 0x2800 to 0x2fff. I found (as you have pointed out) that if the RAM
>does not cover the 0x0800 space then I get error messages from the
>debugger about being unable to load the diagnostic algorithm. I see that
>if your programming code is at 0x0800 and is not PIC then any other
>option is a problem ;(
>
>Jonathan.
>
>-----Original Message-----
>From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
>Of Gilles Blanquin
>Sent: Wednesday, 14 September 2005 6:19 PM
>To: 68HC12@68HC...
>Subject: RE: [68HC12] Codewarrior programming EEPROM in S12DG128
>
>Hi Jonathan.
>
>I presume your silicon is an MC9S12DG128(B).
>Indeed, we had to "workaround" the fact that the EEPROM is below the
>Registers and Ram blocks.
>The Flash Programmer relocates automatically the EEPROM via INITEE real
>time change, when checking/programming, to address 0x2000. This is only
>done if INITEE is 0x01, default value. If changed by the user to another
>
>value, the user relocation is taken in account.
>(*) To verify this, after starting a project on hardware, reset the
>debugger and open the Flash dialog (in ICD-12 menu). You should see the
>current location of the EEPROM.
>
>So to program it, define in your .prm the EEPROM at 0x2000.
>
>As you already defined for your application the RAM at 0x2000, it is not
>
>possible to take advantage of this automatic relocation. The Linker
>won't
>accept to have 2 overlapped segments.
>
>So I propose to set the EEPROM for programming to another unused range,
>for
>example, commenting out "ROM_4000", that you can allocate via ppage $3E. >in your .prm: >SEGMENTS
> /* ROM_4000 = READ_ONLY 0x4000 TO 0x7FFF; */ /* also ppage $3E */
>END
>
>PLACEMENT
> EEPROM INTO READ_ONLY 0x4000 TO 0x47FF;
>END >Then add the following command in your Startup and Reset project command
>files:
>
>wb 0x12 0x41 /* moves the eeprom at 0x4000 */
>The Flash Programmer will then care of the code "routed" to the
>0x4000-47FF.
>To make sure about the EEPROM relocation, proceed again as described at
>"*"
>here above.
>
>N.B. The application should care about all blocks location (INITRM,
>INITRG,
>INITEE) so there won't be any discrepancy at execution time (you can
>read
>the EEPROM were you define it). >Regards,
>Gilles >
>At 08:29 AM 9/14/2005, you wrote:
> >(This is probably a stupid question and there is probably a clever
> >answer)
> >
> >I have been programming a Codewarrior project into an DP256 for some
> >time. In an alternative product, a similar project is being put into a
> >DG128. However I am struggling to understand how to locate the EEPROM.
> >
> >The DG128 EEPROM is located at 0x0000 - 0x07ff on reset and is not
> >visible. My EEPROM section in my PRM file is 0x800. How does the
> >debugger know that this is where I want the EEPROM mapped and
> >programmed? This is a non issue with the DP256 as the EEPROM is mapped
> >out of reset.
> >
> >At present, the EEPROM data is appearing in RAM since the RAM is mapped
> >to 0x0800 out of reset. My program remaps the ram to 0x2000.
> >
> >I feel the answer lies somewhere in the works of Codewarrior. I hate to
> >criticize documentation when I am new to a system, but I have been
>using
> >CodeWarrior for over two years in one form or another and still find
>the
> >helpfiles a waste of disk space.
> >
> >Jonathan Masters
> >JEMTECH Pty Ltd
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >> Terms of Service.
>
> _____ >
>Yahoo! Groups Links >
>
Reply by ●September 14, 20052005-09-14
Gilles
That's cool. My main problem has been with the amount of work needed to
figure out the whole mechanism that the IDE/Debugger combo uses. The
documentation in the help files is very generic and the PDF files in the
manuals section are quite general. To be truthful I didn't even find the
PDF files until relatively late in the process.
Jonathan.
-----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
Of Gilles Blanquin
Sent: Wednesday, 14 September 2005 7:38 PM
To: 68HC12@68HC...
Subject: RE: [68HC12] Codewarrior programming EEPROM in S12DG128
Jonathan,
as you noticed, the flash drivers/algorithms have been setup to be
downloaded in 0x400-0x1FFF.
If you move the RAM at reset via a "WB" command to change INITRM, the
driver cannot be loaded and the diagnostic fails.
This is a known problem that has already been covered for the next
CodeWarrior release which has PIC code drivers and special commands for
drivers relocation.
However, the current drivers limitation is not conflictual with any
application relocating resources when starting/running. But please keep
currently the RAM at default location for programming.
Regards,
Gilles
At 11:12 AM 9/14/2005, you wrote:
>Gilles,
>
>Thanks for your quick response. I figured out the .cmd files for the
>reset and preload. Then I put the ram at 0x0800-0x27ff and the EEPROM
>from 0x2800 to 0x2fff. I found (as you have pointed out) that if the
RAM
>does not cover the 0x0800 space then I get error messages from the
>debugger about being unable to load the diagnostic algorithm. I see
that
>if your programming code is at 0x0800 and is not PIC then any other
>option is a problem ;(
>
>Jonathan.
>
>-----Original Message-----
>From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
>Of Gilles Blanquin
>Sent: Wednesday, 14 September 2005 6:19 PM
>To: 68HC12@68HC...
>Subject: RE: [68HC12] Codewarrior programming EEPROM in S12DG128
>
>Hi Jonathan.
>
>I presume your silicon is an MC9S12DG128(B).
>Indeed, we had to "workaround" the fact that the EEPROM is below the
>Registers and Ram blocks.
>The Flash Programmer relocates automatically the EEPROM via INITEE real
>time change, when checking/programming, to address 0x2000. This is only
>done if INITEE is 0x01, default value. If changed by the user to
another
>
>value, the user relocation is taken in account.
>(*) To verify this, after starting a project on hardware, reset the
>debugger and open the Flash dialog (in ICD-12 menu). You should see the
>current location of the EEPROM.
>
>So to program it, define in your .prm the EEPROM at 0x2000.
>
>As you already defined for your application the RAM at 0x2000, it is
not
>
>possible to take advantage of this automatic relocation. The Linker
>won't
>accept to have 2 overlapped segments.
>
>So I propose to set the EEPROM for programming to another unused range,
>for
>example, commenting out "ROM_4000", that you can allocate via ppage
$3E.
>
>
>in your .prm: >SEGMENTS
> /* ROM_4000 = READ_ONLY 0x4000 TO 0x7FFF; */ /* also ppage $3E */
>END
>
>PLACEMENT
> EEPROM INTO READ_ONLY 0x4000 TO 0x47FF;
>END >Then add the following command in your Startup and Reset project
command
>files:
>
>wb 0x12 0x41 /* moves the eeprom at 0x4000 */
>The Flash Programmer will then care of the code "routed" to the
>0x4000-47FF.
>To make sure about the EEPROM relocation, proceed again as described at
>"*"
>here above.
>
>N.B. The application should care about all blocks location (INITRM,
>INITRG,
>INITEE) so there won't be any discrepancy at execution time (you can
>read
>the EEPROM were you define it). >Regards,
>Gilles >
>At 08:29 AM 9/14/2005, you wrote:
> >(This is probably a stupid question and there is probably a clever
> >answer)
> >
> >I have been programming a Codewarrior project into an DP256 for some
> >time. In an alternative product, a similar project is being put into
a
> >DG128. However I am struggling to understand how to locate the
EEPROM.
> >
> >The DG128 EEPROM is located at 0x0000 - 0x07ff on reset and is not
> >visible. My EEPROM section in my PRM file is 0x800. How does the
> >debugger know that this is where I want the EEPROM mapped and
> >programmed? This is a non issue with the DP256 as the EEPROM is
mapped
> >out of reset.
> >
> >At present, the EEPROM data is appearing in RAM since the RAM is
mapped
> >to 0x0800 out of reset. My program remaps the ram to 0x2000.
> >
> >I feel the answer lies somewhere in the works of Codewarrior. I hate
to
> >criticize documentation when I am new to a system, but I have been
>using
> >CodeWarrior for over two years in one form or another and still find
>the
> >helpfiles a waste of disk space.
> >
> >Jonathan Masters
> >JEMTECH Pty Ltd
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >> Terms of Service.
>
> _____ >
>> Terms of Service.
_____
That's cool. My main problem has been with the amount of work needed to
figure out the whole mechanism that the IDE/Debugger combo uses. The
documentation in the help files is very generic and the PDF files in the
manuals section are quite general. To be truthful I didn't even find the
PDF files until relatively late in the process.
Jonathan.
-----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
Of Gilles Blanquin
Sent: Wednesday, 14 September 2005 7:38 PM
To: 68HC12@68HC...
Subject: RE: [68HC12] Codewarrior programming EEPROM in S12DG128
Jonathan,
as you noticed, the flash drivers/algorithms have been setup to be
downloaded in 0x400-0x1FFF.
If you move the RAM at reset via a "WB" command to change INITRM, the
driver cannot be loaded and the diagnostic fails.
This is a known problem that has already been covered for the next
CodeWarrior release which has PIC code drivers and special commands for
drivers relocation.
However, the current drivers limitation is not conflictual with any
application relocating resources when starting/running. But please keep
currently the RAM at default location for programming.
Regards,
Gilles
At 11:12 AM 9/14/2005, you wrote:
>Gilles,
>
>Thanks for your quick response. I figured out the .cmd files for the
>reset and preload. Then I put the ram at 0x0800-0x27ff and the EEPROM
>from 0x2800 to 0x2fff. I found (as you have pointed out) that if the
RAM
>does not cover the 0x0800 space then I get error messages from the
>debugger about being unable to load the diagnostic algorithm. I see
that
>if your programming code is at 0x0800 and is not PIC then any other
>option is a problem ;(
>
>Jonathan.
>
>-----Original Message-----
>From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
>Of Gilles Blanquin
>Sent: Wednesday, 14 September 2005 6:19 PM
>To: 68HC12@68HC...
>Subject: RE: [68HC12] Codewarrior programming EEPROM in S12DG128
>
>Hi Jonathan.
>
>I presume your silicon is an MC9S12DG128(B).
>Indeed, we had to "workaround" the fact that the EEPROM is below the
>Registers and Ram blocks.
>The Flash Programmer relocates automatically the EEPROM via INITEE real
>time change, when checking/programming, to address 0x2000. This is only
>done if INITEE is 0x01, default value. If changed by the user to
another
>
>value, the user relocation is taken in account.
>(*) To verify this, after starting a project on hardware, reset the
>debugger and open the Flash dialog (in ICD-12 menu). You should see the
>current location of the EEPROM.
>
>So to program it, define in your .prm the EEPROM at 0x2000.
>
>As you already defined for your application the RAM at 0x2000, it is
not
>
>possible to take advantage of this automatic relocation. The Linker
>won't
>accept to have 2 overlapped segments.
>
>So I propose to set the EEPROM for programming to another unused range,
>for
>example, commenting out "ROM_4000", that you can allocate via ppage
$3E.
>
>
>in your .prm: >SEGMENTS
> /* ROM_4000 = READ_ONLY 0x4000 TO 0x7FFF; */ /* also ppage $3E */
>END
>
>PLACEMENT
> EEPROM INTO READ_ONLY 0x4000 TO 0x47FF;
>END >Then add the following command in your Startup and Reset project
command
>files:
>
>wb 0x12 0x41 /* moves the eeprom at 0x4000 */
>The Flash Programmer will then care of the code "routed" to the
>0x4000-47FF.
>To make sure about the EEPROM relocation, proceed again as described at
>"*"
>here above.
>
>N.B. The application should care about all blocks location (INITRM,
>INITRG,
>INITEE) so there won't be any discrepancy at execution time (you can
>read
>the EEPROM were you define it). >Regards,
>Gilles >
>At 08:29 AM 9/14/2005, you wrote:
> >(This is probably a stupid question and there is probably a clever
> >answer)
> >
> >I have been programming a Codewarrior project into an DP256 for some
> >time. In an alternative product, a similar project is being put into
a
> >DG128. However I am struggling to understand how to locate the
EEPROM.
> >
> >The DG128 EEPROM is located at 0x0000 - 0x07ff on reset and is not
> >visible. My EEPROM section in my PRM file is 0x800. How does the
> >debugger know that this is where I want the EEPROM mapped and
> >programmed? This is a non issue with the DP256 as the EEPROM is
mapped
> >out of reset.
> >
> >At present, the EEPROM data is appearing in RAM since the RAM is
mapped
> >to 0x0800 out of reset. My program remaps the ram to 0x2000.
> >
> >I feel the answer lies somewhere in the works of Codewarrior. I hate
to
> >criticize documentation when I am new to a system, but I have been
>using
> >CodeWarrior for over two years in one form or another and still find
>the
> >helpfiles a waste of disk space.
> >
> >Jonathan Masters
> >JEMTECH Pty Ltd
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >> Terms of Service.
>
> _____ >
>> Terms of Service.
_____
Reply by ●September 14, 20052005-09-14
Gilles,
I still have one thing I don't understand. I have mapped ram to
0x0800-0x27ff (8k bytes) using INITRM=0x08. EEPROM is mapped to 0x2800
to 0x2fff using INITEE=0x29. Curiously however, RAM stops at 0x1fff. The
final 2K is missing, unwritable and only reading 0x00. Are there some
special rules to the mapping registers I have misunderstood?
Jonathan
-----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
Of Gilles Blanquin
Sent: Wednesday, 14 September 2005 7:38 PM
To: 68HC12@68HC...
Subject: RE: [68HC12] Codewarrior programming EEPROM in S12DG128
Jonathan,
as you noticed, the flash drivers/algorithms have been setup to be
downloaded in 0x400-0x1FFF.
If you move the RAM at reset via a "WB" command to change INITRM, the
driver cannot be loaded and the diagnostic fails.
This is a known problem that has already been covered for the next
CodeWarrior release which has PIC code drivers and special commands for
drivers relocation.
However, the current drivers limitation is not conflictual with any
application relocating resources when starting/running. But please keep
currently the RAM at default location for programming.
Regards,
Gilles
At 11:12 AM 9/14/2005, you wrote:
>Gilles,
>
>Thanks for your quick response. I figured out the .cmd files for the
>reset and preload. Then I put the ram at 0x0800-0x27ff and the EEPROM
>from 0x2800 to 0x2fff. I found (as you have pointed out) that if the
RAM
>does not cover the 0x0800 space then I get error messages from the
>debugger about being unable to load the diagnostic algorithm. I see
that
>if your programming code is at 0x0800 and is not PIC then any other
>option is a problem ;(
>
>Jonathan.
>
>-----Original Message-----
>From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
>Of Gilles Blanquin
>Sent: Wednesday, 14 September 2005 6:19 PM
>To: 68HC12@68HC...
>Subject: RE: [68HC12] Codewarrior programming EEPROM in S12DG128
>
>Hi Jonathan.
>
>I presume your silicon is an MC9S12DG128(B).
>Indeed, we had to "workaround" the fact that the EEPROM is below the
>Registers and Ram blocks.
>The Flash Programmer relocates automatically the EEPROM via INITEE real
>time change, when checking/programming, to address 0x2000. This is only
>done if INITEE is 0x01, default value. If changed by the user to
another
>
>value, the user relocation is taken in account.
>(*) To verify this, after starting a project on hardware, reset the
>debugger and open the Flash dialog (in ICD-12 menu). You should see the
>current location of the EEPROM.
>
>So to program it, define in your .prm the EEPROM at 0x2000.
>
>As you already defined for your application the RAM at 0x2000, it is
not
>
>possible to take advantage of this automatic relocation. The Linker
>won't
>accept to have 2 overlapped segments.
>
>So I propose to set the EEPROM for programming to another unused range,
>for
>example, commenting out "ROM_4000", that you can allocate via ppage
$3E.
>
>
>in your .prm: >SEGMENTS
> /* ROM_4000 = READ_ONLY 0x4000 TO 0x7FFF; */ /* also ppage $3E */
>END
>
>PLACEMENT
> EEPROM INTO READ_ONLY 0x4000 TO 0x47FF;
>END >Then add the following command in your Startup and Reset project
command
>files:
>
>wb 0x12 0x41 /* moves the eeprom at 0x4000 */
>The Flash Programmer will then care of the code "routed" to the
>0x4000-47FF.
>To make sure about the EEPROM relocation, proceed again as described at
>"*"
>here above.
>
>N.B. The application should care about all blocks location (INITRM,
>INITRG,
>INITEE) so there won't be any discrepancy at execution time (you can
>read
>the EEPROM were you define it). >Regards,
>Gilles >
>At 08:29 AM 9/14/2005, you wrote:
> >(This is probably a stupid question and there is probably a clever
> >answer)
> >
> >I have been programming a Codewarrior project into an DP256 for some
> >time. In an alternative product, a similar project is being put into
a
> >DG128. However I am struggling to understand how to locate the
EEPROM.
> >
> >The DG128 EEPROM is located at 0x0000 - 0x07ff on reset and is not
> >visible. My EEPROM section in my PRM file is 0x800. How does the
> >debugger know that this is where I want the EEPROM mapped and
> >programmed? This is a non issue with the DP256 as the EEPROM is
mapped
> >out of reset.
> >
> >At present, the EEPROM data is appearing in RAM since the RAM is
mapped
> >to 0x0800 out of reset. My program remaps the ram to 0x2000.
> >
> >I feel the answer lies somewhere in the works of Codewarrior. I hate
to
> >criticize documentation when I am new to a system, but I have been
>using
> >CodeWarrior for over two years in one form or another and still find
>the
> >helpfiles a waste of disk space.
> >
> >Jonathan Masters
> >JEMTECH Pty Ltd
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >> Terms of Service.
>
> _____ >
>> Terms of Service.
_____
I still have one thing I don't understand. I have mapped ram to
0x0800-0x27ff (8k bytes) using INITRM=0x08. EEPROM is mapped to 0x2800
to 0x2fff using INITEE=0x29. Curiously however, RAM stops at 0x1fff. The
final 2K is missing, unwritable and only reading 0x00. Are there some
special rules to the mapping registers I have misunderstood?
Jonathan
-----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
Of Gilles Blanquin
Sent: Wednesday, 14 September 2005 7:38 PM
To: 68HC12@68HC...
Subject: RE: [68HC12] Codewarrior programming EEPROM in S12DG128
Jonathan,
as you noticed, the flash drivers/algorithms have been setup to be
downloaded in 0x400-0x1FFF.
If you move the RAM at reset via a "WB" command to change INITRM, the
driver cannot be loaded and the diagnostic fails.
This is a known problem that has already been covered for the next
CodeWarrior release which has PIC code drivers and special commands for
drivers relocation.
However, the current drivers limitation is not conflictual with any
application relocating resources when starting/running. But please keep
currently the RAM at default location for programming.
Regards,
Gilles
At 11:12 AM 9/14/2005, you wrote:
>Gilles,
>
>Thanks for your quick response. I figured out the .cmd files for the
>reset and preload. Then I put the ram at 0x0800-0x27ff and the EEPROM
>from 0x2800 to 0x2fff. I found (as you have pointed out) that if the
RAM
>does not cover the 0x0800 space then I get error messages from the
>debugger about being unable to load the diagnostic algorithm. I see
that
>if your programming code is at 0x0800 and is not PIC then any other
>option is a problem ;(
>
>Jonathan.
>
>-----Original Message-----
>From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
>Of Gilles Blanquin
>Sent: Wednesday, 14 September 2005 6:19 PM
>To: 68HC12@68HC...
>Subject: RE: [68HC12] Codewarrior programming EEPROM in S12DG128
>
>Hi Jonathan.
>
>I presume your silicon is an MC9S12DG128(B).
>Indeed, we had to "workaround" the fact that the EEPROM is below the
>Registers and Ram blocks.
>The Flash Programmer relocates automatically the EEPROM via INITEE real
>time change, when checking/programming, to address 0x2000. This is only
>done if INITEE is 0x01, default value. If changed by the user to
another
>
>value, the user relocation is taken in account.
>(*) To verify this, after starting a project on hardware, reset the
>debugger and open the Flash dialog (in ICD-12 menu). You should see the
>current location of the EEPROM.
>
>So to program it, define in your .prm the EEPROM at 0x2000.
>
>As you already defined for your application the RAM at 0x2000, it is
not
>
>possible to take advantage of this automatic relocation. The Linker
>won't
>accept to have 2 overlapped segments.
>
>So I propose to set the EEPROM for programming to another unused range,
>for
>example, commenting out "ROM_4000", that you can allocate via ppage
$3E.
>
>
>in your .prm: >SEGMENTS
> /* ROM_4000 = READ_ONLY 0x4000 TO 0x7FFF; */ /* also ppage $3E */
>END
>
>PLACEMENT
> EEPROM INTO READ_ONLY 0x4000 TO 0x47FF;
>END >Then add the following command in your Startup and Reset project
command
>files:
>
>wb 0x12 0x41 /* moves the eeprom at 0x4000 */
>The Flash Programmer will then care of the code "routed" to the
>0x4000-47FF.
>To make sure about the EEPROM relocation, proceed again as described at
>"*"
>here above.
>
>N.B. The application should care about all blocks location (INITRM,
>INITRG,
>INITEE) so there won't be any discrepancy at execution time (you can
>read
>the EEPROM were you define it). >Regards,
>Gilles >
>At 08:29 AM 9/14/2005, you wrote:
> >(This is probably a stupid question and there is probably a clever
> >answer)
> >
> >I have been programming a Codewarrior project into an DP256 for some
> >time. In an alternative product, a similar project is being put into
a
> >DG128. However I am struggling to understand how to locate the
EEPROM.
> >
> >The DG128 EEPROM is located at 0x0000 - 0x07ff on reset and is not
> >visible. My EEPROM section in my PRM file is 0x800. How does the
> >debugger know that this is where I want the EEPROM mapped and
> >programmed? This is a non issue with the DP256 as the EEPROM is
mapped
> >out of reset.
> >
> >At present, the EEPROM data is appearing in RAM since the RAM is
mapped
> >to 0x0800 out of reset. My program remaps the ram to 0x2000.
> >
> >I feel the answer lies somewhere in the works of Codewarrior. I hate
to
> >criticize documentation when I am new to a system, but I have been
>using
> >CodeWarrior for over two years in one form or another and still find
>the
> >helpfiles a waste of disk space.
> >
> >Jonathan Masters
> >JEMTECH Pty Ltd
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >> Terms of Service.
>
> _____ >
>> Terms of Service.
_____
Reply by ●September 14, 20052005-09-14
Jonathan,
Thanks for your feedback.
We are aware of this help issue and the CodeWarrior team is already working
on improvements.
Regards,
Gilles At 11:45 AM 9/14/2005, you wrote:
>Gilles
>
>That's cool. My main problem has been with the amount of work needed to
>figure out the whole mechanism that the IDE/Debugger combo uses. The
>documentation in the help files is very generic and the PDF files in the
>manuals section are quite general. To be truthful I didn't even find the
>PDF files until relatively late in the process.
>
>Jonathan.
>
>-----Original Message-----
>From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
>Of Gilles Blanquin
>Sent: Wednesday, 14 September 2005 7:38 PM
>To: 68HC12@68HC...
>Subject: RE: [68HC12] Codewarrior programming EEPROM in S12DG128
>
>Jonathan,
>
>as you noticed, the flash drivers/algorithms have been setup to be
>downloaded in 0x400-0x1FFF.
>If you move the RAM at reset via a "WB" command to change INITRM, the
>driver cannot be loaded and the diagnostic fails.
>This is a known problem that has already been covered for the next
>CodeWarrior release which has PIC code drivers and special commands for
>drivers relocation.
>
>However, the current drivers limitation is not conflictual with any
>application relocating resources when starting/running. But please keep
>currently the RAM at default location for programming.
>
>Regards,
>Gilles >
>At 11:12 AM 9/14/2005, you wrote:
> >Gilles,
> >
> >Thanks for your quick response. I figured out the .cmd files for the
> >reset and preload. Then I put the ram at 0x0800-0x27ff and the EEPROM
> >from 0x2800 to 0x2fff. I found (as you have pointed out) that if the
>RAM
> >does not cover the 0x0800 space then I get error messages from the
> >debugger about being unable to load the diagnostic algorithm. I see
>that
> >if your programming code is at 0x0800 and is not PIC then any other
> >option is a problem ;(
> >
> >Jonathan.
> >
> >-----Original Message-----
> >From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
> >Of Gilles Blanquin
> >Sent: Wednesday, 14 September 2005 6:19 PM
> >To: 68HC12@68HC...
> >Subject: RE: [68HC12] Codewarrior programming EEPROM in S12DG128
> >
> >Hi Jonathan.
> >
> >I presume your silicon is an MC9S12DG128(B).
> >Indeed, we had to "workaround" the fact that the EEPROM is below the
> >Registers and Ram blocks.
> >The Flash Programmer relocates automatically the EEPROM via INITEE real
> >time change, when checking/programming, to address 0x2000. This is only
> >done if INITEE is 0x01, default value. If changed by the user to
>another
> >
> >value, the user relocation is taken in account.
> >(*) To verify this, after starting a project on hardware, reset the
> >debugger and open the Flash dialog (in ICD-12 menu). You should see the
> >current location of the EEPROM.
> >
> >So to program it, define in your .prm the EEPROM at 0x2000.
> >
> >As you already defined for your application the RAM at 0x2000, it is
>not
> >
> >possible to take advantage of this automatic relocation. The Linker
> >won't
> >accept to have 2 overlapped segments.
> >
> >So I propose to set the EEPROM for programming to another unused range,
> >for
> >example, commenting out "ROM_4000", that you can allocate via ppage
>$3E.
> >
> >
> >in your .prm:
> >
> >
> >SEGMENTS
> > /* ROM_4000 = READ_ONLY 0x4000 TO 0x7FFF; */ /* also ppage $3E */
> >END
> >
> >PLACEMENT
> > EEPROM INTO READ_ONLY 0x4000 TO 0x47FF;
> >END
> >
> >
> >Then add the following command in your Startup and Reset project
>command
> >files:
> >
> >wb 0x12 0x41 /* moves the eeprom at 0x4000 */
> >The Flash Programmer will then care of the code "routed" to the
> >0x4000-47FF.
> >To make sure about the EEPROM relocation, proceed again as described at
> >"*"
> >here above.
> >
> >N.B. The application should care about all blocks location (INITRM,
> >INITRG,
> >INITEE) so there won't be any discrepancy at execution time (you can
> >read
> >the EEPROM were you define it).
> >
> >
> >Regards,
> >Gilles
> >
> >
> >
> >At 08:29 AM 9/14/2005, you wrote:
> > >(This is probably a stupid question and there is probably a clever
> > >answer)
> > >
> > >I have been programming a Codewarrior project into an DP256 for some
> > >time. In an alternative product, a similar project is being put into
>a
> > >DG128. However I am struggling to understand how to locate the
>EEPROM.
> > >
> > >The DG128 EEPROM is located at 0x0000 - 0x07ff on reset and is not
> > >visible. My EEPROM section in my PRM file is 0x800. How does the
> > >debugger know that this is where I want the EEPROM mapped and
> > >programmed? This is a non issue with the DP256 as the EEPROM is
>mapped
> > >out of reset.
> > >
> > >At present, the EEPROM data is appearing in RAM since the RAM is
>mapped
> > >to 0x0800 out of reset. My program remaps the ram to 0x2000.
> > >
> > >I feel the answer lies somewhere in the works of Codewarrior. I hate
>to
> > >criticize documentation when I am new to a system, but I have been
> >using
> > >CodeWarrior for over two years in one form or another and still find
> >the
> > >helpfiles a waste of disk space.
> > >
> > >Jonathan Masters
> > >JEMTECH Pty Ltd
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >> Terms of Service.
> >
> > _____
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >> Terms of Service.
>
> _____ >
>Yahoo! Groups Links >
>
Thanks for your feedback.
We are aware of this help issue and the CodeWarrior team is already working
on improvements.
Regards,
Gilles At 11:45 AM 9/14/2005, you wrote:
>Gilles
>
>That's cool. My main problem has been with the amount of work needed to
>figure out the whole mechanism that the IDE/Debugger combo uses. The
>documentation in the help files is very generic and the PDF files in the
>manuals section are quite general. To be truthful I didn't even find the
>PDF files until relatively late in the process.
>
>Jonathan.
>
>-----Original Message-----
>From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
>Of Gilles Blanquin
>Sent: Wednesday, 14 September 2005 7:38 PM
>To: 68HC12@68HC...
>Subject: RE: [68HC12] Codewarrior programming EEPROM in S12DG128
>
>Jonathan,
>
>as you noticed, the flash drivers/algorithms have been setup to be
>downloaded in 0x400-0x1FFF.
>If you move the RAM at reset via a "WB" command to change INITRM, the
>driver cannot be loaded and the diagnostic fails.
>This is a known problem that has already been covered for the next
>CodeWarrior release which has PIC code drivers and special commands for
>drivers relocation.
>
>However, the current drivers limitation is not conflictual with any
>application relocating resources when starting/running. But please keep
>currently the RAM at default location for programming.
>
>Regards,
>Gilles >
>At 11:12 AM 9/14/2005, you wrote:
> >Gilles,
> >
> >Thanks for your quick response. I figured out the .cmd files for the
> >reset and preload. Then I put the ram at 0x0800-0x27ff and the EEPROM
> >from 0x2800 to 0x2fff. I found (as you have pointed out) that if the
>RAM
> >does not cover the 0x0800 space then I get error messages from the
> >debugger about being unable to load the diagnostic algorithm. I see
>that
> >if your programming code is at 0x0800 and is not PIC then any other
> >option is a problem ;(
> >
> >Jonathan.
> >
> >-----Original Message-----
> >From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
> >Of Gilles Blanquin
> >Sent: Wednesday, 14 September 2005 6:19 PM
> >To: 68HC12@68HC...
> >Subject: RE: [68HC12] Codewarrior programming EEPROM in S12DG128
> >
> >Hi Jonathan.
> >
> >I presume your silicon is an MC9S12DG128(B).
> >Indeed, we had to "workaround" the fact that the EEPROM is below the
> >Registers and Ram blocks.
> >The Flash Programmer relocates automatically the EEPROM via INITEE real
> >time change, when checking/programming, to address 0x2000. This is only
> >done if INITEE is 0x01, default value. If changed by the user to
>another
> >
> >value, the user relocation is taken in account.
> >(*) To verify this, after starting a project on hardware, reset the
> >debugger and open the Flash dialog (in ICD-12 menu). You should see the
> >current location of the EEPROM.
> >
> >So to program it, define in your .prm the EEPROM at 0x2000.
> >
> >As you already defined for your application the RAM at 0x2000, it is
>not
> >
> >possible to take advantage of this automatic relocation. The Linker
> >won't
> >accept to have 2 overlapped segments.
> >
> >So I propose to set the EEPROM for programming to another unused range,
> >for
> >example, commenting out "ROM_4000", that you can allocate via ppage
>$3E.
> >
> >
> >in your .prm:
> >
> >
> >SEGMENTS
> > /* ROM_4000 = READ_ONLY 0x4000 TO 0x7FFF; */ /* also ppage $3E */
> >END
> >
> >PLACEMENT
> > EEPROM INTO READ_ONLY 0x4000 TO 0x47FF;
> >END
> >
> >
> >Then add the following command in your Startup and Reset project
>command
> >files:
> >
> >wb 0x12 0x41 /* moves the eeprom at 0x4000 */
> >The Flash Programmer will then care of the code "routed" to the
> >0x4000-47FF.
> >To make sure about the EEPROM relocation, proceed again as described at
> >"*"
> >here above.
> >
> >N.B. The application should care about all blocks location (INITRM,
> >INITRG,
> >INITEE) so there won't be any discrepancy at execution time (you can
> >read
> >the EEPROM were you define it).
> >
> >
> >Regards,
> >Gilles
> >
> >
> >
> >At 08:29 AM 9/14/2005, you wrote:
> > >(This is probably a stupid question and there is probably a clever
> > >answer)
> > >
> > >I have been programming a Codewarrior project into an DP256 for some
> > >time. In an alternative product, a similar project is being put into
>a
> > >DG128. However I am struggling to understand how to locate the
>EEPROM.
> > >
> > >The DG128 EEPROM is located at 0x0000 - 0x07ff on reset and is not
> > >visible. My EEPROM section in my PRM file is 0x800. How does the
> > >debugger know that this is where I want the EEPROM mapped and
> > >programmed? This is a non issue with the DP256 as the EEPROM is
>mapped
> > >out of reset.
> > >
> > >At present, the EEPROM data is appearing in RAM since the RAM is
>mapped
> > >to 0x0800 out of reset. My program remaps the ram to 0x2000.
> > >
> > >I feel the answer lies somewhere in the works of Codewarrior. I hate
>to
> > >criticize documentation when I am new to a system, but I have been
> >using
> > >CodeWarrior for over two years in one form or another and still find
> >the
> > >helpfiles a waste of disk space.
> > >
> > >Jonathan Masters
> > >JEMTECH Pty Ltd
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >> Terms of Service.
> >
> > _____
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >> Terms of Service.
>
> _____ >
>Yahoo! Groups Links >
>
