Debug port locked

The debug port answered and refused the access. That is what read-out protection looks like: STM32 RDP level 1, Nordic APPROTECT, Kinetis FSEC.

CORTEX_M_DEBUG_PORT_LOCKED

Symptoms

  • The debug port answers and then refuses the access — this is a reply, not silence. A chip that says nothing at all is a different problem.
  • The error text mentions an AP or DP fault while connecting.
  • The board worked before, then stopped being debuggable after flashing a production or release firmware.
  • STM32CubeProgrammer shows RDP level 1 when connected.

Likely causes

  • STM32 readout protection (RDP): level 1 blocks flash access through SWD; level 2 disables the debug port entirely and is irreversible.
  • Nordic APPROTECT: on nRF52/nRF53 devices, the APPROTECT register locks out the debugger until an ERASEALL recover is performed.
  • Kinetis FSEC and equivalent fuses on other vendors, set the same way and with the same effect.
  • Firmware enables protection at boot: some firmware sets RDP/APPROTECT programmatically on first startup, so the lock reappears after every unlock + reflash cycle.

How to fix it

  1. Identify the protection level

    For STM32, connect with STM32CubeProgrammer (SWD, mode "Under reset") and read the option bytes. RDP level 1 is recoverable; level 2 is permanent — no tool can restore debug access on a level-2 part.

  2. Regress RDP from level 1 to 0

    In STM32CubeProgrammer → Option Bytes → set RDP to AA and apply. This triggers a full mass erase — all flash contents are wiped by design. That is the intended security behavior, not a bug.

  3. Recover a Nordic device

    Perform an ERASEALL recover, which also clears APPROTECT.

    nrfjprog --recover
# or
pyocd erase --mass -t nrf52

  4. Reconnect in MCUHex

    After unlocking, click refresh in the device list and connect again. The SWD port should now respond normally.

  5. Check whether your firmware re-locks the device

    If the lock returns after flashing, search your firmware for option-byte / UICR writes (e.g. FLASH_OB_Launch, APPROTECT writes) and disable them in development builds.

Related errors