Configure MCUboot as the bootloader in your Zephyr application; in prj.conf enable CONFIG_BOOTLOADER_MCUBOOT=y and select swap-move mode (CONFIG_BOOT_SWAP_USING_MOVE=y) to avoid the need for a dedicated scratch partition
Generate a signing key pair with imgtool.py keygen -k my_key.pem -t ecdsa-p256 and configure CONFIG_MCUBOOT_SIGNATURE_KEY_FILE in your application to auto-sign images at build time
Enable the SMP server and mcumgr BLE transport in your application: CONFIG_MCUMGR=y, CONFIG_MCUMGR_TRANSPORT_BT=y, CONFIG_MCUMGR_GRP_IMG=y, CONFIG_MCUMGR_GRP_OS=y
Build a new firmware image; sign and verify it with imgtool.py verify; then use the mcumgr CLI or a mobile app to upload the image via BLE: mcumgr --conntype ble --connstring peer_name=<device_name> image upload <firmware.bin>
After upload, confirm the pending image hash and trigger the test swap: mcumgr image test <hash>; reset the device: mcumgr reset
After reboot into the new image, if the application passes self-checks, call boot_write_img_confirmed() (or use mcumgr image confirm) to make the swap permanent; without confirmation MCUboot reverts on the next reset
Known gotchas
Swap-move mode requires that both application slots be the same size; asymmetric slot sizes cause MCUboot to fall back to overwrite mode which has no rollback protection
The SMP server must be running and BLE advertising before the upload can start; if the application crashes before confirming the image, the automatic rollback is the intended recovery path
Private signing keys must be kept secure and never embedded in the firmware binary; the build system uses them only at build time to sign the image header
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp