Request for nRF54L15 JTAG Lock/Unlock Procedure

[H538063]

Hi Team,

We require the detailed procedure for locking and unlocking JTAG access on the nRF54L15 device. Specifically, we are looking for:

• Steps to enable JTAG protection (lock/debug disable)
• Procedure to recover or unlock JTAG access
• Any prerequisites or considerations (power cycle, erase behavior, firmware impact, etc.)
• Impact of locking on firmware updates and debugging
• Recommended best practices for secure production configuration

This information is needed to correctly implement and validate JTAG security handling in our product.

Thanks

Haritha

[H538063]

Hi Øyvind,

We are planning to enable both APPROTECT and ERASEPROTECT to completely block debug access, including erase and write operations through the debug interface.

Based on the documentation, ERASEPROTECT requires a key-based unlock mechanism implemented in the firmware for device recovery.

We would like clarification on the recovery process after ERASEPROTECT is enabled:

1. If APPROTECT and ERASEPROTECT are both enabled, what is the recommended method to recover the device?
2. Can a device still be recovered using nRF Command Line Tools (nrfjprog) or J-Link, or is firmware-based authentication mandatory?
3. If the firmware implementing the ERASEPROTECT unlock mechanism becomes corrupted or inaccessible, is there any alternative recovery path available?
4. Are there any Nordic-recommended best practices to ensure devices remain recoverable in production while maintaining maximum debug protection?
5. Can you provide an example or reference implementation of the ERASEPROTECT unlock procedure?

Our goal is to secure the device against all external debug operations while still retaining a controlled recovery mechanism for manufacturing and field service scenarios

Thanks

Haritha

[Øyvind]

Hello Haritha, 

I recommend reading through the nRF54L Series Production Programming documentation, specifically the Enabling device protection. Here is an explanation from the Nordic AI chatbot:

1. Recommended Recovery Method When Both Protections Are Enabled

When both APPROTECT and ERASEPROTECT are enabled on the nRF54L15, the only supported recovery path is a coordinated key exchange between the running firmware and the debugger:

• Both the debugger and the on-board firmware must write the same non-zero 32-bit KEY value to their respective ERASEPROTECT.DISABLE registers:
  • Debugger side: CTRL-AP register ERASEPROTECT.DISABLE (offset 0x010)
  • CPU/firmware side: CPU register ERASEPROTECT.DISABLE (offset 0x504)
• When both registers contain matching non-zero values, the device automatically performs an ERASEALL operation.
• Access ports are re-enabled on the next reset after the erase sequence completes.

[nRF54L15 CTRL-AP] [nRF54L15 Debugger Register]

2. Can nrfjprog / J-Link Recover the Device Alone?

No. When both APPROTECT and ERASEPROTECT are enabled, access port 0 and the ERASEALL functionality are blocked from external tools. nrfjprog --recover or nrfutil device recover cannot complete the recovery unilaterally — the device firmware must cooperate by providing the matching KEY value. Firmware-based authentication is mandatory. [nRF54L Series Production Programming]

3. What If the Firmware Is Corrupted or Inaccessible?

️ Critical: If both APPROTECT and ERASEPROTECT are enabled and the firmware is unable to write the KEY to ERASEPROTECT.DISABLE (e.g., due to corruption), there is no alternative recovery path. The device is permanently unrecoverable.

The documentation explicitly warns:

"If the device has activated both APPROTECT and ERASEPROTECT, it cannot be recovered without a proper software solution."

[nRF54L Series Production Programming]

4. Nordic-Recommended Best Practices

• Implement the KEY handler in a protected bootloader, not just the application. A bootloader is less likely to be corrupted and runs before the application, giving you a reliable recovery entry point.
• Set ERASEPROTECT.LOCK as early as possible in the startup sequence — once the firmware has confirmed it does not need to communicate with a debugger via the CTRL-AP mailbox. After locking, ERASEPROTECT cannot be disabled until the next pin reset, power-on reset, brownout reset, or watchdog timer reset. [nRF54L15 CTRL-AP]
• Configure all protections before performing a reset. APPROTECT, ERASEPROTECT, and SECUREAPPROTECT all take effect after a reset, so configure them together before resetting. [nRF54L Series Production Programming]
• Never enable ERASEPROTECT without a tested, working KEY-based recovery handler already present and verified in firmware. Enabling ERASEPROTECT on a device without a recovery handler is irreversible.
• Use SECUREAPPROTECT instead of or alongside APPROTECT if you only need to protect the secure domain — this leaves non-secure debug access available and reduces the risk of a fully unrecoverable device. [nRF Connect SDK AP-Protect]
• For production, lock UICR.APPROTECT and UICR.SECUREAPPROTECT to prevent unauthorized access. [nRF Connect SDK AP-Protect]

5. ERASEPROTECT Unlock Procedure (Reference)

The unlock is a two-sided handshake. The KEY must be agreed upon in advance (e.g., a device-unique value derived from a secret, exchanged over a secure channel such as UART or CTRL-AP mailbox):

Step 1 — Firmware side (on-device):

• Receive the KEY via a secure communication channel (e.g., authenticated UART command or CTRL-AP mailbox).
• Write the non-zero 32-bit KEY to the CPU-side register at offset 0x504:
  

  /* CPU-side ERASEPROTECT.DISABLE register */
  #define ERASEPROTECT_DISABLE_CPU  (*(volatile uint32_t *)0x<base_address + 0x504>)
  
  void eraseprotect_unlock(uint32_t key)
  {
      /* key must be non-zero */
      ERASEPROTECT_DISABLE_CPU = key;
  }

Step 2 — Debugger/tool side:

• Write the same non-zero 32-bit KEY to the CTRL-AP ERASEPROTECT.DISABLE register at offset 0x010.

When both sides have written matching non-zero values, the device automatically initiates ERASEALL and re-enables access ports on the next reset. [nRF54L15 CPU Register] [nRF54L15 Debugger Register]

Kind regards,
Øyvind