16.9 Intellectual Property Protection

Intellectual property protection consists of restricting access to internal memories from external tools when the device is protected, and the user can accomplish this by setting the Code Protect bit or DEBUG_LCK bit.

The following are the two protection mechanisms in the PIC32CX-BZ3 devices:
  1. Code Protect – If enabling the Code Protect bit by configuring FCPN0.CP in Boot Flash memory, the device is locked from programming and debugging. Only chip erase can retrieve the device to the normal programming and debugging condition. When issuing a chip erase, it erases sensitive information from volatile memory and Flash.
  2. Secured Device – DEBUG_LCK bits in eFuse (SECCFG.DEBUG_LCK in Root of Trust) determines if the device is locked for debugging. If the DEBUG_LCK bits are non-zero, device is a secured device. Securing of the device implies:
    1. The user cannot execute any unauthenticated firmware.
    2. The debug features of the device are not available and are locked down.
    3. Device programming through SWD interface is still available. Debugger can be plugged in only through the Cold-Plugging procedure. The Hot-Plugging feature is not available (see Cold-Plugging and Hot-Plugging from Related Links).
    4. The DEBUG_LCK bits are in eFuse (one time programmable memory); therefore, when locked, the device is permanently locked for debug unlike the Code Protect mechanism, which can be cleared on a chip erase.
Important: On a secured device (non-zero value of SECCFG.DEBUG_LCK), if the boot key is zero, it implies that secure boot code need not authorize the firmware code. Therefore, programming through an external debugger is disabled on a device, which is secured, and secure boot key is zero.

When the device is protected, read/write accesses using the AHB-AP is limited to the DSU address range and DSU commands are restricted.

The DSU implements a security filter that monitors the AHB transactions generated by the ARM AHB-AP inside the DAP. If the device is protected, then AHB-AP read/write accesses outside the DSU external address range are discarded, causing an error response that sets the ARM AHB-AP sticky error bits. For more details, refer to the ARM Debug Interface v5 Architecture Specification on www.arm.com.

The user can access the DSU either:
  • Internally from the CPU without any limitation, even when the device is protected
  • Externally from a debug adapter with some restrictions when the device is protected
For security reasons, DSU features have limitations when using a debug adapter. To differentiate external accesses from internal ones, the first 0x100 bytes of the DSU register map were mirrored at offset 0x100:
  • The first 0x100 bytes form the internal address range
  • The next 0x100 bytes form the external address range

When the device is protected, the DAP can only issue MEM-AP accesses in the DSU range 0x0100-0x2000.

The DSU Operating registers are located in the 0x0000-0x00FF area and remapped in 0x0100-0x01FF to differentiate accesses coming from a debugger and the CPU. If the device is protected and an access is issued in the region 0x0100-0x01FF, it is subject to security restrictions. For more information, see Table   1.

Figure 16-4. APB Memory Mapping

When the device is protected, some features that are not activated by APB transactions are unavailable.

Table 16-2. Feature Availability Under Protection
FeatureCode Protected and UnsecuredCode Protected and SecuredNot Code Protected and UnsecuredNot Code Protected and Secured
CPU Reset ExtensionYesYesYesYes
Clear CPU Reset ExtensionNoNoYesNo
Debugger Cold-PluggingYesYesYesYes
MEM-AP access during Cold-PluggingNoNoYesYes
Debugger Hot-PluggingNoNoYesNo
Note:
  • Code Protected means FCPN0.CP of the Flash fuse configuration bit is set.
  • Secured means SECCFG.DEBUG_LCK bits of the eFuse are non zero values.