• State Verified Answer
  • Replies 2 replies
  • Subscribers 86 subscribers
  • Views 353 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 356882
Options

Is SWD (APPROTECT) disable possible programmatically while application is running on nRF5340?

Nagari Gopal

Hi Team,

I am working with nRF5340 and have a few clarifications regarding SWD protection (APPROTECT / ERASEPROTECT).

  1. While the application is running, is it possible to disable SWD APProtect programmatically (for example, using a command in application-specific shell / UART terminal)?

  2. If APPROTECT is enabled, can it be dynamically disabled from firmware during runtime, or is the only supported way to regain debug access via CTRL-AP / nrfjprog --recover?

  3. What happens if both APPROTECT and ERASEPROTECT are enabled on nRF5340:

    • Is recovery still possible using CTRL-AP or nrfjprog?

    • Or does enabling both protections permanently block recovery?

  4. In general, is there any supported method to toggle APPROTECT at runtime, or is it intentionally designed as a one-way operation that requires external recovery tools to disable?

I would appreciate clarification on the intended and supported behavior for nRF5340, and any recommended best practices.

Parents
  • +1

    Hi,

    While the application is running, is it possible to disable SWD APProtect programmatically (for example, using a command in application-specific shell / UART terminal)?

    If UICR.APPROTECT has not been enabled from UICR, both the debugger and on-chip firmware must write the same non-zero 32-bit KEY value into their respective registers CTRLAP.APPROTECT.DISABLE (CPU-side) and CTRLAP.APPROTECT.DISABLE (debugger-side) to disable the access port protection. The CTRLAP registers can be accessed from the debugger if you use the Jlink Commander. See Disabling access port protection. 

    If APPROTECT is enabled, can it be dynamically disabled from firmware during runtime, or is the only supported way to regain debug access via CTRL-AP / nrfjprog --recover?

     If UICR.APPROTECT has been enabled from UICR, the device access port is protected. It needs nrfjprog --recover / CTRL‑AP.ERASEALL to unlock the device. See Only APPROTECT is enabled. 

    What happens if both APPROTECT and ERASEPROTECT are enabled on nRF5340:

    • Is recovery still possible using CTRL-AP or nrfjprog?

    • Or does enabling both protections permanently block recovery?

    If both APPROTECT and ERASEPROTECT are enabled, the access port and the ERASEALL functionality are unavailable. nrfjprog --recover / CTRL-AP ERASEALL command will not work when ERASEPROTECT is enabled. To unlock the device, it must have compatible firmware that provides a 32-bit non-zero KEY value to ERASEPROTECT.DISABLE. When both the debugger and firmware provide the same 32-bit non-zero KEY value to ERASEPROTECT.DISABLE, the device does a Control Access Port (CTRL-AP) erase all operation. The access port is re-enabled on the next reset once the erase sequence is done. See APPROTECT and ERASEPROTECT are enabled

    In general, is there any supported method to toggle APPROTECT at runtime, or is it intentionally designed as a one-way operation that requires external recovery tools to disable?

    It is intentionally not a simple runtime toggle. Once protections are enabled, it requires nrfjprog --recover / CTRL‑AP ERASEALL command to unlock the device. See Only APPROTECT is enabled. 

    Regards,
    Amanda H.

Reply
  • +1

    Hi,

    While the application is running, is it possible to disable SWD APProtect programmatically (for example, using a command in application-specific shell / UART terminal)?

    If UICR.APPROTECT has not been enabled from UICR, both the debugger and on-chip firmware must write the same non-zero 32-bit KEY value into their respective registers CTRLAP.APPROTECT.DISABLE (CPU-side) and CTRLAP.APPROTECT.DISABLE (debugger-side) to disable the access port protection. The CTRLAP registers can be accessed from the debugger if you use the Jlink Commander. See Disabling access port protection. 

    If APPROTECT is enabled, can it be dynamically disabled from firmware during runtime, or is the only supported way to regain debug access via CTRL-AP / nrfjprog --recover?

     If UICR.APPROTECT has been enabled from UICR, the device access port is protected. It needs nrfjprog --recover / CTRL‑AP.ERASEALL to unlock the device. See Only APPROTECT is enabled. 

    What happens if both APPROTECT and ERASEPROTECT are enabled on nRF5340:

    • Is recovery still possible using CTRL-AP or nrfjprog?

    • Or does enabling both protections permanently block recovery?

    If both APPROTECT and ERASEPROTECT are enabled, the access port and the ERASEALL functionality are unavailable. nrfjprog --recover / CTRL-AP ERASEALL command will not work when ERASEPROTECT is enabled. To unlock the device, it must have compatible firmware that provides a 32-bit non-zero KEY value to ERASEPROTECT.DISABLE. When both the debugger and firmware provide the same 32-bit non-zero KEY value to ERASEPROTECT.DISABLE, the device does a Control Access Port (CTRL-AP) erase all operation. The access port is re-enabled on the next reset once the erase sequence is done. See APPROTECT and ERASEPROTECT are enabled

    In general, is there any supported method to toggle APPROTECT at runtime, or is it intentionally designed as a one-way operation that requires external recovery tools to disable?

    It is intentionally not a simple runtime toggle. Once protections are enabled, it requires nrfjprog --recover / CTRL‑AP ERASEALL command to unlock the device. See Only APPROTECT is enabled. 

    Regards,
    Amanda H.

Children
Related
Terms of service