Code Security Module (CSM)
147
SPRUH22I – April 2012 – Revised November 2019
Copyright © 2012–2019, Texas Instruments Incorporated
System Control and Interrupts
1.10.2 CSM Impact on Other On-Chip Resources
On this device, not all memories on the master subsystem and control subsystem are secure (for
example, C2/C3 on the master system and M0/M1/L2/L3 on the control subsystem and Shared RAM). To
avoid any potential hacking when the device is in a default state (post reset), accesses (all types) to all
memories (secure as well as non-secure, except Boot ROM & OTP) and to the analog subsystem, are
disabled until proper security initialization is done. That is, just after reset, none of the memory resources
except boot ROM and OTP are accessible.
The following are the steps required after reset (any type of reset) to initialize security on the device.
•
Dummy Read to address location OTPSECLOCK in OTP
•
Dummy read to address location Z1_GRABSECT in Flash
•
Dummy read to address location Z1_GRABRAM in Flash
•
Dummy read to address location Z1_EXEONLY in Flash
•
Dummy read to address location Z2_GRABSECT in Flash
•
Dummy read to address location Z2_GRABRAM in Flash
•
Dummy read to address location Z2_EXEONLY in Flash
Control subsystem
•
Dummy Read to address location OTPSECLOCK in OTP by M3 software
•
Dummy read to address location EXEONLY in flash
1.10.3 Incorporating Code Security in User Applications
Code security is typically not employed in the development phase of a project; however, security may be
desired once the application code is finalized. Before such code is programmed in the flash memory, a
CSM password should be chosen to secure the zone. Once a CSM password is in place for a zone, the
zone is secured (that is, programming a password at the appropriate locations and either performing a
device reset or setting the FORCESEC bit (CSMSCR.15) is the action that secures the device). From that
time on, access to debug the contents of secure memory by any means (via JTAG, code running off
external/on-chip memory, and so on) requires a valid password. A password is not needed to run the code
out of secure memory (such as in end-application usage); however, access to secure memory contents for
debug purpose requires a password.
If the code-security feature is used, any one of the following directives must be used when a function
residing in secure memory calls another function which belongs to a different secure zone or to unsecure
memory:
•
Use unsecure memory as stack
•
Switch stack to unsecure memory before calling the function
•
Unlock security before calling the function
Note that the above directives apply for any address-based-parameters passed on to the called function,
basically making sure that the called function can read/write to these address-based parameters.
Table 1-29. OTPSECLOCK - Reserved Locations in OTP Memory
Memory Address
Register Name
Reset Values
Register Description
0x68-0800
OTPSECLOCK
User Defined
Contains one time
programmable settings for
security.
Table 1-30. M3 Zone1 - Reserved Locations in Flash Memory
Memory Address
Register Name
Reset Values
Register Description
0x20-0000
Z1_CSMPSWD0
User Defined
Low word (32-bit) of the 128-bit
CSM password for zone1
