SLAU847D October 2022 – May 2024 MSPM0L1105 , MSPM0L1106 , MSPM0L1227 , MSPM0L1228 , MSPM0L1228-Q1 , MSPM0L1303 , MSPM0L1304 , MSPM0L1304-Q1 , MSPM0L1305 , MSPM0L1305-Q1 , MSPM0L1306 , MSPM0L1306-Q1 , MSPM0L1343 , MSPM0L1344 , MSPM0L1345 , MSPM0L1346 , MSPM0L2227 , MSPM0L2228 , MSPM0L2228-Q1
Figure 4-1 illustrates the boot and startup sequence in security enabled applications. At BOOTRST, TI boot-code execution commences. After successful boot, boot-code issues BOOTDONE. At this point, SYSCTL issues a SYSRST to the device to trigger execution from flash memory. Depending on the boot configuration record, this leads either to 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 is responsible for determining execution bank, memory region protections, secure key initialization into the keystore, etc. When the customer secure code issues INITDONE (by writing to SYSCTL.SECCFG.INITDONE MMR), then SYSCTL issues a second SYSRST. The device again starts execution from 0x0 mapped to flash, and the CSC executes a second time. This time, the CSC will find that INITDONE has already been issued previously (this is determined by reading the SYSCTL.SECCFG.SECSTATUS.INITDONE bit) and it directly calls the main application.
The secure execution flow is the path where CSC_EXISTS = YES. In this case, it may be observed that after BOOTRST, two SYSRSTs will be issued before the main application is launched. After first SYSRST, the customer startup code gets to execute. It configures security and issues INITDONE. At this point, the security configuration is locked and enforced. A second SYSRST is issued at this point, restarting startup code execution. At the second SYSRST, since INITDONE is YES, the main application is launched.