Jonathan,
to have compatible layouts between silicons, I propose you to have a look
in the EB386.pdf from Freescale.
www.freescale.com/files/microcontrollers/doc/eng_bulletin/EB386.pdf
Figure 7 Example 1 Layout (p.18)
initrg = 0x00;
initrm = 0x39;
initee = 0x09;
Regards,
Gilles
At 12:01 PM 9/14/2005, you wrote:
>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.
>
> _____
>
>Yahoo! Groups Links
>
>
Re: Codewarrior programming EEPROM in S12DG128
Started by ●December 9, 2004
Reply by ●September 14, 20052005-09-14
Reply by ●September 14, 20052005-09-14
To reply to my own post..
INITRM shows RAM11-RAM15 bits as controlling the base address of the
RAM. In the CPU15 document there are no mentions of any limitations to
this. In the DT128 block device guide, the memory map says "mappable to
any 8K boundary" which would mean 0, 0x2000, 0x4000 etc - only
RAM15-RAM13 would be used in this scheme.
Can't say I ever been a big fan of the Freescale "modular documentation"
scheme.
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&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&k=Microcontrollers&w1=Freescale+semic
onductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+micropr
ocessor&c=4&s6&.sig=SYHwNJjjGQXRvtt_GybT4g>
Pic
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Freescale+s
emiconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+mic
roprocessor&c=4&s6&.sig=umVbbnUwsPzEzKKD_pQfUw> microcontrollers
8051
<http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Freescale+se
miconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+micr
oprocessor&c=4&s6&.sig=NO-nSKjHoAlh9XtZ8LB1_A> microprocessor
_____
> Terms of Service.
_____
INITRM shows RAM11-RAM15 bits as controlling the base address of the
RAM. In the CPU15 document there are no mentions of any limitations to
this. In the DT128 block device guide, the memory map says "mappable to
any 8K boundary" which would mean 0, 0x2000, 0x4000 etc - only
RAM15-RAM13 would be used in this scheme.
Can't say I ever been a big fan of the Freescale "modular documentation"
scheme.
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&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&k=Microcontrollers&w1=Freescale+semic
onductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+micropr
ocessor&c=4&s6&.sig=SYHwNJjjGQXRvtt_GybT4g>
Pic
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Freescale+s
emiconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+mic
roprocessor&c=4&s6&.sig=umVbbnUwsPzEzKKD_pQfUw> microcontrollers
8051
<http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Freescale+se
miconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+micr
oprocessor&c=4&s6&.sig=NO-nSKjHoAlh9XtZ8LB1_A> microprocessor
_____
> Terms of Service.
_____
Reply by ●September 14, 20052005-09-14
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&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&k=Microcontrollers&w1=Freescale+semic
onductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+micropr
ocessor&c=4&s6&.sig=SYHwNJjjGQXRvtt_GybT4g>
Pic
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Freescale+s
emiconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+mic
roprocessor&c=4&s6&.sig=umVbbnUwsPzEzKKD_pQfUw> microcontrollers
8051
<http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Freescale+se
miconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+micr
oprocessor&c=4&s6&.sig=NO-nSKjHoAlh9XtZ8LB1_A> microprocessor
_____
> Terms of Service.
_____
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&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&k=Microcontrollers&w1=Freescale+semic
onductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+micropr
ocessor&c=4&s6&.sig=SYHwNJjjGQXRvtt_GybT4g>
Pic
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Freescale+s
emiconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+mic
roprocessor&c=4&s6&.sig=umVbbnUwsPzEzKKD_pQfUw> microcontrollers
8051
<http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Freescale+se
miconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+micr
oprocessor&c=4&s6&.sig=NO-nSKjHoAlh9XtZ8LB1_A> microprocessor
_____
> Terms of Service.
_____
Reply by ●September 14, 20052005-09-14
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&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&k=Microcontrollers&w1=Freescale+semic
>onductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+micropr
>ocessor&c=4&s6&.sig=SYHwNJjjGQXRvtt_GybT4g>
>Pic
><http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Freescale+s
>emiconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+mic
>roprocessor&c=4&s6&.sig=umVbbnUwsPzEzKKD_pQfUw> microcontrollers
>
>8051
><http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Freescale+se
>miconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+micr
>oprocessor&c=4&s6&.sig=NO-nSKjHoAlh9XtZ8LB1_A> microprocessor >
> _____
>
>> Terms of Service.
>
> _____ >
>Yahoo! Groups Links >
>
Reply by ●September 15, 20052005-09-15
Thank you for the information and also reference in documentation, it
will
help us to define memorization strategies in the application.
Erwan
-----Message d'origine-----
De : Doron Fael [mailto:doronf@doro...]
Envoy: mercredi 14 septembre 2005 08:25
: 68HC12@68HC...
Objet : Re: [68HC12] RW cycles in Flash/EEPROM
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
help us to define memorization strategies in the application.
Erwan
-----Message d'origine-----
De : Doron Fael [mailto:doronf@doro...]
Envoy: mercredi 14 septembre 2005 08:25
: 68HC12@68HC...
Objet : Re: [68HC12] RW cycles in Flash/EEPROM
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.
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 23, 20052005-09-23
> 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.
Doron,
Do you know the Program/erase cycle for the 9S12DP256C ? Would it be
the same as the DJ64?
There doesn't seem to be any info to be found except for the 9S12DP256B.
thanks.
temperature.
> At temperatures above 0C it is 100,000 cycles minimum.
> At temperatures below 0c, it drops to 10,000 cycles minimum.
Doron,
Do you know the Program/erase cycle for the 9S12DP256C ? Would it be
the same as the DJ64?
There doesn't seem to be any info to be found except for the 9S12DP256B.
thanks.
Reply by ●September 25, 20052005-09-25
At 20:53 23/09/2005 +0000, you wrote:
>Doron,
>
>Do you know the Program/erase cycle for the 9S12DP256C ? Would it be
>the same as the DJ64?
>
>There doesn't seem to be any info to be found except for the 9S12DP256B.
>
>thanks.
Actually the data for the S12DP256C is not as good as for the S12DJ64.
Take a look at the following data sheets - that also cover the S12DP256C -
at table A12:
http://www.freescale.com/files/microcontrollers/doc/data_sheet/9S12DP256BDGV2.pdf
On the S12DP256C:
- The Flash is specified for a maximum of 10 erase/program cycles at -40C
to 125C, and data retention of 15 years.
- The EEPROM is specified for a maximum 10,000 erase/program cycles at -40C
to 125C, and data retention of 5 years.
These specifications are very cautious, and are very much affected by the
extreme temperatures. In less extreme temperatures it is very likely you
will get much more erase/program cycles, but Freescale will apparently not
guarantee it.
This was, I believe, one of the motivations for the newer MC9S12DT256 mask
sets 0L91N - 4L91N and 0L01Y, which have improved Flash and EEPROM
reliability, and a higher number of guaranteed erase/program cycles.
Take a look at table A-12 of the applicable data sheets:
http://www.freescale.com/files/microcontrollers/doc/data_sheet/9S12DT256DGV3.pdf
Which specify data retention of 15 years,
Flash minimum number of 1000 erase/program, and 10,000 typical.
EEPROM minimum number of 10,000 erase/program cycles (at -40C to 0C), or a
minimum of 100,000 at 0C to 140C.
These numbers are more similar to the numbers on the MC9S12DJ64, that you
were asking about.
Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
>Doron,
>
>Do you know the Program/erase cycle for the 9S12DP256C ? Would it be
>the same as the DJ64?
>
>There doesn't seem to be any info to be found except for the 9S12DP256B.
>
>thanks.
Actually the data for the S12DP256C is not as good as for the S12DJ64.
Take a look at the following data sheets - that also cover the S12DP256C -
at table A12:
http://www.freescale.com/files/microcontrollers/doc/data_sheet/9S12DP256BDGV2.pdf
On the S12DP256C:
- The Flash is specified for a maximum of 10 erase/program cycles at -40C
to 125C, and data retention of 15 years.
- The EEPROM is specified for a maximum 10,000 erase/program cycles at -40C
to 125C, and data retention of 5 years.
These specifications are very cautious, and are very much affected by the
extreme temperatures. In less extreme temperatures it is very likely you
will get much more erase/program cycles, but Freescale will apparently not
guarantee it.
This was, I believe, one of the motivations for the newer MC9S12DT256 mask
sets 0L91N - 4L91N and 0L01Y, which have improved Flash and EEPROM
reliability, and a higher number of guaranteed erase/program cycles.
Take a look at table A-12 of the applicable data sheets:
http://www.freescale.com/files/microcontrollers/doc/data_sheet/9S12DT256DGV3.pdf
Which specify data retention of 15 years,
Flash minimum number of 1000 erase/program, and 10,000 typical.
EEPROM minimum number of 10,000 erase/program cycles (at -40C to 0C), or a
minimum of 100,000 at 0C to 140C.
These numbers are more similar to the numbers on the MC9S12DJ64, that you
were asking about.
Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
Reply by ●September 25, 20052005-09-25
> This was, I believe, one of the motivations for the newer
MC9S12DT256 mask
> sets 0L91N - 4L91N and 0L01Y, which have improved Flash and EEPROM
> reliability, and a higher number of guaranteed erase/program cycles.
>
> Take a look at table A-12 of the applicable data sheets:
>
http://www.freescale.com/files/microcontrollers/doc/data_sheet/9S12DT256DGV3.pdf
>
> Which specify data retention of 15 years,
> Flash minimum number of 1000 erase/program, and 10,000 typical.
> EEPROM minimum number of 10,000 erase/program cycles (at -40C to
0C), or a
> minimum of 100,000 at 0C to 140C.
> These numbers are more similar to the numbers on the MC9S12DJ64,
that you
> were asking about.
Thanks Doron, you gave much good info that can be put to use.
MC9S12DT256 mask
> sets 0L91N - 4L91N and 0L01Y, which have improved Flash and EEPROM
> reliability, and a higher number of guaranteed erase/program cycles.
>
> Take a look at table A-12 of the applicable data sheets:
>
http://www.freescale.com/files/microcontrollers/doc/data_sheet/9S12DT256DGV3.pdf
>
> Which specify data retention of 15 years,
> Flash minimum number of 1000 erase/program, and 10,000 typical.
> EEPROM minimum number of 10,000 erase/program cycles (at -40C to
0C), or a
> minimum of 100,000 at 0C to 140C.
> These numbers are more similar to the numbers on the MC9S12DJ64,
that you
> were asking about.
Thanks Doron, you gave much good info that can be put to use.
