Firmware Signing Key Conflict (v19.0.0+)
This guide explains how to recover from a firmware signing key conflict in firmware versions v19.0.0 and later.
This issue occurs in firmware versions v19.0.0 and later when mixing officially released (production-signed) firmware with locally built (development-signed) firmware.
The Core Problem
The Production-signed MCUBoot (Device Manager/DM Firmware), once installed, enforces a strict security check. It will permanently reject and fail to boot any subsequent DMFW image that is signed with the local development key.
The Failure Chain:
Initial Flash: Developer uses
recover-blackhole.pyto flash a production-signed fwbundle.Lock Installed: The restrictive production MCUBoot is installed.
Subsequent Flash: Developer attempts to flash a local, development-signed fwbundle (
west build).Result: The new DMFW won’t be installed and the board will fall back to the previous production-signed firmware because the installed MCUBoot rejects the development key.
Recovery Methods (To Accept Development Firmware)
Base recovery command:
python ./scripts/tooling/blackhole_recovery/recover-blackhole.py {recovery-fw-bundle-name} {board type} --force
Solution |
Strategy |
Steps |
|---|---|---|
Option 1: Overwrite MCUBoot |
Manually replace the production bootloader with a permissive development version. (Complicated) |
|
Option 2: Downgrade |
Use a non-secure firmware version to clear the lock. (Easy) |
|
Option 3: Use Local Image |
Avoid installing the production MCUBoot entirely. (Recommended) |
|
To build a local recovery bundle:
python3 ./scripts/tooling/blackhole_recovery/prepare-recovery-bundle.py <recovery-fw-bundle-name>