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
|