The following are the typical situations under which unsecuring can be required:
- Code development using debuggers (such as Code
Composer Studio™ IDE). 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™ On-Chip Flash Programmer
plug-in or the Uniflash tool. Flash programming is
common during code development and testing. Once
the necessary password is supplied, 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 to unlock the
device to enable programming. In custom
programming 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 and program the
Flash.
- Executing code from on-chip unsecure memory and
requiring access to secure memory for the lookup
table. This is not a suggested operating condition
as supplying the password from external code can
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 3-21 explains the sequence of operation that is required every time the user attempts to unsecure a particular zone. A code example is listed for clarity.