Access port protection

The access ports can be protected to secure the internal assets and resources of the device. While the control access port (CTRL-AP) is always accessible from an external debugger, the system applies various protection mechanisms to control and restrict access to the individual AHB access ports. These mechanisms ensure both secure and non-secure access can be selectively managed and protected.

Protection is controlled by specific registers, which enable or disable debug access at different levels. These registers are part of UICR and TAMPC. The access port is normally protected. The hardware and software configurations of these registers control the access protection policies as shown in the following table.

Table 2. Non-secure Arm Cortex-M33 AHB-AP debug access
Registers	Description
UICR.APPROTECT	Hardware control of non-secure debug access. A device reset is required for this configuration to take effect. Unprotected – CPU controls DBGEN/NIDEN, locks disabled. Other values – DBGEN/NIDEN disabled and locked.
TAMPC.PROTECT.DOMAIN[0].DBGEN TAMPC.PROTECT.DOMAIN[0].NIDEN	CPU control of non-secure debug access. The registers can be locked.

Table 3. Secure Arm Cortex-M33 AHB-AP debug access
Registers	Description
UICR.SECUREAPPROTECT	Hardware control of secure debug access. A device reset is required for this configuration to take effect. Unprotected – CPU controls SPIDEN/SPNIDEN, locks disabled. Other values – SPIDEN/SPNIDEN disabled and locked.
TAMPC.PROTECT.DOMAIN[0].SPIDEN TAMPC.PROTECT.DOMAIN[0].SPNIDEN	CPU control of secure debug access. The registers can be locked. Non-secure invasive debug access must be enabled for secure debug access to be enabled.

Table 4. VPR AUX-AP debug access
Registers	Description
UICR.AUXAPPROTECT	Hardware control of AUX-AP debug access. A device reset is required for this configuration to take effect. Unprotected – CPU controls AUX-AP DBGEN, lock disabled. Other values – AUX-AP DBGEN disabled and locked.
TAMPC.PROTECT.AP[0].DBGEN	Software control of AUX-AP debug access. The registers can be locked.

The access port protection is illustrated in the following figures.

Figure 2. AUX access port protection overview

Figure 3. Arm Cortex-M33 AHB-AP access port protection overview

Table 5. Erase protection
Registers	Description
UICR.APPROTECT UICR.SECUREAPPROTECT	Hardware control of RRAMC ERASEALL protection in addition to access ports. A device reset is required for this configuration to take effect. Any value other than Unprotected disables RRAMC ERASEALL.
UICR.ERASEPROTECT	Hardware control of RRAMC ERASEALL and CTRL-AP ERASEALL protection. A device reset is required for this configuration to take effect. Any value other than Unprotected disables the erase all operations.
TAMPC.PROTECT.ERASEPROTECT	Software control of RRAMC ERASEALL and CTRL-AP ERASEALL protection. The register can be locked.

The ERASEALL protection is illustrated in the following figure:

Erase all protection overview — Figure 4. ERASEALL protection overview

The reset behavior of the TAMPC access port and ERASEALL protection is defined in Signal protector. On-chip software must write to the TAMPC registers before a debug access port is opened.

The access port remains open after the completion of the CTRL-AP.ERASEALL operation. CTRL-AP temporarily removes the access port protection until certain conditions are met, after which the protection will be reinstated. The AHB-AP will be protected when one of the following conditions are met:

Power-on reset
Brownout reset
Watchdog timer reset
Pin reset

The following figure shows how a device with access port protection enabled can be erased, programmed, and configured to allow debugging. The access port state is determined by operations sent from the debugger and registers written by firmware. Reset in the following figure refers to any of the conditions previously listed for AHB-AP protection. When writing to the TAMPC, the software must first disable write protection, then write the new values. For more details, see TAMPC — Tamper controller.

Figure 5. Access port unlocking

The debugger can read the access port protection status in the core's AHB-AP, using the Arm AHB-AP Control/Status Word register (CSW), defined in the Arm CoreSight SoC-400 Technical Reference Manual. The DbgStatus field indicates that the AHB-AP can perform AHB transfers, while the SPIStatus field indicates if secure AHB transfers are permitted. For a list of all debug access ports, see Debug access port.