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...
Reply by Michal Konieczny●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@....
Reply by Dr. David A. Perreault●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.
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 hashlock●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
> >
> >
> >
> >
Reply by Steve Russell●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.
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 Michal Konieczny●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@....
Reply by hashlock●October 4, 20052005-10-04
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? :)