EEPROM protection register

Started by p_anglum November 13, 2003
We're using the MC9S12DP256B and I have a question regarding eeprom
protection. Not counting the area from $_E00 to $_FFF, can we use
the EPOPEN bit in the EPROT register to protect our eeprom data but
still modify the eeprom data if we first change the EPOPEN bit? Or
is the EPROT register itself also protected so that we don't have
access to the EPOPEN bit?



--- In , "p_anglum" <p_anglum@h...> wrote:
> We're using the MC9S12DP256B and I have a question regarding eeprom
> protection. Not counting the area from $_E00 to $_FFF, can we use
> the EPOPEN bit in the EPROT register to protect our eeprom data but
> still modify the eeprom data if we first change the EPOPEN bit? Or
> is the EPROT register itself also protected so that we don't have
> access to the EPOPEN bit?

Hi,

I am not an expert by a long shot, but the way I understand what is done is this.

On reset there are various locations being read into various reisters (if you set them up of course).
The principle seems to be that these registers are one shot locations, once modified they cannot be un_modified.

So when you manage to protect an area that includes the protection bytes you can only undo his by a total earase.

It makes sort of sense, once you decide to protect someting, you don't want software running riot to undo the works.

Cheers,

Yheo



I agree with your assessment, the only question I would still have is
regarding $_FFD. According to the manual "The EPROT register is
loaded from EEPROM array address $_FFD during reset...". So, if we
cannot change $_FFD (if it is protected also) what is it's purpose?
It seems redundant if it can't be changed and is simply copied to
EPROT.
--- In , "theobee00" <yahoodump2@o...> wrote:
> --- In , "p_anglum" <p_anglum@h...> wrote:
> > We're using the MC9S12DP256B and I have a question regarding
eeprom
> > protection. Not counting the area from $_E00 to $_FFF, can we
use
> > the EPOPEN bit in the EPROT register to protect our eeprom data
but
> > still modify the eeprom data if we first change the EPOPEN bit?
Or
> > is the EPROT register itself also protected so that we don't have
> > access to the EPOPEN bit?
>
> Hi,
>
> I am not an expert by a long shot, but the way I understand what is
done is this.
>
> On reset there are various locations being read into various
reisters (if you set them up of course).
> The principle seems to be that these registers are one shot
locations, once modified they cannot be un_modified.
>
> So when you manage to protect an area that includes the protection
bytes you can only undo his by a total earase.
>
> It makes sort of sense, once you decide to protect someting, you
don't want software running riot to undo the works.
>
> Cheers,
>
> Yheo




All,

Note that the description of the EPROT register states:

"The EPOPEN and EPDIS bits in the EPROT register can only be written to
the protected state (i.e. 0). The EP[2:0] bits can be written anytime
until bit EPDIS is cleared."

Programming location $xFFD to a value where either the EPOPEN and/or
EPDIS bits are 0 places a portion or the entire array of the EE in a
protected state *immediately* out of reset, with no possibility of
removing the protection while running in Normal mode. If the value at
$xFFD is left blank, EE protection is disabled out of reset, allowing
the application code the possibility of making changes to the area of EE
that is protectable. Once the changes have been made, the application
code can protect an area of EE by writing the correct value to the EPROT
register.

Regards,
Gordon

p_anglum wrote:

>I agree with your assessment, the only question I would still have is
>regarding $_FFD. According to the manual "The EPROT register is
>loaded from EEPROM array address $_FFD during reset...". So, if we
>cannot change $_FFD (if it is protected also) what is it's purpose?
>It seems redundant if it can't be changed and is simply copied to
>EPROT. >
>--- In , "theobee00" <yahoodump2@o...> wrote:
>
>>--- In , "p_anglum" <p_anglum@h...> wrote:
>>
>>>We're using the MC9S12DP256B and I have a question regarding
>>>
>eeprom
>
>>>protection. Not counting the area from $_E00 to $_FFF, can we
>>>
>use
>
>>>the EPOPEN bit in the EPROT register to protect our eeprom data
>>>
>but
>
>>>still modify the eeprom data if we first change the EPOPEN bit?
>>>
>Or
>
>>>is the EPROT register itself also protected so that we don't have
>>>access to the EPOPEN bit?
>>>
>>Hi,
>>
>>I am not an expert by a long shot, but the way I understand what is
>>
>done is this.
>
>>On reset there are various locations being read into various
>>
>reisters (if you set them up of course).
>
>>The principle seems to be that these registers are one shot
>>
>locations, once modified they cannot be un_modified.
>
>>So when you manage to protect an area that includes the protection
>>
>bytes you can only undo his by a total earase.
>
>>It makes sort of sense, once you decide to protect someting, you
>>
>don't want software running riot to undo the works.
>
>>Cheers,
>>
>>Yheo
> >
>-------------------- >
>">http://docs.yahoo.com/info/terms/ >

--
===============================================================
Gordon Doughman Ph: 937-438-6811
Motorola Semiconductor Fax: 937-434-7457
Field Applications Engineer Pager: 800-759-8352 Pin: 1304089
Suite 175
3131 Newmark Drive
Miamisburg, OH 45342

Check out my HC12 book at:
http://www.rtcbooks.com/programming.php



Thanks for the info Gordon. Just one last point of clarification.

>....with no possibility of removing the protection while running >in
Normal mode.

I understand I can't make changes on the fly using our application,
because it takes a reset for $xFFD to have any effect.

But is it possible to clear $xFFD then do a reset, update the EE,
then change $xFFD back to protect mode and reset again to activate
the protection?

(Or is $xFFD itself protected and we have to clear the entire EE to
clear $xFFD?) Thanks again!

--- In , Gordon Doughman <g.doughman@m...>
wrote:
> All,
>
> Note that the description of the EPROT register states:
>
> "The EPOPEN and EPDIS bits in the EPROT register can only be
written to
> the protected state (i.e. 0). The EP[2:0] bits can be written
anytime
> until bit EPDIS is cleared."
>
> Programming location $xFFD to a value where either the EPOPEN and/or
> EPDIS bits are 0 places a portion or the entire array of the EE in a
> protected state *immediately* out of reset, with no possibility of
> removing the protection while running in Normal mode. If the value
at
> $xFFD is left blank, EE protection is disabled out of reset,
allowing
> the application code the possibility of making changes to the area
of EE
> that is protectable. Once the changes have been made, the
application
> code can protect an area of EE by writing the correct value to the
EPROT
> register.
>
> Regards,
> Gordon
>
> p_anglum wrote:
>
> >I agree with your assessment, the only question I would still
have is
> >regarding $_FFD. According to the manual "The EPROT register is
> >loaded from EEPROM array address $_FFD during reset...". So, if
we
> >cannot change $_FFD (if it is protected also) what is it's
purpose?
> >It seems redundant if it can't be changed and is simply copied to
> >EPROT.
> >
> >
> >
> >--- In , "theobee00" <yahoodump2@o...>
wrote:
> >
> >>--- In , "p_anglum" <p_anglum@h...> wrote:
> >>
> >>>We're using the MC9S12DP256B and I have a question regarding
> >>>
> >eeprom
> >
> >>>protection. Not counting the area from $_E00 to $_FFF, can we
> >>>
> >use
> >
> >>>the EPOPEN bit in the EPROT register to protect our eeprom data
> >>>
> >but
> >
> >>>still modify the eeprom data if we first change the EPOPEN bit?
> >>>
> >Or
> >
> >>>is the EPROT register itself also protected so that we don't
have
> >>>access to the EPOPEN bit?
> >>>
> >>Hi,
> >>
> >>I am not an expert by a long shot, but the way I understand what
is
> >>
> >done is this.
> >
> >>On reset there are various locations being read into various
> >>
> >reisters (if you set them up of course).
> >
> >>The principle seems to be that these registers are one shot
> >>
> >locations, once modified they cannot be un_modified.
> >
> >>So when you manage to protect an area that includes the
protection
> >>
> >bytes you can only undo his by a total earase.
> >
> >>It makes sort of sense, once you decide to protect someting, you
> >>
> >don't want software running riot to undo the works.
> >
> >>Cheers,
> >>
> >>Yheo
> >>
> >
> >
> >
> >--------------------
> >
> >
> >
> >">http://docs.yahoo.com/info/terms/
> >
> >
> >
>
> --
> ===============================================================
> Gordon Doughman Ph: 937-438-6811
> Motorola Semiconductor Fax: 937-434-7457
> Field Applications Engineer Pager: 800-759-8352 Pin: 1304089
> Suite 175
> 3131 Newmark Drive
> Miamisburg, OH 45342
>
> Check out my HC12 book at:
> http://www.rtcbooks.com/programming.php





Because location $xFFD is part of the protected area, it cannot be
erased and reprogrammed in Normal mode if it has a value in it that
enables protection out of reset. As the spec states, the EPOPEN and
EPDIS bits in the EPROT register can only be written to the protected
state (from a 1 to a 0). If any portion of the EE is protected because
the bits associated with EPOPEN and EPDIS in location $xFFD are zero,
the only way the EE can be unprotected is to place the device in Special
mode with a BDM tool, write the EPROT register to $FF (all bits in the
EPROT register are writable at any time in Special mode) and then erase
$xFFD.

Regards,
Gordon p_anglum wrote:

>Thanks for the info Gordon. Just one last point of clarification. >>....with no possibility of removing the protection while running >in
>>
>Normal mode.
>
>I understand I can't make changes on the fly using our application,
>because it takes a reset for $xFFD to have any effect.
>
>But is it possible to clear $xFFD then do a reset, update the EE,
>then change $xFFD back to protect mode and reset again to activate
>the protection?
>
>(Or is $xFFD itself protected and we have to clear the entire EE to
>clear $xFFD?) >Thanks again!
>
>--- In , Gordon Doughman <g.doughman@m...> wrote:
>
>>All,
>>
>>Note that the description of the EPROT register states:
>>
>>"The EPOPEN and EPDIS bits in the EPROT register can only be
>>
>written to
>
>>the protected state (i.e. 0). The EP[2:0] bits can be written
>>
>anytime
>
>>until bit EPDIS is cleared."
>>
>>Programming location $xFFD to a value where either the EPOPEN and/or
>>EPDIS bits are 0 places a portion or the entire array of the EE in a
>>protected state *immediately* out of reset, with no possibility of
>>removing the protection while running in Normal mode. If the value
>>
>at
>
>>$xFFD is left blank, EE protection is disabled out of reset,
>>
>allowing
>
>>the application code the possibility of making changes to the area
>>
>of EE
>
>>that is protectable. Once the changes have been made, the
>>
>application
>
>>code can protect an area of EE by writing the correct value to the
>>
>EPROT
>
>>register.
>>
>>Regards,
>>Gordon
>>
>>p_anglum wrote:
>>
>> >I agree with your assessment, the only question I would still
>>
>have is
>
>> >regarding $_FFD. According to the manual "The EPROT register is
>> >loaded from EEPROM array address $_FFD during reset...". So, if
>>
>we
>
>> >cannot change $_FFD (if it is protected also) what is it's
>>
>purpose?
>
>> >It seems redundant if it can't be changed and is simply copied to
>> >EPROT.
>> >
>> >
>> >
>> >--- In , "theobee00" <yahoodump2@o...>
>>
>wrote:
>
>> >
>> >>--- In , "p_anglum" <p_anglum@h...> wrote:
>> >>
>> >>>We're using the MC9S12DP256B and I have a question regarding
>> >>>
>> >eeprom
>> >
>> >>>protection. Not counting the area from $_E00 to $_FFF, can we
>> >>>
>> >use
>> >
>> >>>the EPOPEN bit in the EPROT register to protect our eeprom data
>> >>>
>> >but
>> >
>> >>>still modify the eeprom data if we first change the EPOPEN bit?
>> >>>
>> >Or
>> >
>> >>>is the EPROT register itself also protected so that we don't
>>
>have
>
>> >>>access to the EPOPEN bit?
>> >>>
>> >>Hi,
>> >>
>> >>I am not an expert by a long shot, but the way I understand what
>>
>is
>
>> >>
>> >done is this.
>> >
>> >>On reset there are various locations being read into various
>> >>
>> >reisters (if you set them up of course).
>> >
>> >>The principle seems to be that these registers are one shot
>> >>
>> >locations, once modified they cannot be un_modified.
>> >
>> >>So when you manage to protect an area that includes the
>>
>protection
>
>> >>
>> >bytes you can only undo his by a total earase.
>> >
>> >>It makes sort of sense, once you decide to protect someting, you
>> >>
>> >don't want software running riot to undo the works.
>> >
>> >>Cheers,
>> >>
>> >>Yheo
>> >>
>> >
>> >
>> >
>> >--------------------
>> >
>> >
>> >
>> >">http://docs.yahoo.com/info/terms/
>
>> >
>> >
>> >
>>
>>--
>>===============================================================
>>Gordon Doughman Ph: 937-438-6811
>>Motorola Semiconductor Fax: 937-434-7457
>>Field Applications Engineer Pager: 800-759-8352 Pin: 1304089
>>Suite 175
>>3131 Newmark Drive
>>Miamisburg, OH 45342
>>
>>Check out my HC12 book at:
>>http://www.rtcbooks.com/programming.php
> >
>-------------------- >
>">http://docs.yahoo.com/info/terms/ >

--
===============================================================
Gordon Doughman Ph: 937-438-6811
Motorola Semiconductor Fax: 937-434-7457
Field Applications Engineer Pager: 800-759-8352 Pin: 1304089
Suite 175
3131 Newmark Drive
Miamisburg, OH 45342

Check out my HC12 book at:
http://www.rtcbooks.com/programming.php




Thanks Gordon
--- In , Gordon Doughman <g.doughman@m...>
wrote:
>
> Because location $xFFD is part of the protected area, it cannot be
> erased and reprogrammed in Normal mode if it has a value in it that
> enables protection out of reset. As the spec states, the EPOPEN and
> EPDIS bits in the EPROT register can only be written to the
protected
> state (from a 1 to a 0). If any portion of the EE is protected
because
> the bits associated with EPOPEN and EPDIS in location $xFFD are
zero,
> the only way the EE can be unprotected is to place the device in
Special
> mode with a BDM tool, write the EPROT register to $FF (all bits in
the
> EPROT register are writable at any time in Special mode) and then
erase
> $xFFD.
>
> Regards,
> Gordon > p_anglum wrote:
>
> >Thanks for the info Gordon. Just one last point of clarification.
> >
> >
> >>....with no possibility of removing the protection while running
>in
> >>
> >Normal mode.
> >
> >I understand I can't make changes on the fly using our
application,
> >because it takes a reset for $xFFD to have any effect.
> >
> >But is it possible to clear $xFFD then do a reset, update the EE,
> >then change $xFFD back to protect mode and reset again to activate
> >the protection?
> >
> >(Or is $xFFD itself protected and we have to clear the entire EE
to
> >clear $xFFD?)
> >
> >
> >Thanks again!
> >
> >--- In , Gordon Doughman <g.doughman@m...>
wrote:
> >
> >>All,
> >>
> >>Note that the description of the EPROT register states:
> >>
> >>"The EPOPEN and EPDIS bits in the EPROT register can only be
> >>
> >written to
> >
> >>the protected state (i.e. 0). The EP[2:0] bits can be written
> >>
> >anytime
> >
> >>until bit EPDIS is cleared."
> >>
> >>Programming location $xFFD to a value where either the EPOPEN
and/or
> >>EPDIS bits are 0 places a portion or the entire array of the EE
in a
> >>protected state *immediately* out of reset, with no possibility of
> >>removing the protection while running in Normal mode. If the
value
> >>
> >at
> >
> >>$xFFD is left blank, EE protection is disabled out of reset,
> >>
> >allowing
> >
> >>the application code the possibility of making changes to the
area
> >>
> >of EE
> >
> >>that is protectable. Once the changes have been made, the
> >>
> >application
> >
> >>code can protect an area of EE by writing the correct value to
the
> >>
> >EPROT
> >
> >>register.
> >>
> >>Regards,
> >>Gordon
> >>
> >>p_anglum wrote:
> >>
> >> >I agree with your assessment, the only question I would still
> >>
> >have is
> >
> >> >regarding $_FFD. According to the manual "The EPROT register is
> >> >loaded from EEPROM array address $_FFD during reset...". So,
if
> >>
> >we
> >
> >> >cannot change $_FFD (if it is protected also) what is it's
> >>
> >purpose?
> >
> >> >It seems redundant if it can't be changed and is simply copied
to
> >> >EPROT.
> >> >
> >> >
> >> >
> >> >--- In , "theobee00" <yahoodump2@o...>
> >>
> >wrote:
> >
> >> >
> >> >>--- In , "p_anglum" <p_anglum@h...>
wrote:
> >> >>
> >> >>>We're using the MC9S12DP256B and I have a question regarding
> >> >>>
> >> >eeprom
> >> >
> >> >>>protection. Not counting the area from $_E00 to $_FFF, can we
> >> >>>
> >> >use
> >> >
> >> >>>the EPOPEN bit in the EPROT register to protect our eeprom
data
> >> >>>
> >> >but
> >> >
> >> >>>still modify the eeprom data if we first change the EPOPEN
bit?
> >> >>>
> >> >Or
> >> >
> >> >>>is the EPROT register itself also protected so that we don't
> >>
> >have
> >
> >> >>>access to the EPOPEN bit?
> >> >>>
> >> >>Hi,
> >> >>
> >> >>I am not an expert by a long shot, but the way I understand
what
> >>
> >is
> >
> >> >>
> >> >done is this.
> >> >
> >> >>On reset there are various locations being read into various
> >> >>
> >> >reisters (if you set them up of course).
> >> >
> >> >>The principle seems to be that these registers are one shot
> >> >>
> >> >locations, once modified they cannot be un_modified.
> >> >
> >> >>So when you manage to protect an area that includes the
> >>
> >protection
> >
> >> >>
> >> >bytes you can only undo his by a total earase.
> >> >
> >> >>It makes sort of sense, once you decide to protect someting,
you
> >> >>
> >> >don't want software running riot to undo the works.
> >> >
> >> >>Cheers,
> >> >>
> >> >>Yheo
> >> >>
> >> >
> >> >
> >> >
> >> >--------------------
> >> >
> >> >
> >> >
> >> >">http://docs.yahoo.com/info/terms/
> >
> >> >
> >> >
> >> >
> >>
> >>--
> >>===============================================================
> >>Gordon Doughman Ph: 937-438-6811
> >>Motorola Semiconductor Fax: 937-434-7457
> >>Field Applications Engineer Pager: 800-759-8352 Pin: 1304089
> >>Suite 175
> >>3131 Newmark Drive
> >>Miamisburg, OH 45342
> >>
> >>Check out my HC12 book at:
> >>http://www.rtcbooks.com/programming.php
> >>
> >
> >
> >
> >--------------------
> >
> >
> >
> >">http://docs.yahoo.com/info/terms/
> >
> >
> >
>
> --
> ===============================================================
> Gordon Doughman Ph: 937-438-6811
> Motorola Semiconductor Fax: 937-434-7457
> Field Applications Engineer Pager: 800-759-8352 Pin: 1304089
> Suite 175
> 3131 Newmark Drive
> Miamisburg, OH 45342
>
> Check out my HC12 book at:
> http://www.rtcbooks.com/programming.php