1.2.4 Do's and Don'ts to Protect Security Logic
1.2.4.1 Do's
• To keep the debug and code development phase simple, use the device in the unsecure mode; that is, 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 0x3F 7F80 - 0x3F 7FF5 with 0x0000 when using the CSM.
1.2.4.2 Don'ts
• 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 0x3F 7F80 - 0x3F 7FF5 to store program and/or data. These locations should be
programmed to 0x0000 when using the CSM.
1.2.5 CSM Features - Summary
1. The flash is secured after a reset until the password match flow described in
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
device. 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 (Code Composer Studio™ IDE) 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.
System Control and Interrupts
60
TMS320x2806x Microcontrollers
SPRUH18I – JANUARY 2011 – REVISED JUNE 2022
Copyright © 2022 Texas Instruments Incorporated
Содержание TMS320 2806 Series
Страница 2: ......