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

[Øyvind]

Hello Haritha, 

Below is the answer from our AI chatbot, and what the documentation explicitly covers for nRF54L15. Where something is not fully specified, I’ll point it out.

---

1. How to lock/disable JTAG (enable protection)

On nRF54L15, JTAG/SWD debug access is controlled by:

• UICR.APPROTECT – non-secure debug access (Cortex‑M33 AHB‑AP)
• UICR.SECUREAPPROTECT – secure debug access
• TAMPC.PROTECT.DOMAIN[0].DBGEN/NIDEN/SPIDEN/SPNIDEN – software control of debug enable signals
• Optional UICR.AUXAPPROTECT for AUX‑AP (VPR) [Debug access port].

Hardware-side locking (production-style)

To lock the device from the host PC (recommended for production):

1. Enable non-secure AP-Protect (APPROTECT):

   nrfutil device protection-set All
   

   This writes Enabled to UICR.APPROTECT and hard-resets the device, enabling hardware AP-Protect. [nRF54L AP-Protect]

2. Enable Secure AP-Protect (SECUREAPPROTECT) if you also want to block secure debug:

   nrfutil device protection-set SecureRegions
   

   This writes Enabled to UICR.SECUREAPPROTECT and hard-resets the device. [nRF54L AP-Protect]

3. (Optional but common in final products) Enable ERASEPROTECT to block ERASEALL:

   • Write 0x50FA50FA to UICR.ERASEPROTECT[0].PROTECT0 (0x00FFD060) and PROTECT1 (0x00FFD07C). [Enabling device protection]
   • This blocks RRAMC ERASEALL and CTRL‑AP.ERASEALL. [Enabling device protection; Debug ERASEALL]

4. Reset the device (pin reset or power cycle) so the new UICR values take effect. [Enabling device protection]

After this, the access ports are locked; JTAG/SWD debug is effectively disabled unless you perform the appropriate erase/unlock sequence.

Note: nRF54L15 supports UICR.ERASEPROTECT, which can prevent ERASEALL when AP‑Protect is enabled. [nRF54L AP-Protect]

Software-side locking (firmware behavior)

In nRF Connect SDK, you control whether firmware opens or keeps AP-Protect locked:

• CONFIG_NRF_APPROTECT_LOCK=y
  MDK locks AP-Protect in SystemInit() at every boot and prevents CPU from disabling it. [nRF54L AP-Protect Kconfig]
• CONFIG_NRF_SECURE_APPROTECT_LOCK=y
  Same for Secure AP-Protect. [nRF54L Secure AP-Protect Kconfig]

For a fully locked production image, you typically enable these in the first image (e.g., secure bootloader) so firmware never opens the debug port. [nRF54L AP-Protect Kconfig]

---

2. How to unlock / recover JTAG access

If ERASEPROTECT is not enabled

You can fully unlock by issuing ERASEALL via nRF Util:

nrfutil device recover

• This issues ERASEALL, waits for completion, and on nRF54L15 also programs firmware that corresponds to CONFIG_NRF_APPROTECT_DISABLE=y and CONFIG_NRF_SECURE_APPROTECT_DISABLE=y. [nRF54L AP-Protect]
• After this, AP-Protect and Secure AP-Protect are disabled and the device is debug‑open.

You can also “force AP-Protect to be disabled after hard reset” by the same nrfutil device recover command; the device is automatically unlocked after erase. [nRF54L AP-Protect]

If ERASEPROTECT is enabled

Here the documentation is explicit: any value other than “Unprotected” in UICR.ERASEPROTECT disables ERASEALL (both RRAMC and CTRL‑AP). [Debug ERASEALL; CTRL‑AP erase protection]

• With ERASEPROTECT enabled, ERASEALL cannot be performed, so you cannot simply “recover” the device by erase. [How to unlock nRF54L10]
• Disabling ERASEPROTECT requires a coordinated key write from both debugger and CPU to ERASEPROTECT.DISABLE registers, followed by an automatic erase. [CTRL‑AP erase protection]
• If you have locked ERASEPROTECT and do not have firmware support for this handshake, the device is effectively not recoverable by normal means; this is intentional as a final‑production security measure. [How to unlock nRF54L10]

So, for a recoverable product, you must design and validate a firmware‑assisted ERASEPROTECT disable path before enabling ERASEPROTECT in production. The knowledge sources do not provide a full reference implementation of that handshake.

---

3. Prerequisites and considerations

Resets / power cycles

• UICR‑based protection (APPROTECT, SECUREAPPROTECT, ERASEPROTECT) takes effect only after a device reset (pin reset, power‑on, brownout, or watchdog reset). [Debug access port]
• After CTRL-AP.ERASEALL completes, the access port remains open until one of those resets occurs, at which point protection is re‑applied according to UICR and TAMPC. [Debug access port]

ERASEALL behavior

• nrfutil device recover issues ERASEALL and then flashes firmware that opens AP-Protect (sets the “disable” Kconfig behavior). [nRF54L AP-Protect]
• If UICR.ERASEPROTECT is set (Protected), ERASEALL is disabled and nrfutil device recover will fail. [Debug ERASEALL; CTRL‑AP erase protection]

Interaction with firmware

• On every reset, internal boot logic loads AP-Protect configuration from UICR, then firmware may further open/lock AP-Protect via TAMPC depending on Kconfig (CONFIG_NRF_APPROTECT_DISABLE, CONFIG_NRF_APPROTECT_LOCK, etc.). [AP-Protect flow; nRF54L AP-Protect Kconfig]
• To keep AP-Protect or Secure AP-Protect disabled after hard reset, firmware must open the debugger signals in TAMPC; in nRF Connect SDK this is handled by CONFIG_NRF_APPROTECT_DISABLE and CONFIG_NRF_SECURE_APPROTECT_DISABLE (both y by default). [nRF54L AP-Protect]

---

4. Impact on firmware updates and debugging

From the docs:

• With AP-Protect and Secure AP-Protect disabled (default Kconfig), you can start debugging and programming without extra steps. [nRF54L AP-Protect Kconfig]
• With AP-Protect enabled and locked (CONFIG_NRF_APPROTECT_LOCK / CONFIG_NRF_SECURE_APPROTECT_LOCK and UICR set to protected), external debug access is blocked; firmware updates via JTAG/SWD are not possible unless you first perform ERASEALL (and ERASEPROTECT is not enabled). [nRF54L AP-Protect Kconfig; Debug access port]
• If you also enable ERASEPROTECT, then neither debug nor ERASEALL is possible without the firmware+debugger key handshake; if that is not implemented, the device cannot be recovered. [Enabling device protection; How to unlock nRF54L10]

The knowledge sources do not describe the impact on other update channels (e.g., OTA) in detail, but any update path that relies on JTAG/SWD will be blocked when AP-Protect is locked.

---

5. Recommended best practices for secure production

Based on the provided docs:

1. Use UICR + firmware together

   • Configure UICR.APPROTECT / UICR.SECUREAPPROTECT for hardware protection.
   • Use CONFIG_NRF_APPROTECT_LOCK / CONFIG_NRF_SECURE_APPROTECT_LOCK in the first image to ensure firmware does not reopen debug. [nRF54L AP-Protect Kconfig; Debug access port]

2. Lock UICR in final production

   • “For devices in a production environment, it is highly recommended to lock the UICR.APPROTECT and UICR.SECUREAPPROTECT registers to prevent unauthorized access. If configured this way, access port protection cannot be disabled without erasing NVM.” [nRF54L AP-Protect]

3. Be very careful with ERASEPROTECT

   • Only enable UICR.ERASEPROTECT once you have a tested recovery/upgrade strategy that uses the ERASEPROTECT.DISABLE handshake from both debugger and firmware.
   • Nordic explicitly warns: if both APPROTECT and ERASEPROTECT are active, the device cannot be recovered without a proper software solution. [Enabling device protection]

4. Use nRF Util flows for production programming

   • Nordic provides specific guides for:
     • Enabling device protection on nRF54L
     • Disabling AP-Protect on nRF54L
     • Checking AP-Protect status
       [nRF54L AP-Protect; Enabling device protection]

5. Plan a debug/unlock policy

   • During development: keep CONFIG_NRF_APPROTECT_DISABLE=y (default) and UICR unprotected.
   • For field returns / RMA: rely on nrfutil device recover (no ERASEPROTECT) to erase and reopen debug.
   • For high‑security SKUs: enable ERASEPROTECT only if you accept that devices may become unrecoverable without the key‑based disable flow.

Kind regards,
Øyvind