M16C Security

I want to add security to an M16C project. The manual in Figure 1.30.2
shows the 7 security bytes ID1 thru ID7 on the left-hand side, or what
I would call the lower address side of the four bytes, whereas the text
defines the addresses as the high side. The two options in the
sect30.inc file would be either:

One:
                        .section         vectors,ROMDATA
                        .org               0fffdch
UDI:                  .addr             dummy_int
                        .byte             01h                        ;
security byte ID1
OVER_FLOW:  .addr  etc...


Two:
                        .section         vectors,ROMDATA
                        .org               0fffdch
UDI:                  .byte             01h                        ;
security byte ID1
                        .addr             dummy_int
OVER_FLOW:  .byte  etc...

Does anyone have experience with the correct method?
Ron

>I want to add security to an M16C project. The manual in Figure 1.30.2
>shows the 7 security bytes ID1 thru ID7 on the left-hand side, or what
>I would call the lower address side of the four bytes, whereas the text
>defines the addresses as the high side. The two options in the
>sect30.inc file would be either:
>
>One:
>                        .section         vectors,ROMDATA
>                        .org               0fffdch
>UDI:                  .addr             dummy_int
>                        .byte             01h                        ;
>security byte ID1
>OVER_FLOW:  .addr  etc...
>
>
>Two:
>                        .section         vectors,ROMDATA
>                        .org               0fffdch
>UDI:                  .byte             01h                        ;
>security byte ID1
>                        .addr             dummy_int
>OVER_FLOW:  .byte  etc...
>
>Does anyone have experience with the correct method?
>Ron

The Datasheet clearly states:

<------- beginn quote -------->
The ID code consists of 8-bit data,the areas of which,beginning with
the first byte,are:

0FFFDF16,0FFFE316,0FFFEB16,0FFFEF16,0FFFF316,0FFFF716,and 0FFFFB16.
<------- end quote -------->

An excerpt of my ".mot" file follows to hopefully further clear the
situation for you. Note, I replaced my ID bytes with "xx". I seperated
four bytes for readability and seperated the S record start also. The
checksum is represented here as YY. 

S214 0FFFDC 5AF00Fxx 5AF00Fxx 5AF00F00 5AF00Fxx YY
S214 0FFFEC 5AF00Fxx B0EF0Fxx 5AF00Fxx 5AF00Fxx YY
S208 0FFFFC 00F00Fxx YY

You can see that there is one spot where you would expect an ID byte
but that this one is not used.

I'm not that sure, but I would say both of your versions are wrong in
that an address consumes FOUR bytes, hence the .byte instruction that
follows your .addr statement or is in front of it respectively also
generates one ADITIONAL byte of code. I could be wrong here though.
Apart from this your "One" version IMHO comes closer.

Do you intend to access the ID bytes from within your firmware code?
IMHO there is no need for this since from what I know the ID code
protects the uC from being read out or reprogrammed unless the propper
ID code is passed in to the uC from the firmware programming process
over the serial interface (or paralell programmer). The lmc30
statement also places the bytes to the propper locations when it
generates the .mot file so....

HTH

Markus

Markus Zingg wrote:
> >I want to add security to an M16C project. The manual in Figure 1.30.2
> >shows the 7 security bytes ID1 thru ID7 on the left-hand side, or what
> >I would call the lower address side of the four bytes, whereas the text
> >defines the addresses as the high side. The two options in the
> >sect30.inc file would be either:
> >
> >One:
> >                        .section         vectors,ROMDATA
> >                        .org               0fffdch
> >UDI:                  .addr             dummy_int
> >                        .byte             01h                        ;
> >security byte ID1
> >OVER_FLOW:  .addr  etc...
> >
> >
> >Two:
> >                        .section         vectors,ROMDATA
> >                        .org               0fffdch
> >UDI:                  .byte             01h                        ;
> >security byte ID1
> >                        .addr             dummy_int
> >OVER_FLOW:  .byte  etc...
> >
> >Does anyone have experience with the correct method?
> >Ron
>
> The Datasheet clearly states:
>
> <------- beginn quote -------->
> The ID code consists of 8-bit data,the areas of which,beginning with
> the first byte,are:
>
> 0FFFDF16,0FFFE316,0FFFEB16,0FFFEF16,0FFFF316,0FFFF716,and 0FFFFB16.
> <------- end quote -------->
>
> An excerpt of my ".mot" file follows to hopefully further clear the
> situation for you. Note, I replaced my ID bytes with "xx". I seperated
> four bytes for readability and seperated the S record start also. The
> checksum is represented here as YY.
>
> S214 0FFFDC 5AF00Fxx 5AF00Fxx 5AF00F00 5AF00Fxx YY
> S214 0FFFEC 5AF00Fxx B0EF0Fxx 5AF00Fxx 5AF00Fxx YY
> S208 0FFFFC 00F00Fxx YY
>
> You can see that there is one spot where you would expect an ID byte
> but that this one is not used.
>
> I'm not that sure, but I would say both of your versions are wrong in
> that an address consumes FOUR bytes, hence the .byte instruction that
> follows your .addr statement or is in front of it respectively also
> generates one ADITIONAL byte of code. I could be wrong here though.
> Apart from this your "One" version IMHO comes closer.
>
> Do you intend to access the ID bytes from within your firmware code?
> IMHO there is no need for this since from what I know the ID code
> protects the uC from being read out or reprogrammed unless the propper
> ID code is passed in to the uC from the firmware programming process
> over the serial interface (or paralell programmer). The lmc30
> statement also places the bytes to the propper locations when it
> generates the .mot file so....
>
> HTH
>
> Markus

The "One" version was what I thought would be correct, it was the
figure that appeared confusing. The .addr seems to insert only 3-bytes.
What were you using instead?

Ron

>The "One" version was what I thought would be correct, it was the
>figure that appeared confusing. The .addr seems to insert only 3-bytes.

Provided it really inserts only 3 bytes you are right, but I somehow
doubt it. Well, you could eaisly verify this with a compile and then
look at the debugger or so.

>What were you using instead?

Nothing. :)

Seriousely, we have a networded product and when it comes to
distinguishing devices we use the MAC address which we individually
"patch" into the MOT file before the uC is programmed.

When it comes to the ID code, we are happy to know that it requires
someone else to have OUR ID code in order to read out the flash.
That's sufficient for our needs since a brute force attack seems
unfeasable considering the latency of the RS232 port and the asociated
commands to set the ID. 

The ID code is stored into the MOT file at the point in time you
invoce lmc30 which takes our ID's on the command line.

Markus

ronkrem wrote:
> I want to add security to an M16C project. The manual in Figure 1.30.2
> shows the 7 security bytes ID1 thru ID7 on the left-hand side, or what
> I would call the lower address side of the four bytes, whereas the text
> defines the addresses as the high side. The two options in the
> sect30.inc file would be either:
> 
> Does anyone have experience with the correct method?
> Ron

Not sure if you consider my method "correct", but it surely works:

	.lword	int_vect1 + 012000000h
	.lword	int_vect2 + 034000000h
	.lword	int_vect3 + 056000000h
	.lword	int_vect4 + 078000000h

Where 12, 34, 56, 78 are the ID values.

The ID bytes are the most significant (unused) bytes of addresses.