Debug Unlock#

Overview#

The debug access port connected to the Series 2 device's Cortex-M33 processor can be opened by issuing commands to the SE, either from a debugger over DCI or through the mailbox interface.

New on the Series 2 devices is the addition of secure debug unlock functionality. When enabled, it is possible to request a challenge from the device and, by answering the challenge, disable the debug lock until the next power-on or pin reset.

The status of the debug lock can be inspected using the Read Lock Status command.

Standard Debug Unlock#

With the properties of the standard debug lock or secure debug lock with Device Erase enabled, the device can be returned to the standard debug unlock state using the Erase Device command. This command will wipe the main flash and RAM and verify they are empty before opening the debug lock. It will not wipe user data and provisioned SE settings.

Secure Debug Unlock#

In a secure debug unlock scenario, the customer, who has control over the Private Command Key for a SE, has programmed a Public Command Key into the device. The Public Command Key is used to verify the signature on a certificate, telling the SE what authorization has been given by the owner of the key (customer) to the one issuing the command (customer or delegate). Authorization can be granted, for example, to unlock only the debug port on the Cortex-M33, or to restore only specific tamper signals on HSE-SVH devices.

This mode is particularly useful in failure analysis scenarios because it allows devices to be unlocked without losing flash and RAM contents.

Debug Unlock Token#

The elements of the Debug Unlock Token are described in the following figures and table.

Note:

1. The debug access command payload consists of an access certificate and a debug access command signature.

Notes:

• Enable debug port - Debug port enabled if set.

• DBGLOCK (Non-secure, Invasive debug lock) - The Invasive debug features for the Non-secure state are unlocked if set.

• NIDLOCK (Non-secure, Non-invasive debug lock) - The Non-invasive debug features for the Non-secure state are unlocked if set.

• SPIDLOCK (Secure, Invasive debug lock) - The Invasive debug features for the Secure state are unlocked if set.

• SPNIDLOCK (Secure, Non-Invasive debug lock) - The Non-invasive debug features for the Secure state are unlocked if set.

• All reserved bits should be 0, and bit 1 must be 1 to access the debug port.

• For the TrustZone-unaware debugging, bits 2 to 5 are irrelevant, so bits 1 to 5 are usually set (0x0000003e) to match with the Authorizations in the access certificate.

• For the TrustZone-aware debugging, bits 2 to 5 are relevant. Refer to Trust Zone Debug Authentication for details about these debug options.

Access Certificate#

The elements of the access certificate are described in the following figures and table.

Notes:

1. This value allows all debug options to be reset for secure debug.

2. Value that sets available bits in the tamper disable mask for tamper disable (HSE-SVH device only).

3. The Private/Public Certificate Key is a randomly generated key pair. It can be ephemeral or retainable.

The Private Certificate Key can be used repeatedly to generate the signature in a challenge response on one device until the Private/Public Certificate Key pair is discarded. This can reduce the frequency of access to the Private Command Key, allowing more restrictive access control on that key.

For more information about tamper disable, see Anti-Tamper Protection Configuration and Use.

Notes:

• Set the bit to enable the corresponding bit in the debug mode request.

• The Debug Unlock Token will reset the corresponding debug option if the same bit is set in Debug mode request and Authorizations.

Challenge Response#

The elements of the challenge response are described in the following figure and table.

Notes:

1. The challenge remains unchanged until it is updated to a new random value by rolling the challenge. The Private Certificate Key can be reused for signing when the device challenge is refreshed.

2. This signature is the final argument of the Debug Unlock Token.

Debug Access Flow#

The debug access flow is described in the following figure.

1. Get the serial number and challenge from the SE.

2. Generate the access certificate with the device serial number.

3. Generate the challenge response with device challenge.

4. Generate the debug access command payload with access certificate and debug access command signature.

5. Send the Debug Unlock Token to the SE.

6. Verify the debug access command signature using the Public Certificate Key in the access certificate.

7. Verify the serial number and the access certificate signature using the on-chip serial number and Public Command Key in the SE OTP.

8. Authorize the debug mode request to reset the debug options until the next power-on or pin reset.

9. Roll the challenge to invalidate the current Debug Unlock Token.

TrustZone Debug Authentication#

The debug and trace support in the Cortex-M33 devices are based on the CoreSight architecture, which can be classified into Invasive and Non-invasive debugging features as described in the following table.

The separation of Invasive and Non-invasive debug and trace operations in CoreSight architecture can apply to TrustZone debug authentication, which defines the permission levels of the debug and trace features on Secure and Non-secure worlds.

The table below describes four debug options in SE to support TrustZone debug authentication. It is possible to restrict the TrustZone access permissions of the debug interface by setting one or more of the following options.

Notes:

• Use Simplicity Commander or the SE Manager API to set the debug options.

• The state of the debug options is stored permanently in SE and can only be reset to the default value (0000) through the Erase Device command (if enabled).

• A secure debug lock device (Device Erase was disabled) can only use the Debug Unlock Token to temporarily unlock (reset) the debug options to debug the Secure and Non-secure applications.

The following conditions are recommended (1, 2, and 3) or mandatory (4) when setting up the debug options for secure debug unlock.

1. If SPIDLOCK is unlocked, then DBGLOCK should also be unlocked.

2. If SPNIDLOCK is unlocked, then NIDLOCK should also be unlocked.

3. If DBGLOCK is unlocked, the NIDLOCK should also be unlocked.

4. If SPIDLOCK is unlocked, then SPNIDLOCK is automatically unlocked.

The following table lists the recommended combinations of debug options.

Notes:

• Trace Point Interface Unit (TPIU) registers' access fault will occur and lock the processor in a security assertion if both NIDLOCK and DBGLOCK in debug option are set (xx11). The device will be unrecoverable if it is in the permanent debug lock state.

• The workaround is to avoid using the xx11 debug option or avoid accessing the TPIU registers and upgrade to SE firmware ≥ v1.2.14 (xG21 and xG22) or ≥ v2.2.1 (other Series 2 devices) so that the debug options cannot be modified after the device is locked.

The highly recommended setting of debug options is to allow debugging in the Non-secure world while, at the same time, disabling debugging for the Secure world (1100).

• Secure memories (flash and RAM) are not accessible by the debugger.

• All debug access is blocked from accessing Secure addresses.

• The debugger will ignore the vector-catch events generated by the Secure exceptions.

• Trace sources (e.g., ETM) will stop generating instruction/data trace packets when the Cortex-M33 is in a Secure state.

• The debugger can neither halt a Secure application (e.g., breakpoint) nor single step into it.

• The Cortex-M33 will not stop when stepping into the Secure application until it returns to the Non-secure state.

The figure below describes the debug scenario of debug options with 1100 configuration.

The following examples describe the relationship between debug options and debug mode request when performing a secure debug unlock on Series 2 devices.

Example 1: All debug and trace features for both the Secure and the Non-secure world are allowed (0000)

Example 2: Only debug and trace features in the Non-secure world are allowed (1100)

Notes:

• The bit order of debug options are SPNIDLOCK (MSB), SPIDLOCK, NIDLOCK, and DBGLOCK (LSB).

• Debug options: 0 = Unlocked, 1 = Locked

• Authorizations in the access certificate: 0 = Disable, 1 = Enable

• The authorizations in the access certificate are usually set to 00|1111|10 (0x3e), so the corresponding debug options (bits 2 to 5) can be reset (unlocked) by debug mode request during secure debug unlock.

• Debug mode request (bits 2 to 5) in the Debug Unlock Token:

  -0 = No action on the corresponding debug option if it was locked (i.e., 1)

  -1 = Reset (unlock) the corresponding debug option from 1 to 0 if it was locked (i.e., 1)

  -x = No action (either 0 or 1) on the corresponding debug option if it was unlocked (i.e., 0)

• Debug options return to the original state after power-on or pin reset.

Debug Unlock Command Reference#

The commands for debug unlock are described in the following table.

Notes:

1. Performing these commands over DCI is implemented in Simplicity Studio and Simplicity Commander.

2. These APIs are only available on HSE devices. The SE Manager API document can be found at https://docs.silabs.com/gecko-platform/latest/service/api/group-sl-se-manager.