Hi folks,
Is it my understanding that if I erase an HCS12's FLASH, but not its
EEPROM, and then reset the device before programming the security byte
(0xFF0F) to 0xFE, that BDM will no longer work?
Have I just created a doorstop to add to my collection? :)
Hans
How to make an HCS12 doorstop
Started by ●October 4, 2005
Reply by ●October 4, 20052005-10-04
> Is it my understanding that if I erase an HCS12's FLASH, but not
its
> EEPROM, and then reset the device before programming the security byte
> (0xFF0F) to 0xFE, that BDM will no longer work?
>
> Have I just created a doorstop to add to my collection? :)
Having erased flash and non-empty eeprom, and reseting the part into
single chip special mode, BDM will come out of reset as disabled
(BDMSTS.ENBDM == 0) and inactive (BDMSTS.BDMACT == 0). That doesn't mean
BDM no longer works - only firmware commands are disabled, but hardware
commands are still allowed. FLASH and EEPROM operations are limited then
to mass erase only. In this state, you have to mass erase both EEPROM
and FLASH, reset the part once more, BDM detects that EEPROM and FLASH
are both erased and enters "unsecure" BDM mode (BDMSTS.UNSEC bit, that's
different from overall security of the chip). That unsecure mode now
allows you to reprogram 0xff0e FLASH byte to unsecured state, thus
unsecuring whole MCU, after next reset. That's unsecuring procedure.
I'm not sure if it works for every HCS12 derivative. Works for A64 and
NE64, which I currently have on my bench and am just writing such
procedures :)
I recall that there was some discussion here about problems with some
early mask versions, that could render some chips to doorstop. But I
assume there were "exceptions". I don't know if there are some
derivatives that are secure-only-once-and-forget-about-unsecuring by design.
--
Michal Konieczny
mk@mk@....
> EEPROM, and then reset the device before programming the security byte
> (0xFF0F) to 0xFE, that BDM will no longer work?
>
> Have I just created a doorstop to add to my collection? :)
Having erased flash and non-empty eeprom, and reseting the part into
single chip special mode, BDM will come out of reset as disabled
(BDMSTS.ENBDM == 0) and inactive (BDMSTS.BDMACT == 0). That doesn't mean
BDM no longer works - only firmware commands are disabled, but hardware
commands are still allowed. FLASH and EEPROM operations are limited then
to mass erase only. In this state, you have to mass erase both EEPROM
and FLASH, reset the part once more, BDM detects that EEPROM and FLASH
are both erased and enters "unsecure" BDM mode (BDMSTS.UNSEC bit, that's
different from overall security of the chip). That unsecure mode now
allows you to reprogram 0xff0e FLASH byte to unsecured state, thus
unsecuring whole MCU, after next reset. That's unsecuring procedure.
I'm not sure if it works for every HCS12 derivative. Works for A64 and
NE64, which I currently have on my bench and am just writing such
procedures :)
I recall that there was some discussion here about problems with some
early mask versions, that could render some chips to doorstop. But I
assume there were "exceptions". I don't know if there are some
derivatives that are secure-only-once-and-forget-about-unsecuring by design.
--
Michal Konieczny
mk@mk@....
Reply by ●October 4, 20052005-10-04
Hans,
The best explanation of flash and EEPROM programming protection and
security is in Freescale's application note AN2400/D. Its well worth
reading. It explains the 27-step method of "unsecuring" a secured HCS-12 part.
Some answers below:
Steve Russell
Nohau Emulators
At 12:04 PM 10/4/2005, you wrote:
>Hi folks,
>
>Is it my understanding that if I erase an HCS12's FLASH, but not its
>EEPROM, and then reset the device before programming the security byte
>(0xFF0F) to 0xFE, that BDM will no longer work?
That is not quite correct.
When an HCS-12 is "secured", BDM still works to erase flash and
EEPROM. BDM won't read flash and EEPROM, but it will allow access to the
flash and EEPROM control registers for erasing.
This allows you to try again (and again...). If you finally get both flash
and EEPROM erased, and the security byte programmed to 0xFE you will have
"unsecured" the part and BDM works as expected.
A Nohau BDM emulator will notice that the HCS-12 is secured and ask if you
want to unsecure it.
P&E has an unsecure application for the PC that supports unsecuring through
their BDM units.
Other BDM interface suppliers may also support this.
When the HCS-12 parts first came out some of the mask sets that were used
for engineering samples acted differently when "secured".
>Have I just created a doorstop to add to my collection? :)
No, not if you have the right software for your BDM hardware.
>Hans
The best explanation of flash and EEPROM programming protection and
security is in Freescale's application note AN2400/D. Its well worth
reading. It explains the 27-step method of "unsecuring" a secured HCS-12 part.
Some answers below:
Steve Russell
Nohau Emulators
At 12:04 PM 10/4/2005, you wrote:
>Hi folks,
>
>Is it my understanding that if I erase an HCS12's FLASH, but not its
>EEPROM, and then reset the device before programming the security byte
>(0xFF0F) to 0xFE, that BDM will no longer work?
That is not quite correct.
When an HCS-12 is "secured", BDM still works to erase flash and
EEPROM. BDM won't read flash and EEPROM, but it will allow access to the
flash and EEPROM control registers for erasing.
This allows you to try again (and again...). If you finally get both flash
and EEPROM erased, and the security byte programmed to 0xFE you will have
"unsecured" the part and BDM works as expected.
A Nohau BDM emulator will notice that the HCS-12 is secured and ask if you
want to unsecure it.
P&E has an unsecure application for the PC that supports unsecuring through
their BDM units.
Other BDM interface suppliers may also support this.
When the HCS-12 parts first came out some of the mask sets that were used
for engineering samples acted differently when "secured".
>Have I just created a doorstop to add to my collection? :)
No, not if you have the right software for your BDM hardware.
>Hans
Reply by ●October 4, 20052005-10-04
More personal experience, below:
Steve Russell
Nohau Emulators
At 12:37 PM 10/4/2005, Michal Konieczny <mk@mk@....> wrote:
> > Is it my understanding that if I erase an HCS12's FLASH, but not its
> > EEPROM, and then reset the device before programming the security byte
> > (0xFF0F) to 0xFE, that BDM will no longer work?
> >
> > Have I just created a doorstop to add to my collection? :)
>
>Having erased flash and non-empty eeprom, and reseting the part into
>single chip special mode, BDM will come out of reset as disabled
>(BDMSTS.ENBDM == 0) and inactive (BDMSTS.BDMACT == 0). That doesn't mean
>BDM no longer works - only firmware commands are disabled, but hardware
>commands are still allowed. FLASH and EEPROM operations are limited then
>to mass erase only. In this state, you have to mass erase both EEPROM
>and FLASH, reset the part once more, BDM detects that EEPROM and FLASH
>are both erased and enters "unsecure" BDM mode (BDMSTS.UNSEC bit, that's
>different from overall security of the chip). That unsecure mode now
>allows you to reprogram 0xff0e FLASH byte to unsecured state, thus
>unsecuring whole MCU, after next reset. That's unsecuring procedure.
>I'm not sure if it works for every HCS12 derivative. Works for A64 and
>NE64, which I currently have on my bench and am just writing such
>procedures :)
I believe that the above is correct.
>I recall that there was some discussion here about problems with some
>early mask versions, that could render some chips to doorstop.
I experienced at least 2 different behaviors on early mask sets, but the
27-step procedure in AN2400/D restored all of them to proper operation.
>But I assume there were "exceptions". I don't know if there are some
>derivatives that are secure-only-once-and-forget-about-unsecuring by design.
Freescale apparently will make ROM parts if you want lots. They qualify as
secure-only-once-and-forget-about-unsecuring by design.
>--
>Michal Konieczny
>mk@mk@.... >
>
>Yahoo! Groups Links >
>
Steve Russell
Nohau Emulators
At 12:37 PM 10/4/2005, Michal Konieczny <mk@mk@....> wrote:
> > Is it my understanding that if I erase an HCS12's FLASH, but not its
> > EEPROM, and then reset the device before programming the security byte
> > (0xFF0F) to 0xFE, that BDM will no longer work?
> >
> > Have I just created a doorstop to add to my collection? :)
>
>Having erased flash and non-empty eeprom, and reseting the part into
>single chip special mode, BDM will come out of reset as disabled
>(BDMSTS.ENBDM == 0) and inactive (BDMSTS.BDMACT == 0). That doesn't mean
>BDM no longer works - only firmware commands are disabled, but hardware
>commands are still allowed. FLASH and EEPROM operations are limited then
>to mass erase only. In this state, you have to mass erase both EEPROM
>and FLASH, reset the part once more, BDM detects that EEPROM and FLASH
>are both erased and enters "unsecure" BDM mode (BDMSTS.UNSEC bit, that's
>different from overall security of the chip). That unsecure mode now
>allows you to reprogram 0xff0e FLASH byte to unsecured state, thus
>unsecuring whole MCU, after next reset. That's unsecuring procedure.
>I'm not sure if it works for every HCS12 derivative. Works for A64 and
>NE64, which I currently have on my bench and am just writing such
>procedures :)
I believe that the above is correct.
>I recall that there was some discussion here about problems with some
>early mask versions, that could render some chips to doorstop.
I experienced at least 2 different behaviors on early mask sets, but the
27-step procedure in AN2400/D restored all of them to proper operation.
>But I assume there were "exceptions". I don't know if there are some
>derivatives that are secure-only-once-and-forget-about-unsecuring by design.
Freescale apparently will make ROM parts if you want lots. They qualify as
secure-only-once-and-forget-about-unsecuring by design.
>--
>Michal Konieczny
>mk@mk@.... >
>
>Yahoo! Groups Links >
>
Reply by ●October 4, 20052005-10-04
I havent tried the 27-step process yet (I'm not using 3rd party
software), but I will. The bahavior I'm seeing is that all was fine
and dandy until I erased Flash blocks 0 & 1 w/o eraseing EEPROM. Now
BDM_BD_READs only return 0 no matter what address I read, which I've
interpreted as "BDM is dead". But perhaps it's not and the 27 step
process will just work?
Have you seen this kind of behavior?
Cheers,
Hans
--- In 68HC12@68HC..., Steve Russell <stever@n...> wrote:
> More personal experience, below:
>
> Steve Russell
> Nohau Emulators
>
> At 12:37 PM 10/4/2005, Michal Konieczny <mk@c...> wrote:
> > > Is it my understanding that if I erase an HCS12's FLASH, but
not its
> > > EEPROM, and then reset the device before programming the
security byte
> > > (0xFF0F) to 0xFE, that BDM will no longer work?
> > >
> > > Have I just created a doorstop to add to my collection? :)
> >
> >Having erased flash and non-empty eeprom, and reseting the part
into
> >single chip special mode, BDM will come out of reset as disabled
> >(BDMSTS.ENBDM == 0) and inactive (BDMSTS.BDMACT == 0). That doesn't
mean
> >BDM no longer works - only firmware commands are disabled, but
hardware
> >commands are still allowed. FLASH and EEPROM operations are limited
then
> >to mass erase only. In this state, you have to mass erase both
EEPROM
> >and FLASH, reset the part once more, BDM detects that EEPROM and
FLASH
> >are both erased and enters "unsecure" BDM mode (BDMSTS.UNSEC bit,
that's
> >different from overall security of the chip). That unsecure mode
now
> >allows you to reprogram 0xff0e FLASH byte to unsecured state, thus
> >unsecuring whole MCU, after next reset. That's unsecuring
procedure.
> >I'm not sure if it works for every HCS12 derivative. Works for A64
and
> >NE64, which I currently have on my bench and am just writing such
> >procedures :)
>
> I believe that the above is correct.
>
> >I recall that there was some discussion here about problems with
some
> >early mask versions, that could render some chips to doorstop.
>
> I experienced at least 2 different behaviors on early mask sets, but
the
> 27-step procedure in AN2400/D restored all of them to proper
operation.
>
> >But I assume there were "exceptions". I don't know if there are
some
> >derivatives that are secure-only-once-and-forget-about-unsecuring
by design.
>
> Freescale apparently will make ROM parts if you want lots. They
qualify as
> secure-only-once-and-forget-about-unsecuring by design.
>
> >--
> >Michal Konieczny
> >mk@c...
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
software), but I will. The bahavior I'm seeing is that all was fine
and dandy until I erased Flash blocks 0 & 1 w/o eraseing EEPROM. Now
BDM_BD_READs only return 0 no matter what address I read, which I've
interpreted as "BDM is dead". But perhaps it's not and the 27 step
process will just work?
Have you seen this kind of behavior?
Cheers,
Hans
--- In 68HC12@68HC..., Steve Russell <stever@n...> wrote:
> More personal experience, below:
>
> Steve Russell
> Nohau Emulators
>
> At 12:37 PM 10/4/2005, Michal Konieczny <mk@c...> wrote:
> > > Is it my understanding that if I erase an HCS12's FLASH, but
not its
> > > EEPROM, and then reset the device before programming the
security byte
> > > (0xFF0F) to 0xFE, that BDM will no longer work?
> > >
> > > Have I just created a doorstop to add to my collection? :)
> >
> >Having erased flash and non-empty eeprom, and reseting the part
into
> >single chip special mode, BDM will come out of reset as disabled
> >(BDMSTS.ENBDM == 0) and inactive (BDMSTS.BDMACT == 0). That doesn't
mean
> >BDM no longer works - only firmware commands are disabled, but
hardware
> >commands are still allowed. FLASH and EEPROM operations are limited
then
> >to mass erase only. In this state, you have to mass erase both
EEPROM
> >and FLASH, reset the part once more, BDM detects that EEPROM and
FLASH
> >are both erased and enters "unsecure" BDM mode (BDMSTS.UNSEC bit,
that's
> >different from overall security of the chip). That unsecure mode
now
> >allows you to reprogram 0xff0e FLASH byte to unsecured state, thus
> >unsecuring whole MCU, after next reset. That's unsecuring
procedure.
> >I'm not sure if it works for every HCS12 derivative. Works for A64
and
> >NE64, which I currently have on my bench and am just writing such
> >procedures :)
>
> I believe that the above is correct.
>
> >I recall that there was some discussion here about problems with
some
> >early mask versions, that could render some chips to doorstop.
>
> I experienced at least 2 different behaviors on early mask sets, but
the
> 27-step procedure in AN2400/D restored all of them to proper
operation.
>
> >But I assume there were "exceptions". I don't know if there are
some
> >derivatives that are secure-only-once-and-forget-about-unsecuring
by design.
>
> Freescale apparently will make ROM parts if you want lots. They
qualify as
> secure-only-once-and-forget-about-unsecuring by design.
>
> >--
> >Michal Konieczny
> >mk@c...
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
Reply by ●October 4, 20052005-10-04
Hans,
Questions and notes below.
Steve Russell
Nohau Emulators
At 01:27 PM 10/4/2005, "hashlock" <hashlock@hash...> wrote:
>I havent tried the 27-step process yet (I'm not using 3rd party
>software), but I will. The bahavior I'm seeing is that all was fine
>and dandy until I erased Flash blocks 0 & 1 w/o eraseing EEPROM. Now
>BDM_BD_READs only return 0 no matter what address I read, which I've
>interpreted as "BDM is dead". But perhaps it's not and the 27 step
>process will just work?
Can you try just reading and writing to flash control registers without
referring to any other registers?
Are you sure that you are bringing the chip up in "Special Single Chip Mode"?
>Have you seen this kind of behavior?
The 27-step process requires reading flash and EEPROM status registers in
special single chip mode, so you should be able to read them in special
single chip mode. >Cheers,
>
>Hans
>
>--- In 68HC12@68HC..., Steve Russell <stever@n...> wrote:
> > More personal experience, below:
> >
> > Steve Russell
> > Nohau Emulators
> >
> > At 12:37 PM 10/4/2005, Michal Konieczny <mk@c...> wrote:
> > > > Is it my understanding that if I erase an HCS12's FLASH, but
>not its
> > > > EEPROM, and then reset the device before programming the
>security byte
> > > > (0xFF0F) to 0xFE, that BDM will no longer work?
> > > >
> > > > Have I just created a doorstop to add to my collection? :)
> > >
> > >Having erased flash and non-empty eeprom, and reseting the part
>into
> > >single chip special mode, BDM will come out of reset as disabled
> > >(BDMSTS.ENBDM == 0) and inactive (BDMSTS.BDMACT == 0). That doesn't
>mean
> > >BDM no longer works - only firmware commands are disabled, but
>hardware
> > >commands are still allowed. FLASH and EEPROM operations are limited
>then
> > >to mass erase only. In this state, you have to mass erase both
>EEPROM
> > >and FLASH, reset the part once more, BDM detects that EEPROM and
>FLASH
> > >are both erased and enters "unsecure" BDM mode (BDMSTS.UNSEC bit,
>that's
> > >different from overall security of the chip). That unsecure mode
>now
> > >allows you to reprogram 0xff0e FLASH byte to unsecured state, thus
> > >unsecuring whole MCU, after next reset. That's unsecuring
>procedure.
> > >I'm not sure if it works for every HCS12 derivative. Works for A64
>and
> > >NE64, which I currently have on my bench and am just writing such
> > >procedures :)
> >
> > I believe that the above is correct.
> >
> > >I recall that there was some discussion here about problems with
>some
> > >early mask versions, that could render some chips to doorstop.
> >
> > I experienced at least 2 different behaviors on early mask sets, but
>the
> > 27-step procedure in AN2400/D restored all of them to proper
>operation.
> >
> > >But I assume there were "exceptions". I don't know if there are
>some
> > >derivatives that are secure-only-once-and-forget-about-unsecuring
>by design.
> >
> > Freescale apparently will make ROM parts if you want lots. They
>qualify as
> > secure-only-once-and-forget-about-unsecuring by design.
> >
> > >--
> > >Michal Konieczny
> > >mk@c...
> > >
> > >
> > >
> > >
> > >Yahoo! Groups Links
> > >
> > >
> > >
> > >
>Yahoo! Groups Links >
>
Questions and notes below.
Steve Russell
Nohau Emulators
At 01:27 PM 10/4/2005, "hashlock" <hashlock@hash...> wrote:
>I havent tried the 27-step process yet (I'm not using 3rd party
>software), but I will. The bahavior I'm seeing is that all was fine
>and dandy until I erased Flash blocks 0 & 1 w/o eraseing EEPROM. Now
>BDM_BD_READs only return 0 no matter what address I read, which I've
>interpreted as "BDM is dead". But perhaps it's not and the 27 step
>process will just work?
Can you try just reading and writing to flash control registers without
referring to any other registers?
Are you sure that you are bringing the chip up in "Special Single Chip Mode"?
>Have you seen this kind of behavior?
The 27-step process requires reading flash and EEPROM status registers in
special single chip mode, so you should be able to read them in special
single chip mode. >Cheers,
>
>Hans
>
>--- In 68HC12@68HC..., Steve Russell <stever@n...> wrote:
> > More personal experience, below:
> >
> > Steve Russell
> > Nohau Emulators
> >
> > At 12:37 PM 10/4/2005, Michal Konieczny <mk@c...> wrote:
> > > > Is it my understanding that if I erase an HCS12's FLASH, but
>not its
> > > > EEPROM, and then reset the device before programming the
>security byte
> > > > (0xFF0F) to 0xFE, that BDM will no longer work?
> > > >
> > > > Have I just created a doorstop to add to my collection? :)
> > >
> > >Having erased flash and non-empty eeprom, and reseting the part
>into
> > >single chip special mode, BDM will come out of reset as disabled
> > >(BDMSTS.ENBDM == 0) and inactive (BDMSTS.BDMACT == 0). That doesn't
>mean
> > >BDM no longer works - only firmware commands are disabled, but
>hardware
> > >commands are still allowed. FLASH and EEPROM operations are limited
>then
> > >to mass erase only. In this state, you have to mass erase both
>EEPROM
> > >and FLASH, reset the part once more, BDM detects that EEPROM and
>FLASH
> > >are both erased and enters "unsecure" BDM mode (BDMSTS.UNSEC bit,
>that's
> > >different from overall security of the chip). That unsecure mode
>now
> > >allows you to reprogram 0xff0e FLASH byte to unsecured state, thus
> > >unsecuring whole MCU, after next reset. That's unsecuring
>procedure.
> > >I'm not sure if it works for every HCS12 derivative. Works for A64
>and
> > >NE64, which I currently have on my bench and am just writing such
> > >procedures :)
> >
> > I believe that the above is correct.
> >
> > >I recall that there was some discussion here about problems with
>some
> > >early mask versions, that could render some chips to doorstop.
> >
> > I experienced at least 2 different behaviors on early mask sets, but
>the
> > 27-step procedure in AN2400/D restored all of them to proper
>operation.
> >
> > >But I assume there were "exceptions". I don't know if there are
>some
> > >derivatives that are secure-only-once-and-forget-about-unsecuring
>by design.
> >
> > Freescale apparently will make ROM parts if you want lots. They
>qualify as
> > secure-only-once-and-forget-about-unsecuring by design.
> >
> > >--
> > >Michal Konieczny
> > >mk@c...
> > >
> > >
> > >
> > >
> > >Yahoo! Groups Links
> > >
> > >
> > >
> > >
>Yahoo! Groups Links >
>
Reply by ●October 4, 20052005-10-04
If you are using a P&E compatable BDM interface, there is a free
unsecure_12 program you can download to unsecure your device. Most other
interface vendors also supply such a program.
Dave hashlock wrote:
> Hi folks,
>
> Is it my understanding that if I erase an HCS12's FLASH, but not its
> EEPROM, and then reset the device before programming the security byte
> (0xFF0F) to 0xFE, that BDM will no longer work?
>
> Have I just created a doorstop to add to my collection? :)
>
> Hans > SPONSORED LINKS
> Freescale semiconductor inc
> <http://groups.yahoo.com/gads?t=ms&k=Freescale+semiconductor+inc&w1=Freescale+semiconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s6&.sig=K2HGv-zFlv5OYUv_QxIq_Q>
> Microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Freescale+semiconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s6&.sig=SYHwNJjjGQXRvtt_GybT4g>
> Pic microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Freescale+semiconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s6&.sig=umVbbnUwsPzEzKKD_pQfUw>
>
> 8051 microprocessor
> <http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Freescale+semiconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s6&.sig=NO-nSKjHoAlh9XtZ8LB1_A >
>
> >. >
>
unsecure_12 program you can download to unsecure your device. Most other
interface vendors also supply such a program.
Dave hashlock wrote:
> Hi folks,
>
> Is it my understanding that if I erase an HCS12's FLASH, but not its
> EEPROM, and then reset the device before programming the security byte
> (0xFF0F) to 0xFE, that BDM will no longer work?
>
> Have I just created a doorstop to add to my collection? :)
>
> Hans > SPONSORED LINKS
> Freescale semiconductor inc
> <http://groups.yahoo.com/gads?t=ms&k=Freescale+semiconductor+inc&w1=Freescale+semiconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s6&.sig=K2HGv-zFlv5OYUv_QxIq_Q>
> Microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Freescale+semiconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s6&.sig=SYHwNJjjGQXRvtt_GybT4g>
> Pic microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Freescale+semiconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s6&.sig=umVbbnUwsPzEzKKD_pQfUw>
>
> 8051 microprocessor
> <http://groups.yahoo.com/gads?t=ms&k51+microprocessor&w1=Freescale+semiconductor+inc&w2=Microcontrollers&w3=Pic+microcontrollers&w451+microprocessor&c=4&s6&.sig=NO-nSKjHoAlh9XtZ8LB1_A >
>
> >. >
>
Reply by ●October 4, 20052005-10-04
> I havent tried the 27-step process yet (I'm not using 3rd party
> software), but I will. The bahavior I'm seeing is that all was fine
> and dandy until I erased Flash blocks 0 & 1 w/o eraseing EEPROM. Now
> BDM_BD_READs only return 0 no matter what address I read, which I've
> interpreted as "BDM is dead".
BDM not working at all would result in reading all 1's, rather than 0's,
I think ?
> But perhaps it's not and the 27 step
> process will just work?
>
> Have you seen this kind of behavior?
As I said earlier, I'm just working on securing/unsecuring code, and
I've it already working so I can test. I simulated your case: EEPROM not
empty, FLASH erased and NOT unsecured. Chips is then reset into single
chip special mode. That's what I see:
- reading BDM STATUS register reports ENBDM = 0 and BDMACT = 0
(READ_BDM_BYTE command)
- PARTID, MEMSIZ, MISC, FSEC, FPROT, ESEC, EPROT read as expected
(READ_BYTE command)
- INITRG, INITRM, INITEE can be written to
(WRITE_BYTE command)
- EEPROM and FLASH can be bulk erased by writing/reading
ECLKDIV/ESTAT/ECMD/EDATA/EADDR and FCLKDIV/FSTAT/FCMD/FDATA/FADDR
(that's most of the 27-step procedure fom AN2400).
Chip under test is MC9S12A64.
--
Michal Konieczny
mk@mk@....
> software), but I will. The bahavior I'm seeing is that all was fine
> and dandy until I erased Flash blocks 0 & 1 w/o eraseing EEPROM. Now
> BDM_BD_READs only return 0 no matter what address I read, which I've
> interpreted as "BDM is dead".
BDM not working at all would result in reading all 1's, rather than 0's,
I think ?
> But perhaps it's not and the 27 step
> process will just work?
>
> Have you seen this kind of behavior?
As I said earlier, I'm just working on securing/unsecuring code, and
I've it already working so I can test. I simulated your case: EEPROM not
empty, FLASH erased and NOT unsecured. Chips is then reset into single
chip special mode. That's what I see:
- reading BDM STATUS register reports ENBDM = 0 and BDMACT = 0
(READ_BDM_BYTE command)
- PARTID, MEMSIZ, MISC, FSEC, FPROT, ESEC, EPROT read as expected
(READ_BYTE command)
- INITRG, INITRM, INITEE can be written to
(WRITE_BYTE command)
- EEPROM and FLASH can be bulk erased by writing/reading
ECLKDIV/ESTAT/ECMD/EDATA/EADDR and FCLKDIV/FSTAT/FCMD/FDATA/FADDR
(that's most of the 27-step procedure fom AN2400).
Chip under test is MC9S12A64.
--
Michal Konieczny
mk@mk@....
Reply by ●October 5, 20052005-10-05
Thanks all,
The 27 step process resurrected my doorstop. I've learned couple of
lessons:
1) BDM_STATUS == 0 does not mean BDM is dead
2) Once mass erased, the secure BDM firmware takes more than a second
(at least on my 9S12H256) to verify that the FLASH and EEPROM are
erased. Freescale's docs just say "delay until firmware has
verified...". I never thought that delay would be on the order of
seconds!
Cheers,
Hans --- In 68HC12@68HC..., Michal Konieczny <mk@c...> wrote:
> > I havent tried the 27-step process yet (I'm not using 3rd party
> > software), but I will. The bahavior I'm seeing is that all was fine
> > and dandy until I erased Flash blocks 0 & 1 w/o eraseing EEPROM. Now
> > BDM_BD_READs only return 0 no matter what address I read, which I've
> > interpreted as "BDM is dead".
>
> BDM not working at all would result in reading all 1's, rather than
0's,
> I think ?
>
> > But perhaps it's not and the 27 step
> > process will just work?
> >
> > Have you seen this kind of behavior?
>
> As I said earlier, I'm just working on securing/unsecuring code, and
> I've it already working so I can test. I simulated your case: EEPROM
not
> empty, FLASH erased and NOT unsecured. Chips is then reset into single
> chip special mode. That's what I see:
> - reading BDM STATUS register reports ENBDM = 0 and BDMACT = 0
> (READ_BDM_BYTE command)
> - PARTID, MEMSIZ, MISC, FSEC, FPROT, ESEC, EPROT read as expected
> (READ_BYTE command)
> - INITRG, INITRM, INITEE can be written to
> (WRITE_BYTE command)
> - EEPROM and FLASH can be bulk erased by writing/reading
> ECLKDIV/ESTAT/ECMD/EDATA/EADDR and FCLKDIV/FSTAT/FCMD/FDATA/FADDR
> (that's most of the 27-step procedure fom AN2400).
>
> Chip under test is MC9S12A64.
>
> --
> Michal Konieczny
> mk@c...
The 27 step process resurrected my doorstop. I've learned couple of
lessons:
1) BDM_STATUS == 0 does not mean BDM is dead
2) Once mass erased, the secure BDM firmware takes more than a second
(at least on my 9S12H256) to verify that the FLASH and EEPROM are
erased. Freescale's docs just say "delay until firmware has
verified...". I never thought that delay would be on the order of
seconds!
Cheers,
Hans --- In 68HC12@68HC..., Michal Konieczny <mk@c...> wrote:
> > I havent tried the 27-step process yet (I'm not using 3rd party
> > software), but I will. The bahavior I'm seeing is that all was fine
> > and dandy until I erased Flash blocks 0 & 1 w/o eraseing EEPROM. Now
> > BDM_BD_READs only return 0 no matter what address I read, which I've
> > interpreted as "BDM is dead".
>
> BDM not working at all would result in reading all 1's, rather than
0's,
> I think ?
>
> > But perhaps it's not and the 27 step
> > process will just work?
> >
> > Have you seen this kind of behavior?
>
> As I said earlier, I'm just working on securing/unsecuring code, and
> I've it already working so I can test. I simulated your case: EEPROM
not
> empty, FLASH erased and NOT unsecured. Chips is then reset into single
> chip special mode. That's what I see:
> - reading BDM STATUS register reports ENBDM = 0 and BDMACT = 0
> (READ_BDM_BYTE command)
> - PARTID, MEMSIZ, MISC, FSEC, FPROT, ESEC, EPROT read as expected
> (READ_BYTE command)
> - INITRG, INITRM, INITEE can be written to
> (WRITE_BYTE command)
> - EEPROM and FLASH can be bulk erased by writing/reading
> ECLKDIV/ESTAT/ECMD/EDATA/EADDR and FCLKDIV/FSTAT/FCMD/FDATA/FADDR
> (that's most of the 27-step procedure fom AN2400).
>
> Chip under test is MC9S12A64.
>
> --
> Michal Konieczny
> mk@c...
