Code Security Module (CSM)
www.ti.com
54
SPRUI07–March 2020
Submit Documentation Feedback
Copyright © 2020, Texas Instruments Incorporated
System Control and Interrupts
Figure 1-11. CSM Status and Control Register (CSMSCR)
15 14 7 6 1 0
FORCESEC Reserved Reserved SECURE
R/W-1 R-0 R-10111 R-1
LEGEND: R/W = Read/Write; R = Read only; -n = value after reset
(1)
This register is EALLOW protected. Refer to Section 1.5.2 for more information.
Table 1-13. CSM Status and Control Register (CSMSCR) Field Descriptions
Bits Field Value Description
(1)
15 FORCESEC Writing a 1 clears the KEY registers and secures the device.
0 A read always returns a zero.
1 Clears the KEY registers and secures the device. The password match flow described in
Section 1.2.3.2 must be followed to unsecure the device again.
14-1 Reserved Reserved
0 SECURE Read-only bit that reflects the security state of the device.
0 Device is unsecure (CSM unlocked).
1 Device is secure (CSM locked).
1.2.3.1 Environments That Require Security Unlocking
Following are the typical situations under which unsecuring can be required:
• Code development using debuggers (such as Code Composer Studio™).
This is the most common environment during the design phase of a product.
• Flash programming using TI's flash utilities such as Code Composer Studio™ F28xx On-Chip Flash
Programmer plug-in.
Flash programming is common during code development and testing. Once the user supplies the
necessary password, the flash utilities disable the security logic before attempting to program the flash.
The flash utilities can disable the code security logic in new devices without any authorization, since
new devices come with an erased flash. However, reprogramming devices (that already contain a
custom password) require the password to be supplied to the flash utilities in order to unlock the device
to enable programming. In custom programming solutions that use the flash API supplied by TI
unlocking the CSM can be avoided by executing the flash programming algorithms from secure
memory.
• Custom environment defined by the application
In addition to the above, access to secure memory contents can be required in situations such as:
• Using the on-chip bootloader to load code or data into secure SARAM or to erase/program the flash.
• Executing code from on-chip unsecure memory and requiring access to secure memory for lookup
table. This is not a suggested operating condition as supplying the password from external code could
compromise code security.
The unsecuring sequence is identical in all the above situations. This sequence is referred to as the
password match flow (PMF) for simplicity. Figure 1-12 explains the sequence of operation that is required
every time the user attempts to unsecure a device. A code example is listed for clarity.
To Next Page
Loading...
Need help?
General
