SPRUJF2A March 2026 – March 2026 AM13E23019
Figure 7-2 illustrates the boot and startup sequence in security enabled applications. At BOOTRST, TI Bootcode starts executing. According to the device's lifecycle status, the device will execute the corresponding process as regular boot, secure boot, or retest flow.
The Bootloader (BSL) can be invoked by Bootcode when a valid bootloader invocation condition is detected. The Bootloader provides a method to program and verify the device Flash memory through a standard serial interface (see Section 7.4).
During the Bootcode execution, the Debug Subsystem Mailbox (DSSM) enables a debug probe to pass messages to the target device through the Serial Wire Debug (SWD) interface, and for the target device to return data to the debug probe. In Bootcode, the DSSM helps with the transmission of commands to the device during boot, including lifecycle state change requests, authenticating the debug probe for password-protected debug, mass erase, and factory reset operations.
After a successful boot, the Bootcode issues BOOTDONE. At this point in the sequence, SYSCTL issues a SYSRST to the device to trigger execution from flash memory. Depending on the boot configuration record, this leads to either the start of the main application (if CSC does not exist in this configuration) or to the start of the CSC (if CSC is configured).
CSC (Customer Secure Code) executes from flash memory to further configure security elements. Note that CSC is customer-owned secure software. This two-step secure boot concept enables application-specific policies to be implemented and managed by CSC while the standard security enablers are implemented by Bootcode. When CSC has completed execution, the system undergoes a second SYSRST followed by the start of the main aplication.
In this security model, both TI Bootcode and CSC are considered trusted. The main application is considered untrusted. When execution jumps to the main application, all security elements are expected to have been configured, including restrictions on the debug port, memory accesses, and key management.
After the first SYSRST, the CSC executes. It configures security and issues INITDONE = NO. At this point, the security configuration is locked and enforced. A second SYSRST is issued, and restarts CSC execution. At the second SYSRST, INITDONE = YES and the main application is launched.
If CSC is not enabled, then only one SYSRST is issued and the application launches following the reset.