Probe is open in another mode

Another tool already holds this probe — an IDE debug session, STM32CubeProgrammer, or a second MCUHex window.

PROBE_ALREADY_OPEN

Symptoms

  • Connecting fails immediately, and the probe is listed in the device list.
  • An IDE debug session, STM32CubeProgrammer or a second MCUHex window is open on the same machine.
  • It started right after a debug session was stopped in an IDE — the IDE kept the handle.

Likely causes

  • A debug probe can be opened by one program at a time. The second one is refused, whichever it is.
  • STM32CubeIDE, Keil, IAR and VS Code debug sessions hold the probe for as long as their debug server runs, which can outlive the session in the UI.
  • A crashed tool leaves the handle open until its process is gone.
  • On Linux and macOS, a background gdbserver or openocd process from an earlier run is still alive.

How to fix it

  1. Close the other debug session

    Stop the debug session in your IDE and close STM32CubeProgrammer. Both keep the probe after the visible session ends.

  2. Look for a leftover process

    A crashed debug server holds the probe invisibly. Find and end it, then try again.

    # macOS / Linux
ps aux | grep -Ei "openocd|gdbserver|st-util|pyocd"

# Windows (PowerShell)
Get-Process | Where-Object { $_.Name -match "openocd|ST-LINK|gdbserver" }

  3. Replug the probe

    Unplugging and reconnecting frees the handle if nothing is left running. If it comes back straight away, something is reclaiming it automatically.

  4. Check for a second MCUHex window

    Only one page can hold the probe through the tray app. Close the other tab and reconnect here.

Related errors