SLAAEQ5 March 2025 MSPM0C1103 , MSPM0C1104 , MSPM0C1104-Q1 , MSPM0C1105 , MSPM0C1106 , MSPM0G1105 , MSPM0G1106 , MSPM0G1107 , MSPM0G1505 , MSPM0G1506 , MSPM0G1507 , MSPM0G1518 , MSPM0G1519 , MSPM0G3105 , MSPM0G3105-Q1 , MSPM0G3106 , MSPM0G3106-Q1 , MSPM0G3107 , MSPM0G3107-Q1 , MSPM0G3505 , MSPM0G3505-Q1 , MSPM0G3506 , MSPM0G3506-Q1 , MSPM0G3507 , MSPM0G3507-Q1 , MSPM0G3518 , MSPM0G3518-Q1 , MSPM0G3519 , MSPM0G3519-Q1 , MSPM0H3216 , MSPM0L1105 , MSPM0L1106 , MSPM0L1228 , MSPM0L1228-Q1 , MSPM0L1303 , MSPM0L1304 , MSPM0L1304-Q1 , MSPM0L1305 , MSPM0L1305-Q1 , MSPM0L1306 , MSPM0L1306-Q1 , MSPM0L1343 , MSPM0L1344 , MSPM0L1345 , MSPM0L1346 , MSPM0L2228 , MSPM0L2228-Q1
The code that implements this function is in the same project file as the user's own application.
According to the Nonmain configuration, the MCU can communicate with the mailbox based on SWD, but cannot directly access the kernel resource using the debug port. Writing software for the MCU can implement password verification based on Mailbox communication.
| DSSM Register | Description | Debug Probe | Target Device | Actions |
|---|---|---|---|---|
| TX_DATA | Data buffer | RW | R | TXCTL.TRANSMIT is set on write by the debug probe, and cleared on a read by the target device; TXIFG is also set on a write by the debug probe |
| TXCTL | Flow control and status | RW | R | None |
| RX_DATA | Data buffer | R | RW | RXCTL.RECEIVE is set on write by the target device, and cleared on a read by the debug probe; RXIFG is also set on a write by the target device |
| RXCTL | Flow control and status | R | RW | None |
The workflow for MCU is as shown in Figure 3-2.
Combine with debugger software as shown in Figure 3-3. The following is the process of implementing encryption debugging. After the MCU runs the Boot code, the MCU first checks whether AHB-AP is turned on in the Nonmain configuration. If not, then this means that this is in encryption state at this time, and further check whether there is a password transmission command in the DSSM register. If so, then send a response and use the DSSM register to receive the password.
After receiving the four 32-bit password, the MCU checks whether this is the correct password. If correct, then the Nonmain configuration is changed again to enable AHB-AP port.
For Nonmain to take effect, trigger the MCU to perform a boot reset through software. Then, the MCU is powered back on and detects that the AHB-AP is now turned on. To make sure that the MCU is locked again after this debugging is completed, the Nonmain configuration is changed again after detecting that the AHB-AP port is open. However, after this configuration is completed, the MCU is not reset, so the modified Nonmain does not take effect immediately until debug is finished.
After AHB-AP port is opened with password, MCU runs into customer self code and can succeed to debug, and disable AHB-AP port again.
For usual MCU startup, there is no need to debug; MCU enters into main application code after checking SWD is disabled.
During the entire implementation process, Nonmain is modified many times, which also increases the MCU security risk. Specifically, the NONMAIN is a dedicated region of flash memory which stores the configuration data used by the BCR and is related to SWD policies, flash memory, and so on. When modifying Nonmain, if abnormal operation such as power failure causes the Nonmain configuration to be incorrect, then this causes the MCU to become a brick and never be connected. To avoid this problem, a monitor is added to the code to detect whether the configuration is correct after powering on and modifying Nonmain.
Note, that the code for implementing encryption debugging in the MCU is placed in the startup file, and is executed immediately after the MCU is powered on. This jumps to the C Initialization Routine.