Forums

disabling security in bootloader

Started by Steve Letkeman July 6, 2004
So here's another question concerning security while running a
bootloader. If you have the processor in secure mode and you
want to update the firmware, then you would send it a command
(SCI/CAN etc) to use the back door key to unsecure the processor
in order to write new firmware to flash. At this point, is the
device not open to BDM activity? Or do you have to reset in order
for the BDM to work in which case the security would kick in at reset?
Am I missing something here?

Thanks,
Steve



Steve,

I believe that the MC9S12DT256 documentation on the Freescale / Motorola
web site is the best source for how securing and un-securing should work.

Note that many of the older mask sets of MC9S12DP256 parts do not operate
as described for the newest parts.

Things to note in the quote from the documentation below:

It clearly states that the correct backdoor key sequence "unsecures" the MCU.

I take this to mean that the program in flash could then enable BDM, even
if the MCU is in Normal Single Chip mode.

For the MC9S12DT256 there are 2 bits in the KEYEN field. (Some HCS-12 MCUs
have only 1 bit for KEYEN. Also backdoor key words cannot be all 0 or all
1, a change from early MC9S12DP256 documnetation. Check the most recent
specific documentation for your MCU.)

From a recent copy of the flash documentation for the MC9S12DT256:

4.5.1 Unsecuring via the Backdoor Key Access

The MCU may only be unsecured by using the Backdoor Key Access feature
which requires knowledge of the contents of the Backdoor Keys (four 16-bit
words programmed at addresses $FF00 - $FF07). If KEYEN[1:0] and the
KEYACC bit is set, a write to a Backdoor Key address in the Flash array
triggers a comparison between the written data and the Backdoor Key data
stored in the Flash array. If all four words of data are written to the
correct addresses in the correct order and the data matches the Backdoor
Keys stored in the Flash array, the MCU will be unsecured. The data must be
written to the Backdoor Keys sequentially staring with $FF00-1 and ending
with $FF06-7. $0000 and $FFFF keys are not permitted. When the KEYACC bit
is set, reads of the Flash array will return invalid data.

The user code stored in the Flash array must have a method of receiving the
Backdoor Key from an external stimulus. This external stimulus would
typically be through one of the on-chip serial ports.

If KEYEN[1:0] in the FSEC register, the MCU can be unsecured by the
ackdoor Access Sequence described below:

1. Set the KEYACC bit in the Flash Configuration Register (FCNFG).

2. Write the correct four 16-bit words to Flash addresses $FF00 - $FF07
sequentially starting with
$FF00.

3. Clear the KEYACC bit.

4. If all four 16-bit words match the Backdoor Keys stored in Flash
addresses $FF00 - $FF07, the MCU is unsecured and bits SEC[1:0] in the FSEC
register are forced to the unsecure state of "10".

The Backdoor Access Sequence is monitored by the internal Security State
Machine. An illegal operation during the Backdoor Access Sequence will
cause the Security State Machine to lock, leaving the MCU in the secured
state. A reset of the MCU will cause the Security State Machine to exit the
lock state and allow a new Backdoor Access Sequence to be attempted. The
following illegal operations will lock the Security State Machine:

1. If any of the four 16-bit words does not match the backdoor keys
programmed in the Flash array.

2. If the four 16-bit words are written in the wrong sequence.

3. If more than four 16-bit words are written.

4. If any of the four 16-bit words written are $0000 or $FFFF.

5. If the KEYACC bit does not remain set while the four 16-bit words are
written.

After the Backdoor Access Sequence has been correctly matched, the MCU will
be unsecured. The Flash security byte can be programmed to the unsecure
state, if desired.

In the unsecure state, the user has full control of the contents of the
four word Backdoor Key by programming it in bytes $FF00 - $FF07 of the
Flash Protection/Options Field.

The security as defined in the Flash Security/Options byte ($FF0F) is not
changed by using the Backdoor Access Sequence to unsecure. The Backdoor
Keys stored in addresses $FF00 - $FF07 are unaffected by the Backdoor
Access Sequence. After the next reset sequence, the security state of the
Flash module is determined by the Flash Security/Options byte ($FF0F). The
Backdoor Access Sequence has no effect on the program and erase protections
defined in the Flash Protection Register (FPROT).

It is not possible to unsecure the MCU in Special Single Chip mode by the
Backdoor Access Sequence via the Background Debug Mode.

A further comment below.

Hope this helps.

Steve Russell
Nohau Emulators At 07:04 PM 7/6/2004, Steve Letkeman wrote:
>So here's another question concerning security while running a
>bootloader. If you have the processor in secure mode and you
>want to update the firmware, then you would send it a command
>(SCI/CAN etc) to use the back door key to unsecure the processor
>in order to write new firmware to flash. At this point, is the
>device not open to BDM activity? Or do you have to reset in order
>for the BDM to work in which case the security would kick in at reset?
>Am I missing something here?

Yes, but we all do.

There are 1500+ pages of documentation for each HCS-12 part, and new
updates come out periodically. The best of the documentation is like that
quoted above: Correct but terse.

The worst, such as the early documentation for flash security, is what you
might expect from a confused writer >Thanks,
>Steve >Yahoo! Groups Links >
>


*************************************************************************
Steve Russell mailto:
Senior Software Design Engineer http://www.nohau.com
Nohau Corporation phone: (408)866-1820 ext. 1873
51 East Campbell Avenue fax: (408)378-7869
Campbell, CA 95008
*************************************************************************



Thanks for the response, I did read through the documentation that you've
quoted below and what I don't find to be clear is this: If I unsecure the
MCU with the backdoor method in order to write to the flash memory,
does the BDM automatically become active without my program
specifically enabling it? The documentation does say that the BDM
is active while in unsecure mode, right?

Any comments welcome,
Steve
----- Original Message -----
From: Steve Russell
To:
Sent: Tuesday, July 06, 2004 9:49 PM
Subject: Re: [68HC12] disabling security in bootloader Steve,

I believe that the MC9S12DT256 documentation on the Freescale / Motorola
web site is the best source for how securing and un-securing should work.

Note that many of the older mask sets of MC9S12DP256 parts do not operate
as described for the newest parts.

Things to note in the quote from the documentation below:

It clearly states that the correct backdoor key sequence "unsecures" the MCU.

I take this to mean that the program in flash could then enable BDM, even
if the MCU is in Normal Single Chip mode.

For the MC9S12DT256 there are 2 bits in the KEYEN field. (Some HCS-12 MCUs
have only 1 bit for KEYEN. Also backdoor key words cannot be all 0 or all
1, a change from early MC9S12DP256 documnetation. Check the most recent
specific documentation for your MCU.)

From a recent copy of the flash documentation for the MC9S12DT256:

4.5.1 Unsecuring via the Backdoor Key Access

The MCU may only be unsecured by using the Backdoor Key Access feature
which requires knowledge of the contents of the Backdoor Keys (four 16-bit
words programmed at addresses $FF00 - $FF07). If KEYEN[1:0] and the
KEYACC bit is set, a write to a Backdoor Key address in the Flash array
triggers a comparison between the written data and the Backdoor Key data
stored in the Flash array. If all four words of data are written to the
correct addresses in the correct order and the data matches the Backdoor
Keys stored in the Flash array, the MCU will be unsecured. The data must be
written to the Backdoor Keys sequentially staring with $FF00-1 and ending
with $FF06-7. $0000 and $FFFF keys are not permitted. When the KEYACC bit
is set, reads of the Flash array will return invalid data.

The user code stored in the Flash array must have a method of receiving the
Backdoor Key from an external stimulus. This external stimulus would
typically be through one of the on-chip serial ports.

If KEYEN[1:0] in the FSEC register, the MCU can be unsecured by the
ackdoor Access Sequence described below:

1. Set the KEYACC bit in the Flash Configuration Register (FCNFG).

2. Write the correct four 16-bit words to Flash addresses $FF00 - $FF07
sequentially starting with
$FF00.

3. Clear the KEYACC bit.

4. If all four 16-bit words match the Backdoor Keys stored in Flash
addresses $FF00 - $FF07, the MCU is unsecured and bits SEC[1:0] in the FSEC
register are forced to the unsecure state of "10".

The Backdoor Access Sequence is monitored by the internal Security State
Machine. An illegal operation during the Backdoor Access Sequence will
cause the Security State Machine to lock, leaving the MCU in the secured
state. A reset of the MCU will cause the Security State Machine to exit the
lock state and allow a new Backdoor Access Sequence to be attempted. The
following illegal operations will lock the Security State Machine:

1. If any of the four 16-bit words does not match the backdoor keys
programmed in the Flash array.

2. If the four 16-bit words are written in the wrong sequence.

3. If more than four 16-bit words are written.

4. If any of the four 16-bit words written are $0000 or $FFFF.

5. If the KEYACC bit does not remain set while the four 16-bit words are
written.

After the Backdoor Access Sequence has been correctly matched, the MCU will
be unsecured. The Flash security byte can be programmed to the unsecure
state, if desired.

In the unsecure state, the user has full control of the contents of the
four word Backdoor Key by programming it in bytes $FF00 - $FF07 of the
Flash Protection/Options Field.

The security as defined in the Flash Security/Options byte ($FF0F) is not
changed by using the Backdoor Access Sequence to unsecure. The Backdoor
Keys stored in addresses $FF00 - $FF07 are unaffected by the Backdoor
Access Sequence. After the next reset sequence, the security state of the
Flash module is determined by the Flash Security/Options byte ($FF0F). The
Backdoor Access Sequence has no effect on the program and erase protections
defined in the Flash Protection Register (FPROT).

It is not possible to unsecure the MCU in Special Single Chip mode by the
Backdoor Access Sequence via the Background Debug Mode.

A further comment below.

Hope this helps.

Steve Russell
Nohau Emulators At 07:04 PM 7/6/2004, Steve Letkeman wrote:
>So here's another question concerning security while running a
>bootloader. If you have the processor in secure mode and you
>want to update the firmware, then you would send it a command
>(SCI/CAN etc) to use the back door key to unsecure the processor
>in order to write new firmware to flash. At this point, is the
>device not open to BDM activity? Or do you have to reset in order
>for the BDM to work in which case the security would kick in at reset?
>Am I missing something here?

Yes, but we all do.

There are 1500+ pages of documentation for each HCS-12 part, and new
updates come out periodically. The best of the documentation is like that
quoted above: Correct but terse.

The worst, such as the early documentation for flash security, is what you
might expect from a confused writer >Thanks,
>Steve >Yahoo! Groups Links >
>


*************************************************************************
Steve Russell mailto:
Senior Software Design Engineer http://www.nohau.com
Nohau Corporation phone: (408)866-1820 ext. 1873
51 East Campbell Avenue fax: (408)378-7869
Campbell, CA 95008
************************************************************************* ------
Yahoo! Groups Links

a.. To



Maybe I missed something at the beginning of this thread, but in my
bootloader I don't have to unsecure the uP in order to update the flash.
Only the startup and bootloader code is write-protected.

Mike

----- Original Message -----
From: "Steve Letkeman" <>
To: <>
Sent: Wednesday, July 07, 2004 8:39 AM
Subject: Re: [68HC12] disabling security in bootloader > Thanks for the response, I did read through the documentation that you've
> quoted below and what I don't find to be clear is this: If I unsecure
the
> MCU with the backdoor method in order to write to the flash memory,
> does the BDM automatically become active without my program
> specifically enabling it? The documentation does say that the BDM
> is active while in unsecure mode, right?
>
> Any comments welcome,
> Steve
> ----- Original Message -----
> From: Steve Russell
> To:
> Sent: Tuesday, July 06, 2004 9:49 PM
> Subject: Re: [68HC12] disabling security in bootloader > Steve,
>
> I believe that the MC9S12DT256 documentation on the Freescale / Motorola
> web site is the best source for how securing and un-securing should
work.
>
>snip
>



Steve,

After re-reading the BDM documentation, I believe that the BDM is not
active or enabled after you unsecure with the backdoor key.

Reading between the lines, I think that you can set ENBDM in the BDMSTS
register with a "hardware" BDM command after the part is
unsecured. However, this is not explicitly stated, so experiment is indicated.

Again note that the securing logic has evolved from none on the very first
MC9S12DP256 mask set to pretty bullet-proof on the latest HCS-12 mask
sets. Just because things work one way on you trusty old development
system, doesn't mean that they will work the same way on the latest
production parts.

"The manufacturer reserves the right to improve the specifications without
notice."

Steve Russell
Nohau Emulators

At 06:39 AM 7/7/2004, Steve Letkeman wrote:
>Thanks for the response, I did read through the documentation that you've
> quoted below and what I don't find to be clear is this: If I unsecure the
> MCU with the backdoor method in order to write to the flash memory,
> does the BDM automatically become active without my program
>specifically enabling it? The documentation does say that the BDM
> is active while in unsecure mode, right?
>
>Any comments welcome,
>Steve
> ----- Original Message -----
> From: Steve Russell
> To:
> Sent: Tuesday, July 06, 2004 9:49 PM
> Subject: Re: [68HC12] disabling security in bootloader > Steve,
>
> I believe that the MC9S12DT256 documentation on the Freescale / Motorola
> web site is the best source for how securing and un-securing should work.
>
> Note that many of the older mask sets of MC9S12DP256 parts do not operate
> as described for the newest parts.
>
> Things to note in the quote from the documentation below:
>
> It clearly states that the correct backdoor key sequence "unsecures"
> the MCU.
>
> I take this to mean that the program in flash could then enable BDM, even
> if the MCU is in Normal Single Chip mode.
>
> For the MC9S12DT256 there are 2 bits in the KEYEN field. (Some HCS-12
> MCUs
> have only 1 bit for KEYEN. Also backdoor key words cannot be all 0 or all
> 1, a change from early MC9S12DP256 documnetation. Check the most recent
> specific documentation for your MCU.)
>
> From a recent copy of the flash documentation for the MC9S12DT256:
>
> 4.5.1 Unsecuring via the Backdoor Key Access
>
> The MCU may only be unsecured by using the Backdoor Key Access feature
> which requires knowledge of the contents of the Backdoor Keys (four 16-bit
> words programmed at addresses $FF00 - $FF07). If KEYEN[1:0] and the
> KEYACC bit is set, a write to a Backdoor Key address in the Flash array
> triggers a comparison between the written data and the Backdoor Key data
> stored in the Flash array. If all four words of data are written to the
> correct addresses in the correct order and the data matches the Backdoor
> Keys stored in the Flash array, the MCU will be unsecured. The data
> must be
> written to the Backdoor Keys sequentially staring with $FF00-1 and ending
> with $FF06-7. $0000 and $FFFF keys are not permitted. When the KEYACC bit
> is set, reads of the Flash array will return invalid data.
>
> The user code stored in the Flash array must have a method of receiving
> the
> Backdoor Key from an external stimulus. This external stimulus would
> typically be through one of the on-chip serial ports.
>
> If KEYEN[1:0] in the FSEC register, the MCU can be unsecured by the
> ackdoor Access Sequence described below:
>
> 1. Set the KEYACC bit in the Flash Configuration Register (FCNFG).
>
> 2. Write the correct four 16-bit words to Flash addresses $FF00 - $FF07
> sequentially starting with
> $FF00.
>
> 3. Clear the KEYACC bit.
>
> 4. If all four 16-bit words match the Backdoor Keys stored in Flash
> addresses $FF00 - $FF07, the MCU is unsecured and bits SEC[1:0] in the
> FSEC
> register are forced to the unsecure state of "10".
>
> The Backdoor Access Sequence is monitored by the internal Security State
> Machine. An illegal operation during the Backdoor Access Sequence will
> cause the Security State Machine to lock, leaving the MCU in the secured
> state. A reset of the MCU will cause the Security State Machine to exit
> the
> lock state and allow a new Backdoor Access Sequence to be attempted. The
> following illegal operations will lock the Security State Machine:
>
> 1. If any of the four 16-bit words does not match the backdoor keys
> programmed in the Flash array.
>
> 2. If the four 16-bit words are written in the wrong sequence.
>
> 3. If more than four 16-bit words are written.
>
> 4. If any of the four 16-bit words written are $0000 or $FFFF.
>
> 5. If the KEYACC bit does not remain set while the four 16-bit words are
> written.
>
> After the Backdoor Access Sequence has been correctly matched, the MCU
> will
> be unsecured. The Flash security byte can be programmed to the unsecure
> state, if desired.
>
> In the unsecure state, the user has full control of the contents of the
> four word Backdoor Key by programming it in bytes $FF00 - $FF07 of the
> Flash Protection/Options Field.
>
> The security as defined in the Flash Security/Options byte ($FF0F) is not
> changed by using the Backdoor Access Sequence to unsecure. The Backdoor
> Keys stored in addresses $FF00 - $FF07 are unaffected by the Backdoor
> Access Sequence. After the next reset sequence, the security state of the
> Flash module is determined by the Flash Security/Options byte ($FF0F). The
> Backdoor Access Sequence has no effect on the program and erase
> protections
> defined in the Flash Protection Register (FPROT).
>
> It is not possible to unsecure the MCU in Special Single Chip mode by the
> Backdoor Access Sequence via the Background Debug Mode.
>
> A further comment below.
>
> Hope this helps.
>
> Steve Russell
> Nohau Emulators > At 07:04 PM 7/6/2004, Steve Letkeman wrote:
> >So here's another question concerning security while running a
> >bootloader. If you have the processor in secure mode and you
> >want to update the firmware, then you would send it a command
> >(SCI/CAN etc) to use the back door key to unsecure the processor
> >in order to write new firmware to flash. At this point, is the
> >device not open to BDM activity? Or do you have to reset in order
> >for the BDM to work in which case the security would kick in at reset?
> >Am I missing something here?
>
> Yes, but we all do.
>
> There are 1500+ pages of documentation for each HCS-12 part, and new
> updates come out periodically. The best of the documentation is like that
> quoted above: Correct but terse.
>
> The worst, such as the early documentation for flash security, is what you
> might expect from a confused writer > >Thanks,
> >Steve > *************************************************************************
> Steve Russell mailto:
> Senior Software Design Engineer http://www.nohau.com
> Nohau Corporation phone: (408)866-1820 ext. 1873
> 51 East Campbell Avenue fax: (408)378-7869
> Campbell, CA 95008
> *************************************************************************
>




Mike,

If the security bits in flash are un-secured, you won't have to worry about
security. Most flash programmers set these bits to un-secured after a mass
erase, so you would likely be un-secured unless you have taken some
explicit steps to secure the part.

If the part is secured, and of a recent mask set, BDM just plain won't
work, except for "hardware" BDM commands accessing the registers. Even
this access is specified to work only in special single-chip mode, but it
might work in other modes.

If you have one of the original MC9S12DP256 Mask Set 0K36N parts you will
find no sign of functioning security. (You will also find a bunch of other
remarkable features you probably don't want, see the errata.)

What part and mask sets have you been using?

Steve Russell
Nohau Emulators

At 11:16 AM 7/7/2004, Michael Huslig wrote:
>Maybe I missed something at the beginning of this thread, but in my
>bootloader I don't have to unsecure the uP in order to update the flash.
>Only the startup and bootloader code is write-protected.
>
>Mike
>
>----- Original Message -----
>From: "Steve Letkeman" <>
>To: <>
>Sent: Wednesday, July 07, 2004 8:39 AM
>Subject: Re: [68HC12] disabling security in bootloader > > Thanks for the response, I did read through the documentation that you've
> > quoted below and what I don't find to be clear is this: If I unsecure
>the
> > MCU with the backdoor method in order to write to the flash memory,
> > does the BDM automatically become active without my program
> > specifically enabling it? The documentation does say that the BDM
> > is active while in unsecure mode, right?
> >
> > Any comments welcome,
> > Steve
> > ----- Original Message -----
> > From: Steve Russell
> > To:
> > Sent: Tuesday, July 06, 2004 9:49 PM
> > Subject: Re: [68HC12] disabling security in bootloader
> >
> >
> > Steve,
> >
> > I believe that the MC9S12DT256 documentation on the Freescale / Motorola
> > web site is the best source for how securing and un-securing should
>work.
> >
> >snip
> >
*************************************************************************
Steve Russell mailto:
Senior Software Design Engineer http://www.nohau.com
Nohau Corporation phone: (408)866-1820 ext. 1873
51 East Campbell Avenue fax: (408)378-7869
Campbell, CA 95008
*************************************************************************


I appreciate the help from this group, especially when a person
is going in circles. I figured the best way to get this sorted out
was to run some tests and then I ran into the problem of not
being able to secure the C32. Kinda makes it hard to test
the security features...If zeta_alph2002 says they can be
secured I'll keep trying...I reduced my S19 file to
S105FF0EFFFCF2
Also, I think Michael is correct in saying that the MCU
doesn't have to be unsecured in order for the bootloader
to write to flash, this was a mistake in my understanding
of the security feature.

Steve ----- Original Message -----
From: Steve Russell
To:
Sent: Wednesday, July 07, 2004 1:03 PM
Subject: Re: [68HC12] disabling security in bootloader Steve,

After re-reading the BDM documentation, I believe that the BDM is not
active or enabled after you unsecure with the backdoor key.

Reading between the lines, I think that you can set ENBDM in the BDMSTS
register with a "hardware" BDM command after the part is
unsecured. However, this is not explicitly stated, so experiment is indicated.

Again note that the securing logic has evolved from none on the very first
MC9S12DP256 mask set to pretty bullet-proof on the latest HCS-12 mask
sets. Just because things work one way on you trusty old development
system, doesn't mean that they will work the same way on the latest
production parts.

"The manufacturer reserves the right to improve the specifications without
notice."

Steve Russell
Nohau Emulators

At 06:39 AM 7/7/2004, Steve Letkeman wrote:
>Thanks for the response, I did read through the documentation that you've
> quoted below and what I don't find to be clear is this: If I unsecure the
> MCU with the backdoor method in order to write to the flash memory,
> does the BDM automatically become active without my program
>specifically enabling it? The documentation does say that the BDM
> is active while in unsecure mode, right?
>
>Any comments welcome,
>Steve
> ----- Original Message -----
> From: Steve Russell
> To:
> Sent: Tuesday, July 06, 2004 9:49 PM
> Subject: Re: [68HC12] disabling security in bootloader > Steve,
>
> I believe that the MC9S12DT256 documentation on the Freescale / Motorola
> web site is the best source for how securing and un-securing should work.
>
> Note that many of the older mask sets of MC9S12DP256 parts do not operate
> as described for the newest parts.
>
> Things to note in the quote from the documentation below:
>
> It clearly states that the correct backdoor key sequence "unsecures"
> the MCU.
>
> I take this to mean that the program in flash could then enable BDM, even
> if the MCU is in Normal Single Chip mode.
>
> For the MC9S12DT256 there are 2 bits in the KEYEN field. (Some HCS-12
> MCUs
> have only 1 bit for KEYEN. Also backdoor key words cannot be all 0 or all
> 1, a change from early MC9S12DP256 documnetation. Check the most recent
> specific documentation for your MCU.)
>
> From a recent copy of the flash documentation for the MC9S12DT256:
>
> 4.5.1 Unsecuring via the Backdoor Key Access
>
> The MCU may only be unsecured by using the Backdoor Key Access feature
> which requires knowledge of the contents of the Backdoor Keys (four 16-bit
> words programmed at addresses $FF00 - $FF07). If KEYEN[1:0] and the
> KEYACC bit is set, a write to a Backdoor Key address in the Flash array
> triggers a comparison between the written data and the Backdoor Key data
> stored in the Flash array. If all four words of data are written to the
> correct addresses in the correct order and the data matches the Backdoor
> Keys stored in the Flash array, the MCU will be unsecured. The data
> must be
> written to the Backdoor Keys sequentially staring with $FF00-1 and ending
> with $FF06-7. $0000 and $FFFF keys are not permitted. When the KEYACC bit
> is set, reads of the Flash array will return invalid data.
>
> The user code stored in the Flash array must have a method of receiving
> the
> Backdoor Key from an external stimulus. This external stimulus would
> typically be through one of the on-chip serial ports.
>
> If KEYEN[1:0] in the FSEC register, the MCU can be unsecured by the
> ackdoor Access Sequence described below:
>
> 1. Set the KEYACC bit in the Flash Configuration Register (FCNFG).
>
> 2. Write the correct four 16-bit words to Flash addresses $FF00 - $FF07
> sequentially starting with
> $FF00.
>
> 3. Clear the KEYACC bit.
>
> 4. If all four 16-bit words match the Backdoor Keys stored in Flash
> addresses $FF00 - $FF07, the MCU is unsecured and bits SEC[1:0] in the
> FSEC
> register are forced to the unsecure state of "10".
>
> The Backdoor Access Sequence is monitored by the internal Security State
> Machine. An illegal operation during the Backdoor Access Sequence will
> cause the Security State Machine to lock, leaving the MCU in the secured
> state. A reset of the MCU will cause the Security State Machine to exit
> the
> lock state and allow a new Backdoor Access Sequence to be attempted. The
> following illegal operations will lock the Security State Machine:
>
> 1. If any of the four 16-bit words does not match the backdoor keys
> programmed in the Flash array.
>
> 2. If the four 16-bit words are written in the wrong sequence.
>
> 3. If more than four 16-bit words are written.
>
> 4. If any of the four 16-bit words written are $0000 or $FFFF.
>
> 5. If the KEYACC bit does not remain set while the four 16-bit words are
> written.
>
> After the Backdoor Access Sequence has been correctly matched, the MCU
> will
> be unsecured. The Flash security byte can be programmed to the unsecure
> state, if desired.
>
> In the unsecure state, the user has full control of the contents of the
> four word Backdoor Key by programming it in bytes $FF00 - $FF07 of the
> Flash Protection/Options Field.
>
> The security as defined in the Flash Security/Options byte ($FF0F) is not
> changed by using the Backdoor Access Sequence to unsecure. The Backdoor
> Keys stored in addresses $FF00 - $FF07 are unaffected by the Backdoor
> Access Sequence. After the next reset sequence, the security state of the
> Flash module is determined by the Flash Security/Options byte ($FF0F). The
> Backdoor Access Sequence has no effect on the program and erase
> protections
> defined in the Flash Protection Register (FPROT).
>
> It is not possible to unsecure the MCU in Special Single Chip mode by the
> Backdoor Access Sequence via the Background Debug Mode.
>
> A further comment below.
>
> Hope this helps.
>
> Steve Russell
> Nohau Emulators > At 07:04 PM 7/6/2004, Steve Letkeman wrote:
> >So here's another question concerning security while running a
> >bootloader. If you have the processor in secure mode and you
> >want to update the firmware, then you would send it a command
> >(SCI/CAN etc) to use the back door key to unsecure the processor
> >in order to write new firmware to flash. At this point, is the
> >device not open to BDM activity? Or do you have to reset in order
> >for the BDM to work in which case the security would kick in at reset?
> >Am I missing something here?
>
> Yes, but we all do.
>
> There are 1500+ pages of documentation for each HCS-12 part, and new
> updates come out periodically. The best of the documentation is like that
> quoted above: Correct but terse.
>
> The worst, such as the early documentation for flash security, is what you
> might expect from a confused writer > >Thanks,
> >Steve > *************************************************************************
> Steve Russell mailto:
> Senior Software Design Engineer http://www.nohau.com
> Nohau Corporation phone: (408)866-1820 ext. 1873
> 51 East Campbell Avenue fax: (408)378-7869
> Campbell, CA 95008
> *************************************************************************
>


------
Yahoo! Groups Links

a.. To



Well if you really want to secure the MCU include this sample to your
code..

Be warn, you may have to remove and replace the MCU, but it will be
secured ;-).

org $FF00
dc.b $AA,$AA,$AA,$AA,$AA,$AA,$AA,$FF
dc.b $FF,$FF,$FF,$FF,$FF,$7F,$FF,$00

The key to securing is Address $FF00 - $FF07, $FF0D, $FF0F

--- In , "Steve Letkeman" <hc12list1@z...>
wrote:
> I appreciate the help from this group, especially when a person
> is going in circles. I figured the best way to get this sorted out
> was to run some tests and then I ran into the problem of not
> being able to secure the C32. Kinda makes it hard to test
> the security features...If zeta_alph2002 says they can be
> secured I'll keep trying...I reduced my S19 file to
> S105FF0EFFFCF2
> Also, I think Michael is correct in saying that the MCU
> doesn't have to be unsecured in order for the bootloader
> to write to flash, this was a mistake in my understanding
> of the security feature.
>
> Steve > ----- Original Message -----
> From: Steve Russell
> To:
> Sent: Wednesday, July 07, 2004 1:03 PM
> Subject: Re: [68HC12] disabling security in bootloader > Steve,
>
> After re-reading the BDM documentation, I believe that the BDM is
not
> active or enabled after you unsecure with the backdoor key.
>
> Reading between the lines, I think that you can set ENBDM in the
BDMSTS
> register with a "hardware" BDM command after the part is
> unsecured. However, this is not explicitly stated, so experiment
is indicated.
>
> Again note that the securing logic has evolved from none on the
very first
> MC9S12DP256 mask set to pretty bullet-proof on the latest HCS-12
mask
> sets. Just because things work one way on you trusty old
development
> system, doesn't mean that they will work the same way on the
latest
> production parts.
>
> "The manufacturer reserves the right to improve the
specifications without
> notice."
>
> Steve Russell
> Nohau Emulators
>
> At 06:39 AM 7/7/2004, Steve Letkeman wrote:
> >Thanks for the response, I did read through the documentation
that you've
> > quoted below and what I don't find to be clear is this: If I
unsecure the
> > MCU with the backdoor method in order to write to the flash
memory,
> > does the BDM automatically become active without my program
> >specifically enabling it? The documentation does say that the
BDM
> > is active while in unsecure mode, right?
> >
> >Any comments welcome,
> >Steve
> > ----- Original Message -----
> > From: Steve Russell
> > To:
> > Sent: Tuesday, July 06, 2004 9:49 PM
> > Subject: Re: [68HC12] disabling security in bootloader
> >
> >
> > Steve,
> >
> > I believe that the MC9S12DT256 documentation on the
Freescale / Motorola
> > web site is the best source for how securing and un-securing
should work.
> >
> > Note that many of the older mask sets of MC9S12DP256 parts do
not operate
> > as described for the newest parts.
> >
> > Things to note in the quote from the documentation below:
> >
> > It clearly states that the correct backdoor key
sequence "unsecures"
> > the MCU.
> >
> > I take this to mean that the program in flash could then
enable BDM, even
> > if the MCU is in Normal Single Chip mode.
> >
> > For the MC9S12DT256 there are 2 bits in the KEYEN field.
(Some HCS-12
> > MCUs
> > have only 1 bit for KEYEN. Also backdoor key words cannot be
all 0 or all
> > 1, a change from early MC9S12DP256 documnetation. Check the
most recent
> > specific documentation for your MCU.)
> >
> > From a recent copy of the flash documentation for the
MC9S12DT256:
> >
> > 4.5.1 Unsecuring via the Backdoor Key Access
> >
> > The MCU may only be unsecured by using the Backdoor Key
Access feature
> > which requires knowledge of the contents of the Backdoor Keys
(four 16-bit
> > words programmed at addresses $FF00 - $FF07). If KEYEN[1:0]
and the
> > KEYACC bit is set, a write to a Backdoor Key address in the
Flash array
> > triggers a comparison between the written data and the
Backdoor Key data
> > stored in the Flash array. If all four words of data are
written to the
> > correct addresses in the correct order and the data matches
the Backdoor
> > Keys stored in the Flash array, the MCU will be unsecured.
The data
> > must be
> > written to the Backdoor Keys sequentially staring with $FF00-
1 and ending
> > with $FF06-7. $0000 and $FFFF keys are not permitted. When
the KEYACC bit
> > is set, reads of the Flash array will return invalid data.
> >
> > The user code stored in the Flash array must have a method of
receiving
> > the
> > Backdoor Key from an external stimulus. This external
stimulus would
> > typically be through one of the on-chip serial ports.
> >
> > If KEYEN[1:0] in the FSEC register, the MCU can be
unsecured by the
> > ackdoor Access Sequence described below:
> >
> > 1. Set the KEYACC bit in the Flash Configuration Register
(FCNFG).
> >
> > 2. Write the correct four 16-bit words to Flash addresses
$FF00 - $FF07
> > sequentially starting with
> > $FF00.
> >
> > 3. Clear the KEYACC bit.
> >
> > 4. If all four 16-bit words match the Backdoor Keys stored in
Flash
> > addresses $FF00 - $FF07, the MCU is unsecured and bits SEC
[1:0] in the
> > FSEC
> > register are forced to the unsecure state of "10".
> >
> > The Backdoor Access Sequence is monitored by the internal
Security State
> > Machine. An illegal operation during the Backdoor Access
Sequence will
> > cause the Security State Machine to lock, leaving the MCU in
the secured
> > state. A reset of the MCU will cause the Security State
Machine to exit
> > the
> > lock state and allow a new Backdoor Access Sequence to be
attempted. The
> > following illegal operations will lock the Security State
Machine:
> >
> > 1. If any of the four 16-bit words does not match the
backdoor keys
> > programmed in the Flash array.
> >
> > 2. If the four 16-bit words are written in the wrong sequence.
> >
> > 3. If more than four 16-bit words are written.
> >
> > 4. If any of the four 16-bit words written are $0000 or $FFFF.
> >
> > 5. If the KEYACC bit does not remain set while the four 16-
bit words are
> > written.
> >
> > After the Backdoor Access Sequence has been correctly
matched, the MCU
> > will
> > be unsecured. The Flash security byte can be programmed to
the unsecure
> > state, if desired.
> >
> > In the unsecure state, the user has full control of the
contents of the
> > four word Backdoor Key by programming it in bytes $FF00 -
$FF07 of the
> > Flash Protection/Options Field.
> >
> > The security as defined in the Flash Security/Options byte
($FF0F) is not
> > changed by using the Backdoor Access Sequence to unsecure.
The Backdoor
> > Keys stored in addresses $FF00 - $FF07 are unaffected by the
Backdoor
> > Access Sequence. After the next reset sequence, the security
state of the
> > Flash module is determined by the Flash Security/Options byte
($FF0F). The
> > Backdoor Access Sequence has no effect on the program and
erase
> > protections
> > defined in the Flash Protection Register (FPROT).
> >
> > It is not possible to unsecure the MCU in Special Single Chip
mode by the
> > Backdoor Access Sequence via the Background Debug Mode.
> >
> > A further comment below.
> >
> > Hope this helps.
> >
> > Steve Russell
> > Nohau Emulators
> >
> >
> > At 07:04 PM 7/6/2004, Steve Letkeman wrote:
> > >So here's another question concerning security while running
a
> > >bootloader. If you have the processor in secure mode and you
> > >want to update the firmware, then you would send it a command
> > >(SCI/CAN etc) to use the back door key to unsecure the
processor
> > >in order to write new firmware to flash. At this point, is
the
> > >device not open to BDM activity? Or do you have to reset in
order
> > >for the BDM to work in which case the security would kick in
at reset?
> > >Am I missing something here?
> >
> > Yes, but we all do.
> >
> > There are 1500+ pages of documentation for each HCS-12 part,
and new
> > updates come out periodically. The best of the documentation
is like that
> > quoted above: Correct but terse.
> >
> > The worst, such as the early documentation for flash
security, is what you
> > might expect from a confused writer
> >
> >
> > >Thanks,
> > >Steve
> >
> >
> >
**********************************************************************
***
> > Steve Russell
mailto:stever@n...
> > Senior Software Design Engineer
http://www.nohau.com
> > Nohau Corporation phone: (408)866-
1820 ext. 1873
> > 51 East Campbell Avenue fax:
(408)378-7869
> > Campbell, CA 95008
> >
**********************************************************************
***
> > --------------------------------
----------
> Yahoo! Groups Links
>
> a.. To >
>




Steve,

I've been spending a lot of time securing and unsecuring the 9S12E64 derivative and I've come across a few things.

Your S-record example: S105FF0EFFFCF2
implies 0xFF0E = 0xFF, and 0xFF0F = 0xFC

I've had better luck using 0xFF0F = 0x80. This allows backdoor key access and still secures the flash.

Also, section 4.5.1 of the C32 flash document specifically states that "$0000 and $FFFF keys are not permitted.". I don't know if this means all 4 words cannot be 0x0000 or 0xFFFF or if this implies that NONE of the 4 backdoor key words can be either 0x0000 or 0xFFFF. To be on the safe side, I would set all 4 words (8 bytes) from 0xFF00 thru 0xFF07 to a value other than 0x0000 or 0xFFFF.

We've also been working on a method to permit our factory programmer to unsecure the flash and perform code verification. Unfortunately, it is only possible to unsecure the flash from code running in user mode, i.e. BDM is not active. This puts a slight damper on things.

In addition, the code which writes the backdoor keys CANNOT run from the flash itself and must run from RAM.

The solution we've come up with is to implement a small routine which gets executed via the Startup_ function prior to RAM initialization and calling main(). This routine tests 8 bytes stored at a fixed RAM location against a checksum in the next two bytes. If the 2-byte checksum matches, the routine copies a small routine into RAM which will load the 8 bytes from the RAM location into the backdoor key registers thus unsecuring the flash.

The unsecure procedure we use is as follows:

1. The BDM programmer enters special single chip mode and uses the hardware BDM command, WRITE_BD_WORD, to write the backdoor key bytes into the fixed RAM locations. This is permitted even if the flash is secured.

2. Trigger a reset using the RESET pin. This forces the user code to execute in normal single chip mode and unsecure the flash using the special routine.

3. The BDM programmer then enables the BDM by setting the ENBDM flag in the BDM Status Register using the hardware WRITE_BD_WORD command.

4. The BDM programmer activates the BDM using the hardware BACKGROUND command. At this point, the BDM in enabled and the flash is now unsecured.

5. The BDM programmer reads out the flash code to verify the programming.

This is a pain, but it's the only method we've come up with for now. If anybody has a better idea, I'd love to hear it.

Chris ------- Original Message -------
On Wed, 7 Jul 2004 14:08:18 -0600 Steve Letkeman wrote:I appreciate the help from this group, especially when a person

is going in circles. I figured the best way to get this sorted out

was to run some tests and then I ran into the problem of not

being able to secure the C32. Kinda makes it hard to test

the security features...If zeta_alph2002 says they can be

secured I'll keep trying...I reduced my S19 file to

S105FF0EFFFCF2

Also, I think Michael is correct in saying that the MCU

doesn't have to be unsecured in order for the bootloader

to write to flash, this was a mistake in my understanding

of the security feature.
Steve ----- Original Message -----

From: Steve Russell

To:

Sent: Wednesday, July 07, 2004 1:03 PM

Subject: Re: [68HC12] disabling security in bootloader Steve,
After re-reading the BDM documentation, I believe that the BDM is not

active or enabled after you unsecure with the backdoor key.
Reading between the lines, I think that you can set ENBDM in the BDMSTS

register with a "hardware" BDM command after the part is

unsecured. However, this is not explicitly stated, so experiment is indicated.
Again note that the securing logic has evolved from none on the very first

MC9S12DP256 mask set to pretty bullet-proof on the latest HCS-12 mask

sets. Just because things work one way on you trusty old development

system, doesn't mean that they will work the same way on the latest

production parts.
"The manufacturer reserves the right to improve the specifications without

notice."
Steve Russell

Nohau Emulators
At 06:39 AM 7/7/2004, Steve Letkeman wrote:

>Thanks for the response, I did read through the documentation that you've
Thanks for the response, I did read through the documentation that you've

> quoted below and what I don't find to be clear is this: If I unsecure the
quoted below and what I don't find to be clear is this: If I unsecure the

> MCU with the backdoor method in order to write to the flash memory,
MCU with the backdoor method in order to write to the flash memory,

> does the BDM automatically become active without my program
does the BDM automatically become active without my program

>specifically enabling it? The documentation does say that the BDM
specifically enabling it? The documentation does say that the BDM

> is active while in unsecure mode, right?
is active while in unsecure mode, right?

>


>Any comments welcome,
Any comments welcome,

>Steve
Steve

> ----- Original Message -----
----- Original Message -----

> From: Steve Russell
From: Steve Russell

> To:
To:

> Sent: Tuesday, July 06, 2004 9:49 PM
Sent: Tuesday, July 06, 2004 9:49 PM

> Subject: Re: [68HC12] disabling security in bootloader
Subject: Re: [68HC12] disabling security in bootloader

>


>


> Steve,
Steve,

>


> I believe that the MC9S12DT256 documentation on the Freescale / Motorola
I believe that the MC9S12DT256 documentation on the Freescale / Motorola

> web site is the best source for how securing and un-securing should work.
web site is the best source for how securing and un-securing should work.

>


> Note that many of the older mask sets of MC9S12DP256 parts do not operate
Note that many of the older mask sets of MC9S12DP256 parts do not operate

> as described for the newest parts.
as described for the newest parts.

>


> Things to note in the quote from the documentation below:
Things to note in the quote from the documentation below:

>


> It clearly states that the correct backdoor key sequence "unsecures"
It clearly states that the correct backdoor key sequence "unsecures"

> the MCU.
the MCU.

>


> I take this to mean that the program in flash could then enable BDM, even
I take this to mean that the program in flash could then enable BDM, even

> if the MCU is in Normal Single Chip mode.
if the MCU is in Normal Single Chip mode.

>


> For the MC9S12DT256 there are 2 bits in the KEYEN field. (Some HCS-12
For the MC9S12DT256 there are 2 bits in the KEYEN field. (Some HCS-12

> MCUs
MCUs

> have only 1 bit for KEYEN. Also backdoor key words cannot be all 0 or all
have only 1 bit for KEYEN. Also backdoor key words cannot be all 0 or all

> 1, a change from early MC9S12DP256 documnetation. Check the most recent
1, a change from early MC9S12DP256 documnetation. Check the most recent

> specific documentation for your MCU.)
specific documentation for your MCU.)

>


> From a recent copy of the flash documentation for the MC9S12DT256:
From a recent copy of the flash documentation for the MC9S12DT256:

>


> 4.5.1 Unsecuring via the Backdoor Key Access
4.5.1 Unsecuring via the Backdoor Key Access

>


> The MCU may only be unsecured by using the Backdoor Key Access feature
The MCU may only be unsecured by using the Backdoor Key Access feature

> which requires knowledge of the contents of the Backdoor Keys (four 16-bit
which requires knowledge of the contents of the Backdoor Keys (four 16-bit

> words programmed at addresses $FF00 - $FF07). If KEYEN[1:0] and the
words programmed at addresses $FF00 - $FF07). If KEYEN[1:0] and the

> KEYACC bit is set, a write to a Backdoor Key address in the Flash array
KEYACC bit is set, a write to a Backdoor Key address in the Flash array

> triggers a comparison between the written data and the Backdoor Key data
triggers a comparison between the written data and the Backdoor Key data

> stored in the Flash array. If all four words of data are written to the
stored in the Flash array. If all four words of data are written to the

> correct addresses in the correct order and the data matches the Backdoor
correct addresses in the correct order and the data matches the Backdoor

> Keys stored in the Flash array, the MCU will be unsecured. The data
Keys stored in the Flash array, the MCU will be unsecured. The data

> must be
must be

> written to the Backdoor Keys sequentially staring with $FF00-1 and ending
written to the Backdoor Keys sequentially staring with $FF00-1 and ending

> with $FF06-7. $0000 and $FFFF keys are not permitted. When the KEYACC bit
with $FF06-7. $0000 and $FFFF keys are not permitted. When the KEYACC bit

> is set, reads of the Flash array will return invalid data.
is set, reads of the Flash array will return invalid data.

>


> The user code stored in the Flash array must have a method of receiving
The user code stored in the Flash array must have a method of receiving

> the
the

> Backdoor Key from an external stimulus. This external stimulus would
Backdoor Key from an external stimulus. This external stimulus would

> typically be through one of the on-chip serial ports.
typically be through one of the on-chip serial ports.

>


> If KEYEN[1:0] in the FSEC register, the MCU can be unsecured by the
If KEYEN[1:0] in the FSEC register, the MCU can be unsecured by the

> ackdoor Access Sequence described below:
ackdoor Access Sequence described below:

>


> 1. Set the KEYACC bit in the Flash Configuration Register (FCNFG).
1. Set the KEYACC bit in the Flash Configuration Register (FCNFG).

>


> 2. Write the correct four 16-bit words to Flash addresses $FF00 - $FF07
2. Write the correct four 16-bit words to Flash addresses $FF00 - $FF07

> sequentially starting with
sequentially starting with

> $FF00.
$FF00.

>


> 3. Clear the KEYACC bit.
3. Clear the KEYACC bit.

>


> 4. If all four 16-bit words match the Backdoor Keys stored in Flash
4. If all four 16-bit words match the Backdoor Keys stored in Flash

> addresses $FF00 - $FF07, the MCU is unsecured and bits SEC[1:0] in the
addresses $FF00 - $FF07, the MCU is unsecured and bits SEC[1:0] in the

> FSEC
FSEC

> register are forced to the unsecure state of "10".
register are forced to the unsecure state of "10".

>


> The Backdoor Access Sequence is monitored by the internal Security State
The Backdoor Access Sequence is monitored by the internal Security State

> Machine. An illegal operation during the Backdoor Access Sequence will
Machine. An illegal operation during the Backdoor Access Sequence will

> cause the Security State Machine to lock, leaving the MCU in the secured
cause the Security State Machine to lock, leaving the MCU in the secured

> state. A reset of the MCU will cause the Security State Machine to exit
state. A reset of the MCU will cause the Security State Machine to exit

> the
the

> lock state and allow a new Backdoor Access Sequence to be attempted. The
lock state and allow a new Backdoor Access Sequence to be attempted. The

> following illegal operations will lock the Security State Machine:
following illegal operations will lock the Security State Machine:

>


> 1. If any of the four 16-bit words does not match the backdoor keys
1. If any of the four 16-bit words does not match the backdoor keys

> programmed in the Flash array.
programmed in the Flash array.

>


> 2. If the four 16-bit words are written in the wrong sequence.
2. If the four 16-bit words are written in the wrong sequence.

>


> 3. If more than four 16-bit words are written.
3. If more than four 16-bit words are written.

>


> 4. If any of the four 16-bit words written are $0000 or $FFFF.
4. If any of the four 16-bit words written are $0000 or $FFFF.

>


> 5. If the KEYACC bit does not remain set while the four 16-bit words are
5. If the KEYACC bit does not remain set while the four 16-bit words are

> written.
written.

>


> After the Backdoor Access Sequence has been correctly matched, the MCU
After the Backdoor Access Sequence has been correctly matched, the MCU

> will
will

> be unsecured. The Flash security byte can be programmed to the unsecure
be unsecured. The Flash security byte can be programmed to the unsecure

> state, if desired.
state, if desired.

>


> In the unsecure state, the user has full control of the contents of the
In the unsecure state, the user has full control of the contents of the

> four word Backdoor Key by programming it in bytes $FF00 - $FF07 of the
four word Backdoor Key by programming it in bytes $FF00 - $FF07 of the

> Flash Protection/Options Field.
Flash Protection/Options Field.

>


> The security as defined in the Flash Security/Options byte ($FF0F) is not
The security as defined in the Flash Security/Options byte ($FF0F) is not

> changed by using the Backdoor Access Sequence to unsecure. The Backdoor
changed by using the Backdoor Access Sequence to unsecure. The Backdoor

> Keys stored in addresses $FF00 - $FF07 are unaffected by the Backdoor
Keys stored in addresses $FF00 - $FF07 are unaffected by the Backdoor

> Access Sequence. After the next reset sequence, the security state of the
Access Sequence. After the next reset sequence, the security state of the

> Flash module is determined by the Flash Security/Options byte ($FF0F). The
Flash module is determined by the Flash Security/Options byte ($FF0F). The

> Backdoor Access Sequence has no effect on the program and erase
Backdoor Access Sequence has no effect on the program and erase

> protections
protections

> defined in the Flash Protection Register (FPROT).
defined in the Flash Protection Register (FPROT).

>


> It is not possible to unsecure the MCU in Special Single Chip mode by the
It is not possible to unsecure the MCU in Special Single Chip mode by the

> Backdoor Access Sequence via the Background Debug Mode.
Backdoor Access Sequence via the Background Debug Mode.

>


> A further comment below.
A further comment below.

>


> Hope this helps.
Hope this helps.

>


> Steve Russell
Steve Russell

> Nohau Emulators
Nohau Emulators

>


>


> At 07:04 PM 7/6/2004, Steve Letkeman wrote:
At 07:04 PM 7/6/2004, Steve Letkeman wrote:

> >So here's another question concerning security while running a
>So here's another question concerning security while running a
So here's another question concerning security while running a

> >bootloader. If you have the processor in secure mode and you
>bootloader. If you have the processor in secure mode and you
bootloader. If you have the processor in secure mode and you

> >want to update the firmware, then you would send it a command
>want to update the firmware, then you would send it a command
want to update the firmware, then you would send it a command

> >(SCI/CAN etc) to use the back door key to unsecure the processor
>(SCI/CAN etc) to use the back door key to unsecure the processor
(SCI/CAN etc) to use the back door key to unsecure the processor

> >in order to write new firmware to flash. At this point, is the
>in order to write new firmware to flash. At this point, is the
in order to write new firmware to flash. At this point, is the

> >device not open to BDM activity? Or do you have to reset in order
>device not open to BDM activity? Or do you have to reset in order
device not open to BDM activity? Or do you have to reset in order

> >for the BDM to work in which case the security would kick in at reset?
>for the BDM to work in which case the security would kick in at reset?
for the BDM to work in which case the security would kick in at reset?

> >Am I missing something here?
>Am I missing something here?
Am I missing something here?

>


> Yes, but we all do.
Yes, but we all do.

>


> There are 1500+ pages of documentation for each HCS-12 part, and new
There are 1500+ pages of documentation for each HCS-12 part, and new

> updates come out periodically. The best of the documentation is like that
updates come out periodically. The best of the documentation is like that

> quoted above: Correct but terse.
quoted above: Correct but terse.

>


> The worst, such as the early documentation for flash security, is what you
The worst, such as the early documentation for flash security, is what you

> might expect from a confused writer
might expect from a confused writer

>


>


> >Thanks,
>Thanks,
Thanks,

> >Steve
>Steve
Steve

>


>


> *************************************************************************
*************************************************************************

> Steve Russell mailto:
Steve Russell mailto:

> Senior Software Design Engineer Senior Software Design Engineer http://www.nohau.com

> Nohau Corporation phone: (408)866-1820 ext. 1873
Nohau Corporation phone: (408)866-1820 ext. 1873

> 51 East Campbell Avenue fax: (408)378-7869
51 East Campbell Avenue fax: (408)378-7869

> Campbell, CA 95008
Campbell, CA 95008

> *************************************************************************
*************************************************************************

>
------



Thanks for the comments and suggestion, Chris. I was using the same
values as you suggested despite my simplified S-record. Here is what
I know based on an afternoon of experimenting. The NoIce12 program
with the ComPod12 interface refuses to program location 0xFF0F when
downloading the proper S-record. The StarProg does the same. This
same procedure does work on a DG128. How I eventually got this to work
is by using the bootloader program itself. When it powers up it uses it's
flash routines to write to 0xFF0F to enable security and then writes
to 0xFF0D to enable write protection of the upper 4k to protect the
monitor program from changes. (The backdoor key was set during download)
When reset, everything is protected and secured.
I can then use the bootloader program itself to download
a user program without unsecuring the processor but my monitor program
won't allow any reads from memory until the part is unsecured. If I want full access
to read and write all memory, I send the backdoor key which loads a
routine to ram to compare to the flash key and then opens everything
up, whew...
As far as the procedure you are using, why not allow your bootloader to
unsecure memory (as you are doing) and then use the bootloader itself
to verify the flash contents without even using the BDM?

Thanks again for all the help,
Steve

----- Original Message -----
From: Chris Knight
To:
Sent: Wednesday, July 07, 2004 4:16 PM
Subject: RE: Re: [68HC12] disabling security in bootloader Steve,

I've been spending a lot of time securing and unsecuring the 9S12E64 derivative and I've come across a few things.

Your S-record example: S105FF0EFFFCF2
implies 0xFF0E = 0xFF, and 0xFF0F = 0xFC

I've had better luck using 0xFF0F = 0x80. This allows backdoor key access and still secures the flash.

Also, section 4.5.1 of the C32 flash document specifically states that "$0000 and $FFFF keys are not permitted.". I don't know if this means all 4 words cannot be 0x0000 or 0xFFFF or if this implies that NONE of the 4 backdoor key words can be either 0x0000 or 0xFFFF. To be on the safe side, I would set all 4 words (8 bytes) from 0xFF00 thru 0xFF07 to a value other than 0x0000 or 0xFFFF.

We've also been working on a method to permit our factory programmer to unsecure the flash and perform code verification. Unfortunately, it is only possible to unsecure the flash from code running in user mode, i.e. BDM is not active. This puts a slight damper on things.

In addition, the code which writes the backdoor keys CANNOT run from the flash itself and must run from RAM.

The solution we've come up with is to implement a small routine which gets executed via the Startup_ function prior to RAM initialization and calling main(). This routine tests 8 bytes stored at a fixed RAM location against a checksum in the next two bytes. If the 2-byte checksum matches, the routine copies a small routine into RAM which will load the 8 bytes from the RAM location into the backdoor key registers thus unsecuring the flash.

The unsecure procedure we use is as follows:

1. The BDM programmer enters special single chip mode and uses the hardware BDM command, WRITE_BD_WORD, to write the backdoor key bytes into the fixed RAM locations. This is permitted even if the flash is secured.

2. Trigger a reset using the RESET pin. This forces the user code to execute in normal single chip mode and unsecure the flash using the special routine.

3. The BDM programmer then enables the BDM by setting the ENBDM flag in the BDM Status Register using the hardware WRITE_BD_WORD command.

4. The BDM programmer activates the BDM using the hardware BACKGROUND command. At this point, the BDM in enabled and the flash is now unsecured.

5. The BDM programmer reads out the flash code to verify the programming.

This is a pain, but it's the only method we've come up with for now. If anybody has a better idea, I'd love to hear it.

Chris ------- Original Message -------
On Wed, 7 Jul 2004 14:08:18 -0600 Steve Letkeman wrote:I appreciate the help from this group, especially when a person

is going in circles. I figured the best way to get this sorted out

was to run some tests and then I ran into the problem of not

being able to secure the C32. Kinda makes it hard to test

the security features...If zeta_alph2002 says they can be

secured I'll keep trying...I reduced my S19 file to

S105FF0EFFFCF2

Also, I think Michael is correct in saying that the MCU

doesn't have to be unsecured in order for the bootloader

to write to flash, this was a mistake in my understanding

of the security feature.
Steve ----- Original Message -----

From: Steve Russell

To:

Sent: Wednesday, July 07, 2004 1:03 PM

Subject: Re: [68HC12] disabling security in bootloader Steve,
After re-reading the BDM documentation, I believe that the BDM is not

active or enabled after you unsecure with the backdoor key.
Reading between the lines, I think that you can set ENBDM in the BDMSTS

register with a "hardware" BDM command after the part is

unsecured. However, this is not explicitly stated, so experiment is indicated.
Again note that the securing logic has evolved from none on the very first

MC9S12DP256 mask set to pretty bullet-proof on the latest HCS-12 mask

sets. Just because things work one way on you trusty old development

system, doesn't mean that they will work the same way on the latest

production parts.
"The manufacturer reserves the right to improve the specifications without

notice."
Steve Russell

Nohau Emulators
At 06:39 AM 7/7/2004, Steve Letkeman wrote:

>Thanks for the response, I did read through the documentation that you've
Thanks for the response, I did read through the documentation that you've

> quoted below and what I don't find to be clear is this: If I unsecure the
quoted below and what I don't find to be clear is this: If I unsecure the

> MCU with the backdoor method in order to write to the flash memory,
MCU with the backdoor method in order to write to the flash memory,

> does the BDM automatically become active without my program
does the BDM automatically become active without my program

>specifically enabling it? The documentation does say that the BDM
specifically enabling it? The documentation does say that the BDM

> is active while in unsecure mode, right?
is active while in unsecure mode, right?

>


>Any comments welcome,
Any comments welcome,

>Steve
Steve

> ----- Original Message -----
----- Original Message -----

> From: Steve Russell
From: Steve Russell

> To:
To:

> Sent: Tuesday, July 06, 2004 9:49 PM
Sent: Tuesday, July 06, 2004 9:49 PM

> Subject: Re: [68HC12] disabling security in bootloader
Subject: Re: [68HC12] disabling security in bootloader

>


>


> Steve,
Steve,

>


> I believe that the MC9S12DT256 documentation on the Freescale / Motorola
I believe that the MC9S12DT256 documentation on the Freescale / Motorola

> web site is the best source for how securing and un-securing should work.
web site is the best source for how securing and un-securing should work.

>


> Note that many of the older mask sets of MC9S12DP256 parts do not operate
Note that many of the older mask sets of MC9S12DP256 parts do not operate

> as described for the newest parts.
as described for the newest parts.

>


> Things to note in the quote from the documentation below:
Things to note in the quote from the documentation below:

>


> It clearly states that the correct backdoor key sequence "unsecures"
It clearly states that the correct backdoor key sequence "unsecures"

> the MCU.
the MCU.

>


> I take this to mean that the program in flash could then enable BDM, even
I take this to mean that the program in flash could then enable BDM, even

> if the MCU is in Normal Single Chip mode.
if the MCU is in Normal Single Chip mode.

>


> For the MC9S12DT256 there are 2 bits in the KEYEN field. (Some HCS-12
For the MC9S12DT256 there are 2 bits in the KEYEN field. (Some HCS-12

> MCUs
MCUs

> have only 1 bit for KEYEN. Also backdoor key words cannot be all 0 or all
have only 1 bit for KEYEN. Also backdoor key words cannot be all 0 or all

> 1, a change from early MC9S12DP256 documnetation. Check the most recent
1, a change from early MC9S12DP256 documnetation. Check the most recent

> specific documentation for your MCU.)
specific documentation for your MCU.)

>


> From a recent copy of the flash documentation for the MC9S12DT256:
From a recent copy of the flash documentation for the MC9S12DT256:

>


> 4.5.1 Unsecuring via the Backdoor Key Access
4.5.1 Unsecuring via the Backdoor Key Access

>


> The MCU may only be unsecured by using the Backdoor Key Access feature
The MCU may only be unsecured by using the Backdoor Key Access feature

> which requires knowledge of the contents of the Backdoor Keys (four 16-bit
which requires knowledge of the contents of the Backdoor Keys (four 16-bit

> words programmed at addresses $FF00 - $FF07). If KEYEN[1:0] and the
words programmed at addresses $FF00 - $FF07). If KEYEN[1:0] and the

> KEYACC bit is set, a write to a Backdoor Key address in the Flash array
KEYACC bit is set, a write to a Backdoor Key address in the Flash array

> triggers a comparison between the written data and the Backdoor Key data
triggers a comparison between the written data and the Backdoor Key data

> stored in the Flash array. If all four words of data are written to the
stored in the Flash array. If all four words of data are written to the

> correct addresses in the correct order and the data matches the Backdoor
correct addresses in the correct order and the data matches the Backdoor

> Keys stored in the Flash array, the MCU will be unsecured. The data
Keys stored in the Flash array, the MCU will be unsecured. The data

> must be
must be

> written to the Backdoor Keys sequentially staring with $FF00-1 and ending
written to the Backdoor Keys sequentially staring with $FF00-1 and ending

> with $FF06-7. $0000 and $FFFF keys are not permitted. When the KEYACC bit
with $FF06-7. $0000 and $FFFF keys are not permitted. When the KEYACC bit

> is set, reads of the Flash array will return invalid data.
is set, reads of the Flash array will return invalid data.

>


> The user code stored in the Flash array must have a method of receiving
The user code stored in the Flash array must have a method of receiving

> the
the

> Backdoor Key from an external stimulus. This external stimulus would
Backdoor Key from an external stimulus. This external stimulus would

> typically be through one of the on-chip serial ports.
typically be through one of the on-chip serial ports.

>


> If KEYEN[1:0] in the FSEC register, the MCU can be unsecured by the
If KEYEN[1:0] in the FSEC register, the MCU can be unsecured by the

> ackdoor Access Sequence described below:
ackdoor Access Sequence described below:

>


> 1. Set the KEYACC bit in the Flash Configuration Register (FCNFG).
1. Set the KEYACC bit in the Flash Configuration Register (FCNFG).

>


> 2. Write the correct four 16-bit words to Flash addresses $FF00 - $FF07
2. Write the correct four 16-bit words to Flash addresses $FF00 - $FF07

> sequentially starting with
sequentially starting with

> $FF00.
$FF00.

>


> 3. Clear the KEYACC bit.
3. Clear the KEYACC bit.

>


> 4. If all four 16-bit words match the Backdoor Keys stored in Flash
4. If all four 16-bit words match the Backdoor Keys stored in Flash

> addresses $FF00 - $FF07, the MCU is unsecured and bits SEC[1:0] in the
addresses $FF00 - $FF07, the MCU is unsecured and bits SEC[1:0] in the

> FSEC
FSEC

> register are forced to the unsecure state of "10".
register are forced to the unsecure state of "10".

>


> The Backdoor Access Sequence is monitored by the internal Security State
The Backdoor Access Sequence is monitored by the internal Security State

> Machine. An illegal operation during the Backdoor Access Sequence will
Machine. An illegal operation during the Backdoor Access Sequence will

> cause the Security State Machine to lock, leaving the MCU in the secured
cause the Security State Machine to lock, leaving the MCU in the secured

> state. A reset of the MCU will cause the Security State Machine to exit
state. A reset of the MCU will cause the Security State Machine to exit

> the
the

> lock state and allow a new Backdoor Access Sequence to be attempted. The
lock state and allow a new Backdoor Access Sequence to be attempted. The

> following illegal operations will lock the Security State Machine:
following illegal operations will lock the Security State Machine:

>


> 1. If any of the four 16-bit words does not match the backdoor keys
1. If any of the four 16-bit words does not match the backdoor keys

> programmed in the Flash array.
programmed in the Flash array.

>


> 2. If the four 16-bit words are written in the wrong sequence.
2. If the four 16-bit words are written in the wrong sequence.

>


> 3. If more than four 16-bit words are written.
3. If more than four 16-bit words are written.

>


> 4. If any of the four 16-bit words written are $0000 or $FFFF.
4. If any of the four 16-bit words written are $0000 or $FFFF.

>


> 5. If the KEYACC bit does not remain set while the four 16-bit words are
5. If the KEYACC bit does not remain set while the four 16-bit words are

> written.
written.

>


> After the Backdoor Access Sequence has been correctly matched, the MCU
After the Backdoor Access Sequence has been correctly matched, the MCU

> will
will

> be unsecured. The Flash security byte can be programmed to the unsecure
be unsecured. The Flash security byte can be programmed to the unsecure

> state, if desired.
state, if desired.

>


> In the unsecure state, the user has full control of the contents of the
In the unsecure state, the user has full control of the contents of the

> four word Backdoor Key by programming it in bytes $FF00 - $FF07 of the
four word Backdoor Key by programming it in bytes $FF00 - $FF07 of the

> Flash Protection/Options Field.
Flash Protection/Options Field.

>


> The security as defined in the Flash Security/Options byte ($FF0F) is not
The security as defined in the Flash Security/Options byte ($FF0F) is not

> changed by using the Backdoor Access Sequence to unsecure. The Backdoor
changed by using the Backdoor Access Sequence to unsecure. The Backdoor

> Keys stored in addresses $FF00 - $FF07 are unaffected by the Backdoor
Keys stored in addresses $FF00 - $FF07 are unaffected by the Backdoor

> Access Sequence. After the next reset sequence, the security state of the
Access Sequence. After the next reset sequence, the security state of the

> Flash module is determined by the Flash Security/Options byte ($FF0F). The
Flash module is determined by the Flash Security/Options byte ($FF0F). The

> Backdoor Access Sequence has no effect on the program and erase
Backdoor Access Sequence has no effect on the program and erase

> protections
protections

> defined in the Flash Protection Register (FPROT).
defined in the Flash Protection Register (FPROT).

>


> It is not possible to unsecure the MCU in Special Single Chip mode by the
It is not possible to unsecure the MCU in Special Single Chip mode by the

> Backdoor Access Sequence via the Background Debug Mode.
Backdoor Access Sequence via the Background Debug Mode.

>


> A further comment below.
A further comment below.

>


> Hope this helps.
Hope this helps.

>


> Steve Russell
Steve Russell

> Nohau Emulators
Nohau Emulators

>


>


> At 07:04 PM 7/6/2004, Steve Letkeman wrote:
At 07:04 PM 7/6/2004, Steve Letkeman wrote:

> >So here's another question concerning security while running a
>So here's another question concerning security while running a
So here's another question concerning security while running a

> >bootloader. If you have the processor in secure mode and you
>bootloader. If you have the processor in secure mode and you
bootloader. If you have the processor in secure mode and you

> >want to update the firmware, then you would send it a command
>want to update the firmware, then you would send it a command
want to update the firmware, then you would send it a command

> >(SCI/CAN etc) to use the back door key to unsecure the processor
>(SCI/CAN etc) to use the back door key to unsecure the processor
(SCI/CAN etc) to use the back door key to unsecure the processor

> >in order to write new firmware to flash. At this point, is the
>in order to write new firmware to flash. At this point, is the
in order to write new firmware to flash. At this point, is the

> >device not open to BDM activity? Or do you have to reset in order
>device not open to BDM activity? Or do you have to reset in order
device not open to BDM activity? Or do you have to reset in order

> >for the BDM to work in which case the security would kick in at reset?
>for the BDM to work in which case the security would kick in at reset?
for the BDM to work in which case the security would kick in at reset?

> >Am I missing something here?
>Am I missing something here?
Am I missing something here?

>


> Yes, but we all do.
Yes, but we all do.

>


> There are 1500+ pages of documentation for each HCS-12 part, and new
There are 1500+ pages of documentation for each HCS-12 part, and new

> updates come out periodically. The best of the documentation is like that
updates come out periodically. The best of the documentation is like that

> quoted above: Correct but terse.
quoted above: Correct but terse.

>


> The worst, such as the early documentation for flash security, is what you
The worst, such as the early documentation for flash security, is what you

> might expect from a confused writer
might expect from a confused writer

>


>


> >Thanks,
>Thanks,
Thanks,

> >Steve
>Steve
Steve

>


>


> *************************************************************************
*************************************************************************

> Steve Russell mailto:
Steve Russell mailto:

> Senior Software Design Engineer Senior Software Design Engineer http://www.nohau.com

> Nohau Corporation phone: (408)866-1820 ext. 1873
Nohau Corporation phone: (408)866-1820 ext. 1873

> 51 East Campbell Avenue fax: (408)378-7869
51 East Campbell Avenue fax: (408)378-7869

> Campbell, CA 95008
Campbell, CA 95008

> *************************************************************************
*************************************************************************

>
------

------
Yahoo! Groups Links

a.. To