Sign in
Search 68hc12
Subscribe to 68hc12
68hc12 by Keywords
68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC
Ads
Discussion Groups
Discussion Groups | 68HC12 | EEPROM protection register
Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
EEPROM protection register - p_anglum - Nov 13 17:04:00 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? |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: EEPROM protection register - theobee00 - Nov 14 3:52:00 2003
|
--- 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 |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: EEPROM protection register - p_anglum - Nov 14 12:11:00 2003
|
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 |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: EEPROM protection register - Gordon Doughman - Nov 14 13:40:00 2003
|
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 > > >-------------------------------------------------------- >To unsubscribe from this group, send an email to: >To learn more about Motorola Microcontrollers, please visit >http://www.motorola.com/mcu > -- =============================================================== 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 |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: EEPROM protection register - p_anglum - Nov 14 14:07:00 2003
|
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 > >> > > > > > > > >-------------------------------------------------------- > >To unsubscribe from this group, send an email to: > > > > > >To learn more about Motorola Microcontrollers, please visit > >http://www.motorola.com/mcu > > > > > > > > > > > > > > -- > =============================================================== > 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 |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: EEPROM protection register - Gordon Doughman - Nov 14 14:37:00 2003
|
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 >> >> >> > >> > >> > >> >-------------------------------------------------------- >> >To unsubscribe from this group, send an email to: >> > >> > >> >To learn more about Motorola Microcontrollers, please visit >> >http://www.motorola.com/mcu >> > >> > >> > > >> > >> > >> > >> >>-- >>=============================================================== >>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 > > >-------------------------------------------------------- >To unsubscribe from this group, send an email to: >To learn more about Motorola Microcontrollers, please visit >http://www.motorola.com/mcu > -- =============================================================== 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 |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: EEPROM protection register - p_anglum - Nov 14 16:49:00 2003
|
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 > >> >> > >> > > >> > > >> > > >> >-------------------------------------------------------- > >> >To unsubscribe from this group, send an email to: > >> > > >> > > >> >To learn more about Motorola Microcontrollers, please visit > >> >http://www.motorola.com/mcu > >> > > >> > > >> > > > > >> > > >> > > >> > > >> > >>-- > >>=============================================================== > >>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 > >> > > > > > > > >-------------------------------------------------------- > >To unsubscribe from this group, send an email to: > > > > > >To learn more about Motorola Microcontrollers, please visit > >http://www.motorola.com/mcu > > > > > > > > > > > > > > -- > =============================================================== > 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 |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )