2.4 Do's and Don'ts to Protect Security Logic
2.4.1 Do's
2.4.2 Don'ts
2.5 CSM Features - Summary
Do's and Don'ts to Protect Security Logic
www.ti.com
• To keep the debug and code development phase simple, use the device in the unsecure mode; i.e.,
use all 128 bits as ones in the password locations (or use a password that is easy to remember). Use
a password after the development phase when the code is frozen.
• Recheck the password stored in the password locations before programming the COFF file using flash
utilities.
• The flow of code execution can freely toggle back and forth between secure memory and unsecure
memory without compromising security. To access data variables located in secure memory when the
device is secured, code execution must currently be running from secure memory.
• Program locations 0x33 FF80 - 0x33 FFF5 with 0x0000 when using the CSM.
• If code security is desired, do not embed the password in your application anywhere other than in the
password locations or security can be compromised.
• Do not use 128 bits of all zeros as the password. This automatically secures the device, regardless of
the contents of the KEY register. The device is not debuggable nor reprogrammable.
• Do not pull a reset during an erase operation on the flash array. This can leave either zeros or an
unknown value in the password locations. If the password locations are all zero during a reset, the
device will always be secure, regardless of the contents of the KEY register.
• Do not use locations 0x33 FF80 - 0x33 FFF5 to store program and/or data. These locations should be
programmed to 0x0000 when using the CSM.
1. The flash is secured after a reset until the password match flow described in Section 2.3.2 is executed.
2. The standard way of running code out of the flash is to program the flash with the code and power up
the DSP. Since instruction fetches are always allowed from secure memory, regardless of the state of
the CSM, the code functions correctly even without executing the password match flow.
3. Secure memory cannot be modified by code executing from unsecure memory while the device is
secured.
4. Secure memory cannot be read from any code running from unsecure memory while the device is
secured.
5. Secure memory cannot be read or written to by the debugger (i.e., Code Composer Studioâ„¢) at any
time that the device is secured.
6. Complete access to secure memory from both the CPU code and the debugger is granted while the
device is unsecured.
Code Security Module (CSM)36 SPRUFB0C – September 2007 – Revised May 2009
Submit Documentation Feedback
To Next Page
Loading...
Need help?
General
