Skip to content
BUSMUST
中文Support

BMCLI device

device reset

Section titled “device reset”

Reboot one complete local analyzer and verify that the same physical UID returns:

Terminal window
bmcli device reset 10356
bmcli device reset 10356/0 --timeout=45000 --format=json
bmcli device reset --channel=423BAE5191B9/0 --format=json

The 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:

Terminal window
bmcli device update 10356 --check
bmcli device update 10356/0 --check --format=json
bmcli device update 423BAE5191B9 --check
bmcli device update --device=10356
bmcli device update 10356 --force

The 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; it does not accept an arbitrary version or local image and cannot be combined with --check. After download, BMCLI sends the generation-3 boot command, waits for the HPMBOOT mass-storage volume (legacy BMBOOT is also accepted), copies the firmware, and requires the same UID to re-enumerate with the expected version. 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. Transport integrity relies on HTTPS, response sanity checks, and HPM bootloader validation; post-update re-enumeration is mandatory before success is reported.

Source of truth: bmcli_reference.md in the BMCLI repository. Run bmcli help <category> <action> --format=json for the exact contract of the installed version.