BMCLI channel

命令名、参数与机器可读字段保持英文，以便直接复制到终端或交给 AI 使用；当前安装版本的精确契约请以 bmcli help ... --format=json 为准。

channel enumerate

List all connected BUSMUST CAN FD / LIN analyzer channels. Each result is one channel record; physical-device operations use the record’s stable serial or UID with device reset and device update.

bmcli channel enumerate
bmcli channel enumerate --format=json
bmcli channel enumerate --format=csv

channel info

Show channel information. Standalone mode reports static enumeration fields (name, SN, firmware, VID/PID, capability). Daemon mode additionally reports the selected bus and runtime configuration. CAN channels report controller mode, nominal/data bitrate, and termination. LIN channels report role, bitrate, pull-up, supply direction, protocol version, and checksum model.

bmcli channel info                     # all devices
bmcli channel info --channel=0         # by legacy index
bmcli channel info --channel=10356/0   # by SN/port
bmcli channel info --channel=0 --format=json

Option	Description
--channel	Channel spec (SN/port, UID/port, or legacy index). Omit for all.

channel open

Open and activate one CAN or LIN channel in the persistent daemon. The default bus type is selected from the enumerated channel capability; --bus is not a public argument. Repeat the command to open additional channels.

bmcli channel open --channel=10356/0 --nbitrate=500k --dbitrate=2000k
bmcli channel open --channel=10356/1 --mode=loopback --termination=120

# LIN master and slave endpoints
bmcli channel open --channel=10356/4 --mode=master --bitrate=19200 --pullup=1k --power=on
bmcli channel open --channel=10357/4 --mode=slave --bitrate=19.2K --pullup=off --power=off

# Legacy index remains supported, but depends on the current enumeration order
bmcli channel open --channel=0 --nbitrate=500 --dbitrate=2000

Option	Default	Description
--channel	(required)	One channel spec: 0, 10356/0, UID/0, or an exact enumerated name
--mode	CAN normal; LIN listen-only	CAN controller mode or LIN master, slave, listen-only, internal-loopback
--nbitrate	500	CAN nominal bitrate. Bare kbps, bps, K/kbps, and M/mbps forms are accepted.
--dbitrate	2000	CAN data bitrate. Bare kbps, bps, K/kbps, and M/mbps forms are accepted.
--bitrate	19200	LIN bitrate in bps, 1000..20000; 19200 and 19.2K are equivalent. auto is slave-only and requires supporting firmware.
--termination	120	CAN termination: 120 or off
--pullup	master 1k; other modes off	LIN pull-up: 1k or off
--power	master on; other modes off	Enable or disable this channel’s LIN 12 V output
--lin-version	2.2	LIN protocol version: 1.3, 2.0, 2.1, 2.2
--checksum	auto	LIN checksum: classic for IDs 0x3C/0x3D, enhanced otherwise

Current HPM firmware cannot safely accept a zero bitrate for slave auto-detect, so BMCLI rejects --bitrate=auto with a firmware-capability error instead of silently substituting a fixed value.

channel close

Close a previously opened channel.

bmcli channel close --channel=0

channel status

Show CAN bus status (TEC, REC, busoff, TX/RX passive/warn).

bmcli channel status --channel=0
bmcli channel status --channel=0 --format=json

JSON output:

{"status":"ok","channel":0,"busoff":0,"txbp":0,"rxbp":0,"txwarn":0,"rxwarn":0,"tec":0,"rec":0}

channel power

Read or control channel power independently from LIN protocol configuration. Current hardware maps this command to the LIN 12 V output. off disables this device’s output but does not prove an externally powered bus is unpowered.

bmcli channel power status --channel=10356/4 --format=json
bmcli channel power on --channel=10356/4
bmcli channel power cycle --channel=10356/4 --off-duration=500

can config get/set

Read all CAN settings or idempotently apply supplied settings to an open daemon channel. The protocol prefix keeps CAN termination and bitrate terms out of LIN.

bmcli can config get --channel=10356/0 --format=json
bmcli can config set --channel=10356/0 --mode=normal \
  --nbitrate=500K --dbitrate=2M --termination=120

lin config get/set

Read all LIN role, timing, electrical, and protocol settings or apply supplied settings to an open daemon channel. A role change clears the active hardware TX task table before switching, preventing a master schedule or slave response from surviving into the opposite role.

bmcli lin config get --channel=10356/4 --format=json
bmcli lin config set --channel=10356/4 --mode=master --bitrate=19200 \
  --pullup=1k --power=on --lin-version=2.2 --checksum=enhanced

config is a noun and is always followed by get or set. Bare channel config and configure forms are not supported.

channel autoset

Detect the nominal/data bitrate and terminal resistor. AutoSet runs outside the daemon and requires exclusive hardware access. Stop a running BMCLI daemon first. Passive mode is the default and only listens; active mode transmits probe frames and must be explicitly selected on an isolated bench or authorized bus.

bmcli channel autoset --channel=10356/1 --timeout=10000
bmcli channel autoset --channel=10356/1 --timeout=10000 --format=json
bmcli channel autoset --channel=10356/1 --mode=active --timeout=10000 --format=json

Option	Default	Description
--channel	(required)	Stable SN/port, UID/port, or legacy index
--mode	passive	passive/listen observes existing traffic; active transmits probes and detects TX ACK evidence
--timeout	10000	Soft deadline, 1-60000 milliseconds. A candidate already showing plausible traffic is allowed to finish verification.
--confirmations	3	Required RX messages in passive mode or TX ACK confirmations in active mode, 3-255
--observation	BMAPI default	Passive mode: observation time per candidate in milliseconds
--probe-timeout	BMAPI default	Active mode: write timeout per probe in milliseconds
--probe-id	0x6A5	Active mode: standard or extended CAN probe ID
--probe-data	eight zero bytes	Active mode: 1-64 probe payload bytes

Passive success proves that the selected analyzer port observed valid traffic at the reported timing. Active success proves that another CAN node acknowledged repeated probes at the reported timing. Neither mode identifies a specific ECU. A silent bus can make passive mode fail even when an ECU is connected; active mode is faster in that case but can affect live network behavior. JSON output identifies mode and evidence_type, with either observed-message or acknowledged-probe counts.

channel recover

Manually trigger fault recovery on a channel (BUSOFF, USB disconnect, etc.). The daemon also performs this automatically when auto-recover is on.

bmcli channel recover --channel=0

channel auto-recover

Enable or disable automatic fault recovery in daemon mode. Default: on.

bmcli channel auto-recover on
bmcli channel auto-recover off
bmcli channel auto-recover status

channel reset-defaults

Reset a channel’s runtime state to factory-neutral. This is the reliable way to clear device tables that a prior command may have populated:

• RX filters → accept-all (overwrite every device slot)
• TX tasks → none (overwrite every slot with BM_TXTASK_INVALID)
• message routes → none (overwrite every slot with type=0)
• online logging → off
• online replay → off
• CAN mode → NORMAL
• offline config storage → cleared (BM_ClearConfig)

bmcli channel reset-defaults --channel=0
# rxfilters:ok(cap=0) txtasks:ok(cap=64) routes:ok(cap=64) logging:off replay:off mode:normal offlinecfg:cleared
# OK: channel 0 reset to defaults

Why capacity-based overwrite? Passing NULL/0 to BM_SetMsgRoutes / BM_SetTxTasks / BM_SetRxFilters is a no-op — the BMAPI write loop runs for (i = 0; i < n; i++), so n=0 writes nothing and leaves the device table untouched. The only reliable clear is to overwrite every slot the device actually exposes. BMCLI queries the device’s real slot count via BM_Control(BM_GET_STAT, BM_STAT_MAX_*) and writes that many invalid/accept-all entries. The (cap=N) in the response is that queried count:

• cap>0 — the device reported its real slot count; that many slots were overwritten (a true clear).
• cap=0 — the stat item is unsupported on this firmware; BMCLI fell back to a hardware-specific default (see below).

Fallback defaults when the stat query is unsupported (cap=0). These are the real slot counts of the hardware — writing more than this is an out-of-bounds write that can corrupt the table, so the defaults MUST match the hardware, not the (larger) BMAPI internal array sizes:

Table	Fallback default	Notes
RX filters	2	Our hardware exposes 2 rxfilter slots.
TX tasks	gen3 = 64, gen2 = 1	Generation detected from the firmware version major byte (version[0]==3 → gen3, ==2 → gen2). TX-task stat is normally supported on gen3.
Message routes	4	Our hardware exposes 4 route slots.

To inspect the live device runtime state (the same fields reset-defaults clears — RX filters, TX tasks, routes, logging/replay config, CAN status), use bmcli doctor --channel=<spec>, which now dumps all of them. Note: BM_Get* returns stale slot memory (the device does not zero unused slots), so the active=N counts are an upper bound, not ground truth — a slot that held an entry earlier in this power cycle may still read back as active after a logical clear. reset-defaults is the reliable clear.

channel reset-defaults only resets the channel given by --channel. Routes and TX tasks are device-global tables, so on a multi-channel device you may want to run it on each open channel.

---

---

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