Debug port locked

The target debug port is secured (RDP or APPROTECT is active).

CORTEX_M_DEBUG_PORT_LOCKED

Symptoms

  • The probe is detected over USB, but connecting to the target fails immediately.
  • pyOCD reports errors like "No ACK received" or "unable to initialize the debug port" even though wiring is correct.
  • 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.
  • 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