Result: ST-Link works again.
If your application firmware accidentally remaps the vector table, disables the debug clock (DBGMCU), or enters a low-power sleep mode before the debugger takes control, the target MCU is effectively deaf to your unlock tool.
After the unlock tool reports success:
A standard flashing utility assumes a cooperative, unlocked device. When you encounter writing flash programmer... fail, you need an unlock tool. This is not a magic wand, but a specialized software/hardware routine designed to bypass the blockage.
A fail unlock tool typically does one of three things: writing flash programmer... fail unlock tool
Standard esptool.py fails:
A fatal error occurred: Failed to connect to ESP32: Wrong boot mode detected
Fail-unlock tool:
esptool.py itself has --before default_reset and --after hard_reset. But for hard lock, use: After erase, RDP falls back to Level 0
esptool.py --port COM3 --baud 115200 chip_id
# If fails, force download mode:
esptool.py --port COM3 --before no_reset write_flash --force 0x0 otadata.bin
# Then mass erase:
esptool.py erase_flash
For stubborn cases (GPIO0 strap ignored), build a hardware flasher that holds GPIO0 low, EN low, release EN, release GPIO0 after 50ms.
JLinkExe -device STM32F103C8 -if SWD -speed 4000 -autoconnect 1
> unlock Kinetis # Even for STM32, this triggers a mass erase
> erase
> exit
Note: J-Link’s universal unlock command forces a device reset and re-initializes the flash controller. Result: ST-Link works again
Some unlock tools fail because the HSE (external crystal) is dead or misconfigured. The unlock programmer tries to initialize the PLL, hangs, and times out.
Fix: Force the debugger to use HSI (internal RC oscillator).