Request for nRF9160 JTAG Lock/Unlock Procedure

Hi Team,


We require the detailed procedure for locking and unlocking JTAG access on the nRF9160 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

  • Hello Haritha, 

    From our AI chatbot: 

    JTAG/Debug Access Protection on nRF9160

    The nRF9160 uses AP-Protect controlled by hardware only (no software component), plus an optional Secure AP-Protect layer. Here is the detailed procedure:


    1. Enabling JTAG Protection (Locking Debug Access)

    The nRF9160 ships unlocked (AP-Protect disabled by default). [AP-Protect overview]

    To enable AP-Protect (full debug lock):

    nrfutil device protection-set All
    

    This writes Enabled to UICR.APPROTECT, hard resets the device, and blocks all debugger read/write access to CPU registers and memory-mapped addresses. [nRF91 AP-Protect config]

    To enable Secure AP-Protect (locks only the Secure Processing Environment):

    nrfutil device protection-set SecureRegions
    

    This writes Enabled to UICR.SECUREAPPROTECT, hard resets the device, and blocks access only to secure CPU registers and secure memory-mapped addresses, while non-secure debugging remains accessible. [nRF91 AP-Protect config]


    2. Unlocking / Recovering JTAG Access

    To disable AP-Protect or Secure AP-Protect (or both):

    nrfutil device recover
    

    This issues an ERASEALL command via CTRL-AP, which erases flash, RAM, and UICR (including UICR.APPROTECT and UICR.SECUREAPPROTECT), and hard resets the device. The device is automatically unlocked after erase. [Unlocking nRF91]

    Note: On the nRF9160, AP-Protect is hardware-only — there are no nRF Connect SDK Kconfig options for this device. Both AP-Protect and Secure AP-Protect are controlled solely by writing to the UICR. [AP-Protect overview]


    3. Prerequisites and Considerations

    • Erase behavior: ERASEALL erases all flash, RAM, and UICR. Any firmware and data on the device will be lost upon unlock.
    • UICR.ERASEPROTECT: The nRF9160 supports UICR.ERASEPROTECT. If both APPROTECT and ERASEPROTECT are enabled simultaneously, the ERASEALL command cannot execute, and the device cannot be recovered. [AP-Protect overview]
    • No software re-enable after reset: Unlike nRF91x1 devices, the nRF9160 does not re-enable AP-Protect on every hard reset. Once unlocked via ERASEALL, it stays unlocked until you explicitly re-enable it. [AP-Protect overview]
    • No firmware changes needed to keep AP-Protect disabled after recovery, since the nRF9160 does not use software-controlled AP-Protect. [nRF91 AP-Protect config]

    4. Impact on Firmware Updates and Debugging

    • When AP-Protect is enabled, the debugger has no read/write access to CPU registers or memory. Firmware cannot be flashed or debugged via SWD/JTAG.
    • The only way to regain access is via ERASEALL through CTRL-AP, which destroys all firmware and data.
    • If ERASEPROTECT is also enabled, even ERASEALL is blocked, making the device permanently inaccessible without a proper authenticated software solution. [Device protection]

    5. Recommended Best Practices for Production

    • Lock both UICR.APPROTECT and UICR.SECUREAPPROTECT in production to prevent unauthorized debug access. If configured this way, protection cannot be disabled without erasing non-volatile memory. [nRF91 AP-Protect config]
    • Be cautious with ERASEPROTECT: Enabling it alongside APPROTECT makes the device unrecoverable. Only enable it if you have a controlled authenticated recovery mechanism in place. [Device protection]
    • Program all protections before the final reset: If activating multiple protections (APPROTECT, ERASEPROTECT, SECUREAPPROTECT), write all UICR values before issuing the reset, so all protections activate simultaneously. [Device protection]
    • Refer to the additional Nordic production programming guides for validation:

    Let me know how this works for you.

    Kind regards,
    Øyvind

Related