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:
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.
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....
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?
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.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.