Suite Configuration¶

BenchCI test suites are stored in suite.yaml. A suite defines named tests and ordered steps.

Top-level structure¶

version: "1"

suite:
  name: smoke
  description: Optional suite description

tests:
  - name: boot_ok
    steps:
      - expect_uart:
          node: dut
          transport: console
          contains: "BOOT OK"
          within_ms: 3000

Main sections¶

`version`¶

Schema version string.

`suite`¶

Suite metadata.

suite:
  name: smoke
  description: First working suite

`tests`¶

Ordered list of test cases.

Each test has:

name
steps

Example suite¶

version: "1"

suite:
  name: stm32_smoke

tests:
  - name: boot_ok
    steps:
      - expect_uart:
          node: dut
          transport: console
          contains: "[BOOT] OK"
          within_ms: 3000

  - name: ping
    steps:
      - send_uart:
          node: dut
          transport: console
          data: "PING\n"

      - expect_uart:
          node: dut
          transport: console
          contains: "PONG"
          within_ms: 1000

  - name: irq_test
    steps:
      - gpio_wait_edge:
          node: dut
          line: irq
          edge: rising
          within_ms: 2000

Step types¶

BenchCI currently supports these step types:

reset
sleep_ms
flash
send_uart
expect_uart
modbus_read_holding_registers
modbus_write_single_register
modbus_read_coils
modbus_write_single_coil
gpio_set
gpio_get
gpio_expect
gpio_wait_edge
send_can
expect_can
power_set
power_cycle

Reset step¶

- reset:
    node: dut

Resets the selected node using the node’s configured reset.method.

Sleep step¶

- sleep_ms: 100

Pauses execution for the requested number of milliseconds.

Flash step¶

- flash:
    node: dut

Optional step-level artifact override:

- flash:
    node: dut
    artifact: build/alternate.elf

Artifact resolution order is:

step artifact override
CLI --artifact
node.flash.artifact from bench.yaml

UART steps¶

Send text¶

- send_uart:
    node: dut
    transport: console
    data: "PING\n"

Expect text by substring¶

- expect_uart:
    node: dut
    transport: console
    contains: "PONG"
    within_ms: 1000

Expect text by regex¶

- expect_uart:
    node: dut
    transport: console
    regex: "FW:[0-9.]+"
    within_ms: 1000

expect_uart must define exactly one of:

contains
regex

Modbus steps¶

Read holding registers¶

- modbus_read_holding_registers:
    node: plc
    transport: fieldbus
    slave: 1
    address: 100
    count: 2
    expect: [123, 456]

Write single register¶

- modbus_write_single_register:
    node: plc
    transport: fieldbus
    slave: 1
    address: 100
    value: 42

Read coils¶

- modbus_read_coils:
    node: plc
    transport: fieldbus
    slave: 1
    address: 0
    count: 2
    expect: [true, false]

Write single coil¶

- modbus_write_single_coil:
    node: plc
    transport: fieldbus
    slave: 1
    address: 0
    value: true

GPIO steps¶

Set logical output value¶

- gpio_set:
    node: dut
    line: reset_n
    value: false

Read logical input value¶

- gpio_get:
    node: dut
    line: ready

With expectation:

- gpio_get:
    node: dut
    line: ready
    expect: true

Wait for logical value¶

- gpio_expect:
    node: dut
    line: ready
    value: true
    within_ms: 3000

Wait for edge¶

- gpio_wait_edge:
    node: dut
    line: irq
    edge: rising
    within_ms: 2000

Allowed edges are:

rising
falling
both

CAN steps¶

Send frame¶

- send_can:
    node: dut
    transport: bus
    frame:
      id: 257
      extended: false
      data: "01 02 0A FF"

Expect frame¶

- expect_can:
    node: dut
    transport: bus
    frame:
      id: 513
      extended: false
      data: "AA BB"
    within_ms: 1000

Timeout behavior¶

Steps that need a timeout can either define within_ms explicitly or inherit it from:

defaults:
  timeouts:
    within_ms: 1000

Validation rules¶

BenchCI cross-validates the suite against the bench before execution. For example:

referenced nodes must exist
referenced transports must exist on the selected node
transport backend must match the step type
referenced GPIO logical line names must exist
flashing requires the node to define a flash backend

This catches many configuration mistakes before hardware execution starts.

Power steps¶

If your bench defines a supported power resource, suites can control outlets.

Set power state¶

- power_set:
    resource: dut_power
    outlet: dut
    state: true

Power cycle¶

- power_cycle:
    resource: dut_power
    outlet: dut
    off_ms: 500
    on_settle_ms: 2000

Power steps are useful for realistic hardware reset, boot recovery, and CI smoke tests.