BMCLI device
Reference version: BMCLI 1.6.3. Command names, parameters and machine-readable fields retain their source spelling.
device reset
Section titled “device reset”Reboot one complete local analyzer and verify that the same physical UID returns:
bmcli device reset 10356bmcli device reset 10356/0 --timeout=45000 --format=jsonbmcli device reset --channel=423BAE5191B9/0 --format=jsonThe selector accepts a 4-6 digit serial, a 12-character UID, or either followed
by /port; --device and --channel forms are equivalent. It may be omitted
only when exactly one local physical analyzer is connected. Missing, malformed,
conflicting, and ambiguous selectors fail before any reset command is sent.
Stop the daemon first. BM_ResetDevice() invalidates every open channel/device
handle belonging to the selected analyzer and causes a USB disconnect comparable
to unplugging and reconnecting it. BMCLI opens the selected device in an inactive
mode, sends the reset, observes its disappearance, and then requires the same UID
to re-enumerate. The default timeout is 45000 milliseconds; the accepted range is
1000-60000 milliseconds. BMCLI returns as soon as the device is back, so this
upper bound does not slow a normal reset. USB auto-connect/capture rules in VMware
or other virtualization software can hold a reappearing analyzer between the host
and guest until their capture timeout expires, or attach it to the guest. Disable
that rule or disconnect the analyzer from the guest when deterministic reset time
is required.
Generation-3 firmware resets immediately from inside the USB control request, so
the low-level API may report BM_ERROR_ILLOPERATION because the transfer itself
was interrupted. BMCLI reports success only when physical disconnect and same-UID
re-enumeration are both observed; inspect the command exit code and top-level
status, not api_status alone. Other connected devices are never accepted as
evidence that the requested target returned.
device update
Section titled “device update”Check or update the complete physical analyzer, not an individual channel:
bmcli device update 10356 --checkbmcli device update 10356/0 --check --format=jsonbmcli device update 423BAE5191B9 --checkbmcli device update --device=10356bmcli device update 10356 --forcebmcli device update 10356 --file=0083.3107.bin --forceThe device selector accepts a 4-6 digit analyzer serial number, a 12-character
UID, or either identity followed by /port. A channel-qualified selector such
as 10356/0 locates its parent physical device; the operation still affects the
complete analyzer. --device=<device> and --channel=<device> are also accepted.
The selector may be omitted only when exactly one supported local generation-3
device is connected. An explicit selector that is absent or ambiguous fails and
never falls back to another connected device.
BMCLI obtains the firmware CID from the enumerated BMAPI product identifier and
downloads https://download.busmust.com/files/Firmware_<CID>_Changelist.txt.
The first non-empty line is the latest four-component firmware version. --check
compares it with version[4], reports update_available, up_to_date, or
local_newer, and displays only newer changelist entries.
Without --check, BMCLI downloads the requested HPM firmware completely over
HTTPS before touching hardware. By default, it proceeds if and only if the
published version is newer. --force explicitly permits a reinstall or
downgrade to the current official release published for the selected device’s
CID and cannot be combined with --check.
An authorized engineering or production workflow may instead provide a complete
local HPM UF2 image with --file and the explicit --force gate. BMCLI
validates the TinyUF2 contract before touching hardware: every block must carry
the family-present flag, must not carry the not-main-flash flag, must use the
HPM family ID and a 256-byte payload, and must form one aligned, contiguous,
non-overlapping F4L2/0083 application image in
[0x80020000, 0x80100000) without address overflow or range escape. BMCLI also
requires exactly one embedded
generation-3 BM_DeviceInfo version. The caller remains responsible for
obtaining the exact file from an approved source and independently verifying
its published SHA-256. BMCLI does not infer the model or version from the
filename and does not accept a caller-supplied expected version.
For either source, BMCLI sends the generation-3 boot command, waits for the
HPMBOOT mass-storage volume (legacy BMBOOT is also accepted), copies the
complete firmware, and requires the same UID to re-enumerate with the expected
version (the published version for CID downloads or the embedded version for a
local image). A successful structured result identifies source as
cid_server or local_file.
On Linux, an HPM device can leave mass-storage mode immediately after accepting
the complete image. If every source byte was accepted by write but fsync or
the destination close then reports an error, BMCLI treats that tail error as
an uncertain copy status rather than a final upgrade failure. It cleans any
mount point that it created and continues the same bounded UID/version check.
The command succeeds only if the requested UID re-enumerates at the expected
version, and reports the synchronization error as a warning. Open, read, or
write failure before the complete source was accepted remains a hard failure
and is never overridden by later enumeration.
Existing HPMBOOT/BMBOOT volumes, remote devices, ambiguous devices, failed
downloads, and generation-2 STM32 devices are rejected. --timeout is in
milliseconds and defaults to 30000. Linux apply requires the boot volume to be
auto-mounted or BMCLI to run with mount permission; BMCLI never invokes sudo.
The boot control request can return BM_ERROR_ILLOPERATION while still
successfully disconnecting the application interface. BMCLI treats the observed
boot volume as authoritative, temporarily releases process-wide BMAPI state so
the mass-storage interface can bind, then reinitializes BMAPI for final UID and
version verification. A low-level error without a boot volume remains a failure.
The current firmware server does not publish a separate firmware hash. CID transport integrity relies on HTTPS, response sanity checks, and HPM bootloader validation. Local-image workflows must verify the artifact hash before invoking BMCLI. Post-update same-UID re-enumeration is mandatory before success is reported in both cases.
Source of truth: BMCLI 1.6.3 repository documentation. Run bmcli help <category> <action> --format=json for the exact contract of the installed version.