Get notified

B153 · Donguru

One cable to your board

Donguru sits between your computer and a device with a USB-C port. A USB 2.0 hub, an STM32G0B1 microcontroller and a set of switches give software full control over the device's power, its USB data lines and its sideband pins. Flashing, logging and power cycling become one cable and a script.

Coming Q1–Q2 2027 on CrowdSupply

Get notified Read the datasheet

draft Copy not yet read by Marketing and PM. Specifications from the datasheet, Preview 0.2, 24 Oct 2026; the PDF is coming.

Donguru, the B153 board, three-quarter view
FIG. 1B153 Donguru · rev A (render)

01Why

One cable instead of a small test rack

A device with a USB-C port usually reaches the bench through several boxes: a cable for USB, an adapter and jumper wires for the serial console, a debug probe, a switchable supply and a meter. Each one is another cable to plug and another thing a test script can't control. Donguru puts all of it in one dongle on the device's own USB-C port, and every part of it answers to software.

It is for everyone who works where code meets hardware: hardware, firmware and software engineers bringing up, debugging, testing and flashing devices with a USB-C port. It fits on a desk, in an automated test bench and on a production line, where the product's own connector becomes its test port.

02Features

What it does, and why it matters

VBUS switch

Between computer and device, up to 20 V and 5 A, both directions, off at power-up.

Why Power-cycle the device from a script, and nothing reaches it until you ask.

Power meter

VBUS voltage, current both ways, power, charge and energy totals.

Why See what the device draws while it boots, and log it beside its console.

Guards in the firmware

Voltage, current and power limits that cut VBUS on their own. A cut stays latched until the mode is written again.

Why A script that hangs, or a PD charger that renegotiates to 20 V, can't leave a 5 V device on a voltage it didn't ask for. Design target, to be tested on rev B.

USB data switch

Connect or cut the device's D+/D− without unplugging.

Why The device disappears from the computer and re-enumerates on reconnect, without touching power.

SWD debug probe

CMSIS-DAP v2 on the plug's SBU pins. Works with probe-rs, OpenOCD and pyOCD.

Why A device with SWD on its sideband pins is flashed and debugged through the same cable that powers it.

Buses on SBU, either way round

UART, I2C, SWD, FDCAN, GPIO and ADC on the plug's SBU pins, at 1.8 or 3.3 V, with switchable pull-ups. UART, I2C and SWD swap their lines for either cable orientation.

Why The orientation is a setting, so a flipped cable is one command instead of re-plugging. Automatic TX/RX flip: tbd

Debug-accessory mode

Switchable pull-ups on the plug's CC lines, as a USB-C debug accessory.

Why The device opens its debug path (SWD, a UART) onto the SBU pins with a few comparators or ADC pins. No PD controller needed.

USB 2.0 Hi-Speed hub

The device under test and the on-board MCU on one cable. Plus adds USB on the header and on the plug's SBU pins.

Why The device's own USB keeps its 480 Mbit/s, and the dongle's control traffic takes little of it.

Header with a relay

4 protected GPIO with UART, I2C, SPI, FDCAN and ADC, 3.3 V out, switched VBUS and an isolated relay.

Why The relay presses a reset button, a boot strap or a power key on the device.

USB Power Delivery

A PD controller on each port, each a source or a sink. The PD stack in the firmware is planned for v1.0.

Why A small PD test tool: watch a contract, ask for another voltage, see the meter follow.

Safe by default

Every enable has a pull-down. Plug VBUS, the header's VBUS_SW and the relay are off at power-up, after a reset and while the MCU is halted.

Why The hardware holds the safe state, not the firmware.

One typed API

Rust library, Python wheel, the dg CLI and the IOWeaver GUI over the same API.

Why Every tool sees the same functions and the same checks, and always matches the firmware.

03Block diagram

What is on the board

Donguru block diagram The computer's USB-C receptacle feeds VBUS through the VBUS switch with its voltage and current meter to the device's USB-C plug. The computer's USB goes into a USB 2.0 hub: port 1 to the STM32G0B1 MCU, port 2 as D+ and D− through the plug signal block to the device, and on the Plus variant port 3 to the 2.54 mm header and port 4 to the device over SBU. The MCU drives the VBUS switch and reads the meter, runs the header IO, and reaches the plug's SBU, CC, A2 and B2 pins. COMPUTER USB-C RECEPTACLE DEVICE USB-C PLUG VBUS SWITCH 20 V / 5 A · V/I METER 2.54 MM HEADER 4 GPIO, RELAY 3.3 V, VBUS_SW STM32G0B1 MCU · 2× UCPD USB 2.0 HUB MAIN 2 · PLUS 4 PORTS PLUG SIGNALS DATA CUT, SBU I/O CC PULL-UPS, OVP VBUS D+/D− PORT 1 PORT 3 · PLUS USB ON SBU · PLUS IO EN, METER SBU, CC, A2/B2
FIG. 2Donguru overview, from the datasheet. Dashed: fitted only on Plus.

The computer talks to the STM32G0B1 through port 1 of the hub. The MCU switches plug VBUS, cuts or connects the device's USB data, drives the sideband pins through a level translator and reads the power meter. Every enable has a pull-down: with the MCU in reset or halted, everything that could reach the device is off.

VBUS passes through a bidirectional load switch with a current shunt, so the computer can power the device or the device can feed the computer. Donguru itself runs from whichever side has VBUS (a diode OR into a 4.5 to 40 V buck converter), so it keeps working while plug VBUS is off, and a self-powered device can keep it alive.

Main and Plus

Two assembly variants on the same board. Main covers bench work on one device; Plus adds two more USB ports. The firmware is the same and tells the variant at boot.

FeatureMainPlus
USB 2.0 hub2 ports4 ports
USB to the device (D+/D−), switchable✓✓
USB on the 2.54 mm header—✓
USB to the device over SBU, switchable with SBU I/O—✓
VBUS switch, meter, PD on both ports, SBU and header IO, relay, SWD probe✓✓

04Specifications

Specifications

Electrical characteristics from the datasheet (Preview 0.2, 24 Oct 2026), preliminary: targets for rev B, nothing measured yet. Where a value is open (tbd), the note gives the limit of the part that sets it; the board's own limit can only be lower. The PDF datasheet is coming.

Absolute maximum ratings

Stress beyond these may damage the board. They are not operating conditions. The over-voltage values are design targets, to be tested on rev B, including 20 V applied without any PD negotiation (a lab supply, a broken charger), not only after a contract Donguru negotiated itself.

ParameterMinTypMaxUnitNotes
VBUS, either port−0.324Vload switch over-voltage cut-off; TVS 22 V standoff; to be tested
VBUS current through the switch5Atbd, set by the current limit
Plug SBU, CC (short to VBUS)−0.320VCC/SBU over-voltage protection, part for rev B tbd; to be tested
Plug A2, B2−0.33.6VMCU pins, ESD only
J101 pins 1-4, IO7-IO10−0.55.6V255 Ω, 5.6 V clamp, 12 V TVS; transients tbd
J101 pins 11, 12, relaytbdVphoto-MOS, isolated
Storage temperature−4085°Ctbd
ESD, external pinstbdkV

Recommended operating conditions

ParameterMinTypMaxUnitNotes
Computer VBUS4.55.020Vabove 5.5 V only on request
Supply current, Donguru itselftbdmA
SBU level1.8 or 3.3Vselectable
Load on J101 pin 5, 3.3 V outtbdmAbuck: 600 mA for the whole board
Operating temperature050°Ctbd

VBUS switch

ParameterMinTypMaxUnitNotes
Voltage20Vover-voltage cut-off 24 V
Current, device to computer5.5Ahardware limit, latch-off; tbd
Current, computer to device5Ano hardware limit, short-circuit protected; firmware Auto mode
On resistancetbdmΩplus 5 mΩ shunt
Guard reaction (firmware)15msone ADC update
Power cycle off time060s

Power meter

ParameterMinTypMaxUnitNotes
Current range−6.66.6Apositive towards the device
Current resolution3.2mA12-bit ADC before oversampling
Current accuracy after calibrationtbd%
Voltage range, computer VBUS023.6Vdivider ÷7.17
Voltage resolution5.8mV
Voltage accuracytbd%
Plug VBUS voltagenot measured

SBU

ParameterMinTypMaxUnitNotes
Level1.8 or 3.3Vselectable; adjustable range for rev B tbd
Input high, lowtbdVlevel translator
Pull-ups3.3kΩto the SBU level, switched
Path resistance5Ωprotection; Plus: +6 Ω USB switch
USB over SBU, Plus480Mbit/shub port 4

SWD probe

ParameterMinTypMaxUnitNotes
ProtocolCMSIS-DAP v2 (bulk), 512-byte packets
SWD clock3MHzbit-banged; up to 4 MHz SPI-driven, experimental
Target level3.3V1.8 V targets with rev B tbd

Header IO, J101 pins 1-4

ParameterMinTypMaxUnitNotes
Level3.3VMCU pins
Series resistance255Ωplus the driver
Output current, pin shorted13mA3.3 V / 255 Ω
ADC inputs3IO7, IO9, IO10; 12 bit, 0-3.3 V
Relay contact currenttbdmAphoto-MOS
Relay contact voltagetbdV

UART

ParameterMinTypMaxUnitNotes
Ports2plug SBU (USART3, swapped USART1); J101 IO7 TX, IO8 RX (USART5)
Baud rate48 MBd64 MHz / k above 4 MBd: 5.818 M for 6 M asked; set rate is reported
Data bits78parity none, even, odd; 1 or 2 stop bits
Flow controlnone (no RTS / CTS pins)
TX / RX swapSBU: follows the cable orientation setting
Receive buffer8KiBDMA ring, plus 32 chunks of 512 B
USB serial port (CDC-ACM)the SBU UART, for terminal programs; planned

I2C

ParameterMinTypMaxUnitNotes
Ports2plug SBU (I2C1, SCL / SDA follow the orientation); J101 IO7 SCL, IO8 SDA (I2C3)
Clocktbd1000kHzstandard, fast, fast-mode plus
Level1.8 or 3.3VSBU: selectable; J101: 3.3 V
Pull-ups, SBU3.3kΩto the SBU level, switched
Pull-ups, J101≈40kΩMCU's own only; add external ones above 100 kHz
Addresses7 and 10 bit
Bus capacitancetbdpF

SPI

ParameterMinTypMaxUnitNotes
Port1J101: IO7 SCK, IO8 MISO, IO9 MOSI, IO10 CS (SPI1, CS in software)
Clock, mastertbdMHzMCU SPI: up to 32 MHz (64 MHz / 2); 255 Ω and clamps set the limit
Clock, slavetbdMHz
Modes0-3, MSB or LSB first
Word size416bit

Analog inputs

ParameterMinTypMaxUnitNotes
Channels5J101 IO7, IO9, IO10; plug SBU1, SBU2 (MCU side of the translator)
Input range03.3V
Resolution12bit≈0.8 mV per step before oversampling
Effective resolutiontbdbit
Sample rate, all channels togethertbdkS/sMCU ADC: 2.5 MS/s, shared with the power meter
Accuracy after calibrationtbdmV
Source resistancetbdkΩJ101 adds 255 Ω in series

GPIO, PWM and timers

ParameterMinTypMaxUnitNotes
GPIO8J101 IO7-IO10, plug SBU1, SBU2, A2, B2
Input high, VIH0.7 × VIOVMCU pins; SBU through the translator tbd
Input low, VIL0.3 × VIOV
Toggle rate from the hosttbd1/sone request per change
Edge timestamps, inputstbdµsresolution
PWM outputs3J101 IO7 (TIM14); plug SBU1, SBU2 (TIM2)
PWM resolution16bit64 MHz timer clock
PWM frequencytbdtbdHz

FDCAN

ParameterMinTypMaxUnitNotes
Ports3plug SBU (FDCAN1, one orientation); plug A2, B2 and J101 IO7 TX, IO10 RX (FDCAN2)
Bit rate, arbitration1Mbit/sCAN FD
Bit rate, data phasetbdMbit/sMCU FDCAN: up to 8 Mbit/s
Transceivernone on board: logic-level TX / RX to an external transceiver

USB Power Delivery

ParameterMinTypMaxUnitNotes
Controllers2UCPD1 on the computer port, UCPD2 on the plug
Power rolessource or sink on each port
MessagesPD 3.0 incl. VDM; firmware stack planned for v1.0
Debug-accessory pull-upstbdkΩboth plug CC lines, switched

USB

ParameterMinTypMaxUnitNotes
Speed, external ports480Mbit/sUSB 2.0 Hi-Speed: 1 port on Main, 3 on Plus
Speed, the MCU12Mbit/sUSB Full Speed, hub port 1
ConnectorsUSB-C receptacle (computer), USB-C plug (device)

At reset, halted or unpowered

Every enable and select line has a pull-down, so while the MCU is in reset, halted by a debugger, or without power, the board falls back to the same safe state.

PartState
Plug VBUSoff
Header VBUS_SWoff
Relayopen
Device USB dataconnected to the hub
SBUto the MCU side, level translator off, pull-ups off, low level selected
J101 IO, plug A2/B2MCU pins as inputs; with Donguru unpowered a pin driven high reaches its 3.3 V rail through the MCU's clamp diodes and series resistors

SBU modes and the cable orientation

USB-C plugs go in either way round, and the device's CC pins can't tell which: a device has the same 5.1 kΩ pull-down on both. The orientation is a setting instead. FDCAN has a TX pin on SBU2 only, so it works in one orientation.

ModeCable one wayFlipped
UARTSBU1 TX, SBU2 RXSBU2 TX, SBU1 RX
I2CSBU1 SCL, SBU2 SDASBU1 SDA, SBU2 SCL
FDCAN (to a transceiver)SBU1 RX, SBU2 TX— (no FDCAN pins for it)
SWD hostSBU1 SWCLK, SBU2 SWDIOSBU1 SWDIO, SBU2 SWCLK
GPIO, ADCboth linesboth lines

05Pinout

Pinout, connectors and size

B153 Donguru PCB, top view
FIG. 3Top · rev A (render)
B153 Donguru PCB, bottom view
FIG. 4Bottom · rev A (render)

J101, 1×12 2.54 mm header

PinSignalFunction
1IO7PB3, ADC on PB1; I2C3 SCL, USART5 TX, FDCAN2 TX
2IO8PB4; I2C3 SDA, USART5 RX
3IO9PA2, ADC; USART2 TX, SPI1 MOSI
4IO10PB12, ADC; FDCAN2 RX
53.3 V outboard 3.3 V
6GND
7GND
8USB D+hub port 3, Plus
9USB D−hub port 3, Plus
10VBUS_SWcomputer's VBUS, switched: 5 V, or up to 20 V after PD
11RL1isolated photo-MOS contact
12RL2

VBUS_SW (pin 10) is the computer's own VBUS through a switch, off at power-up: 5 V normally, up to 20 V after a PD renegotiation. Turning it on always shows the present voltage, and above 5.5 V needs an explicit confirmation. Relay (pins 11, 12): an isolated photo-MOS contact for a reset button, a boot strap or a power key on the device.

Plug J501, to the device

PinUse
VBUSswitched, measured, both directions
D+/D− (A6/A7)hub port 2 through the data switch
CC, VCONN (A5, B5)UCPD2: PD; pull-ups for debug-accessory mode
SBU1, SBU2 (A8, B8)UART, I2C, SWD, FDCAN, GPIO, ADC; USB on Plus
A2, B2GPIO, FDCAN2

Receptacle J401, to the computer

PinUse
VBUSpowers Donguru and the device
D+/D−hub upstream, USB 2.0 Hi-Speed
CC1, CC2UCPD1: PD, sink or source
SBU1, SBU2Donguru's own SWD: one Donguru can flash another

Button, switch and LEDs

A push button and a slide switch share one ADC input; the firmware decodes presses and their length, and the button can be given an action (power cycle, data reconnect). Holding the button at power-up starts the STM32 USB bootloader for a firmware update without a probe. A red and a green LED show state, and can blink to identify one dongle among several.

Mechanical

Board and enclosure dimensions tbd. A STEP model comes with them.

06Software

A CLI, a library and a GUI over one API

The firmware serves a typed WireWeaver API over USB, with a CMSIS-DAP interface for debug tools beside it. The Rust library is generated from the API, and the CLI, the Python wheel and the IOWeaver GUI are built on the library, so every tool sees the same functions and the same checks. A mock Donguru in the library runs test scripts without hardware.

FIG. 5 · Software

CLI · works today

dg device list              # every Donguru on USB: serial, path, label, API version
dg info                     # firmware, board, variant, last reset
dg power status             # plug VBUS, header VBUS_SW and the meter in one read
dg power on --trip 1.5A     # VBUS to the device, cut above 1.5 A
dg power cycle --off 500ms  # off, wait, back on through the same checks
dg power watch --on-change  # voltage, current, power as they change
dg power totals             # charge and energy since the last reset, mAh / mWh
dg usb disconnect           # cut the device's USB data; connect brings it back
dg header relay on          # close the isolated relay contact
dg swd memtest --chip STM32G0B1CEUx   # check the SWD link at each speed
dg device log --follow      # the firmware's log, decoded on the PC

Rust · works today

use donguru_core::{Dongle, vbus};

#[tokio::main]
async fn main() -> donguru_core::Result<()> {
    let dg = Dongle::open(None).await?;           // the one on USB, or as in donguru.toml
    dg.plug().set_vbus_mode(vbus::auto(5.5, 1.5)).await?; // cut above 5.5 V or 1.5 A
    let r = dg.meter().reading().await?;
    println!("{} V, {} A", r.vbus_in, r.current);
    Ok(())
}

Python · planned

from donguru import Donguru

dg = Donguru.connect()                  # first on USB; or Donguru.connect(serial="B153B-042")
dg.plug.vbus_on(max_voltage=5.5, trip_current=1.5)
r = dg.meter.reading()
print(f"{r.vbus_in:.2f} V  {r.current * 1000:.0f} mA")

dg.plug.vbus_cycle(off=0.5)             # power cycle the device
dg.usb.disconnect(); dg.usb.connect()   # make it re-enumerate

dg CLI

--format json or jsonl on every command for scripts, and exit codes that tell a refused request from a missing dongle. Completion for bash, zsh and fish. Planned for v1.0: dg uart, dg i2c, dg gpio.

probe-rs and friends

probe-rs uses the probe directly: probe-rs run --chip STM32G0B1CEUx firmware.elf with Donguru plugged in. OpenOCD and pyOCD find it like any other CMSIS-DAP probe.

IOWeaver planned for v1.0

The GUI for Donguru and rePort: power, the meter, the switches and every bus on one screen, on the desktop or in the browser. Zero setup: Donguru brings up its own small network over USB with a start page, so any browser reaches it with nothing to install.

Documentation · Source on GitHub · IOWeaver

07Use cases

Where it earns its place

Development

Bring-up of a device with a USB-C port: its USB, its console and its power on one cable, with the current it draws on the meter.

Debugging

Flash and debug over SWD on the sideband pins with probe-rs, OpenOCD or pyOCD, and read the UART on the same cable.

Automated test benches

Power cycling, current logging and USB re-enumeration from a script, with limits that hold even when the script doesn't.

Production flashing

Test and program the product through its own USB-C connector. One Donguru can flash another through the receptacle's SBU pins.

08FAQ

Questions the datasheet answers

What is the difference between Main and Plus?

Both have the VBUS switch, the meter, PD on both ports, SBU and header IO, the relay and the SWD probe. Plus has a 4-port hub instead of 2 ports, and adds USB on the 2.54 mm header and USB to the device over the plug's SBU pins. See Main and Plus.

Can a PD charger put 20 V on my 5 V board?

Not with the default mode. ForceOn keeps plug VBUS on only while the computer's VBUS stays at or below the limit, 5.5 V unless asked for more. The firmware checks the limits about every 15 ms: fast enough for a renegotiation, not a fuse. A short circuit is caught by the load switch itself. This is a design target, to be tested on rev B.

What happens when the firmware hangs or the MCU is halted?

Every enable has a pull-down. Plug VBUS, the header's VBUS_SW and the relay are off; the device's USB data stays connected to the hub. See At reset, halted or unpowered.

Does it work with probe-rs?

Yes. Donguru is a CMSIS-DAP v2 probe on the plug's SBU pins, so probe-rs, OpenOCD and pyOCD find it on USB like any other probe. The SWD clock goes up to 3 MHz bit-banged, and up to 4 MHz SPI-driven as an experiment.

What if the cable goes in the other way round?

The orientation is a setting, so a flipped cable is one command rather than re-plugging. UART, I2C and SWD swap their lines; FDCAN on SBU works in one orientation only.

Does my device need a PD controller for the debug path?

No. In debug-accessory mode Donguru pulls both CC pins of the device up. A device recognises that with a few comparators or ADC pins and switches its SWD or UART onto the SBU pins. Devices with a PD controller can be asked the same over PD, with a vendor message.

Can I use the UART as a plain serial port?

That is planned: the SBU UART as a standard USB serial port (CDC-ACM), which terminal programs open as /dev/ttyACM0 or COM3 with no Donguru software at all.

Does Donguru need its own power supply?

No. It runs from whichever side has VBUS, so it keeps working while plug VBUS is off, and a self-powered device can keep it alive.

How fast is the UART?

The baud rate goes up to 8 MBd, with 7 or 8 data bits and no flow control. Receiving runs sustained at 2 MBd (200 kB/s) with any data, without compression, measured on rev A. Above about 2 MBd the firmware compresses what it receives with LZ4 for hosts that support it, so the sustained rate depends on the data; those rates are tbd.

Can I write tests without the hardware?

Yes. The library carries a mock Donguru that follows the same rules as the firmware, for Rust tests today and for Python (Donguru.mock()) with the wheel.

How is its own firmware updated?

Holding the button at power-up starts the STM32 USB bootloader, for a firmware update without a probe.

What does it cost, and when can I get one?

Donguru is coming in Q1–Q2 2027 on CrowdSupply. The price is not set yet. Get notified and we tell you when the campaign opens.

09Launch

Get notified

Donguru launches on CrowdSupply, coming Q1–Q2 2027. Until the campaign page is up, write to hello@vhrd.tech and we let you know.

Get notified
Status
rev A built, rev B in design
Launch
Q1–Q2 2027
Where
CrowdSupply

Datasheet

The PDF datasheet is coming. Until then, this page carries its tables: specifications and pinout, from Preview 0.2, 24 Oct 2026.

Ordering

Part numberProductContents
VHRD-B153Donguru MainDongle, quick-start card
VHRD-B153-PLUSDonguru PlusDongle, quick-start card