Hybridlink (Open Source ST-Link, DAPLink, WCHLink)

Jolt Connect production device

Hybridlink is an Open Source firmware, written from scratch, emulating ST-Link (containing no proprietary ST code), DAPLink and the WCH-Link. It is targeting the Jolt Connect and the Streamline Connect devices.

One firmware, three personalities, selected at run time:

ST-Link mode - ST-Link/V2-1 compatible. Recognised as a genuine ST-Link by STM32CubeIDE, STM32CubeProgrammer, OpenOCD and the stlink tools.
CMSIS-DAP mode - DAPLink compatible CMSIS-DAP v2, for everything ST's tools don't cover (the RP2350 for example).
WCH-Link mode - WCH-Link compatible, for WCH's CH32V RISC-V microcontrollers over their two-wire RVSWD interface. Works with MounRiver Studio, WCH's OpenOCD, wlink and probe-rs.

All modes include the virtual COM port; the ST-Link and CMSIS-DAP modes also SWO trace. The source is available on GitHub: STM32World/hybridlink (MIT license).

Warning: Hybridlink is work in progress and has not been tested enough yet. It is not shipping on production Jolt Connect or Streamline Connect devices yet (it will soon). Anyone who upgrades a probe at this point does so entirely at their own peril: a failed or interrupted install can leave a probe that needs an SWD reflash, and going back to DAPLink always needs SWD.

Videos

Walk-through and demonstration with focus on STM32:

Demonstration using RP2354:

Background and reasoning

On STs official Youtube channel they have this video (at the time of writing but it will probably get removed quite quickly):

What is said in the video (summarised from the video's automatic captions):

Time	What is said
0:00	The question from the internet: ST makes it easy to develop for its products and offers many IDEs - so when will we get ST-Link? There are tons of clones out there anyway; make it open source so it can be used legally and people can design boards with an onboard programmer/debugger. It would only make STM32 more attractive.
0:35	ST's answer: on demand, ST can offer the ST-Link software for free. Contact your ST representative and ST will deliver binary files for your custom boards - "it's not open source but it's available for free".
0:55	ST wants to make sure the binaries are delivered to the "right people". There is no plan to make it open source.
1:07	A presentation of the STLINK-V3 (about six times faster than the ST-Link/V2-1, SWD up to 24 MHz, I2C, UART, SPI) and the ST-Link/V2-1 that can be snapped off the Nucleo boards.
2:33	Asked whether open sourcing wouldn't simply be easier: no - ST wants to protect the IP, describing it as a proprietary USB protocol and mass storage device.

It would appear we are not "the right people". When we asked ST for the binaries, they refused to provide them.

The question, asked at Embedded World 2019, is one every hardware designer using STM32 has asked at some point: there are tons of ST-Link clones out there anyway, so why not make the firmware open source and let people legally design boards with an onboard programmer/debugger? It would only make STM32 more attractive.

ST's answer was no to open source, but a promise that those who embed ST-Link in their own products would be able to get the firmware binaries.

That promise was never honoured. Years later there is still no way for a small company, a maker or a teacher to legally put an ST-Link on their own board. And this is where it gets truly insane:

The ST-Link hardware design is published by ST themselves. The schematics for the ST-Link/V2-1 on the Nucleo boards are freely downloadable.
The firmware only runs on ST's own microcontrollers. Every ST-Link, genuine or clone, is an STM32 sold by ST.
The firmware is given away for free with every STM32CubeIDE, STM32CubeProgrammer and ST-LinkUpgrade download - it's just encrypted. The "encryption" is AES with a fixed master key, and the per device key is derived from the chip's unique ID. It protects nothing.
Meanwhile the market is flooded with clones running pirated ST firmware, which ST either can't or won't stop. The only people kept out are the honest ones who want to do it legally.
The firmware exists for one purpose: to make it easier to use ST's chips. A debug probe is not ST's product, it's the thing that sells ST's products.

So ST hands the firmware to everyone, encrypted with a key that has been public for years, runs it only on their own silicon - and still won't let anyone ship it. The result is that a company that wants to put an STM32 debugger on a board has two choices: pirate ST's firmware like the clones do, or write their own.

We chose the latter. Hybridlink is written from scratch, from published specifications and from the observed behaviour of ST's tools. It contains no ST code at all: no HAL, no CMSIS device headers, no ST libraries and certainly no ST firmware. The STM32F1 port is written at register level from the reference manual. The CMSIS-DAP part is written from the published protocol specification, not from Arm's reference implementation. The WCH-Link part is written from observing how WCH's own tools talk to a genuine WCH-Link; it contains no WCH code either.

Features

ST-Link mode

USB 0483:3752, the ST-Link/V2-1 layout (without mass storage).
Reports firmware version V2J48M35 by default (configurable, see below). The serial number is the 96-bit chip UID, just like a genuine V2-1.
SWD debugging with STM32CubeIDE (ST-LINK_gdbserver), STM32CubeProgrammer, OpenOCD and stlink (st-flash/st-info).
Virtual COM port.
SWO trace (UART/NRZ, up to 4.5 Mbaud) - works with STM32CubeIDE's Serial Wire Viewer: ITM data console and statistical profiling.
ST's firmware update protocol is implemented in the bootloader, so STM32CubeIDE and ST-LinkUpgrade can still install ST's own firmware on the probe if you want it - and you can switch back to Hybridlink afterwards.

CMSIS-DAP mode

USB 0D28:0204 (the DAPLink identity, so existing udev rules and tool setups just work).
CMSIS-DAP v2 (bulk endpoints, WinUSB through Microsoft OS 2.0 descriptors - no driver needed on Windows).
Works with OpenOCD, pyOCD, probe-rs and the Raspberry Pi Pico tools.
SWD including dormant wake-up and multidrop (TARGETSEL, not yet tested), SWO through DAP_SWO_Data.
Virtual COM port.
Twice as fast as DAPLink on the same hardware: programming an 80 KB image into an RP2350 takes 4.0 s against 8.2 s with DAPLink (CMSIS-DAP v1 build).

WCH-Link mode

USB 1A86:8010, product string "WCH-Link", reporting WCH-Link firmware 2.12 (the CH549 based WCH-Link).
Debugs WCH's CH32V RISC-V microcontrollers over RVSWD, WCH's two-wire debug interface, on the probe's SWCLK and SWDIO pins: SWCLK to the target's CLK (PA14 on a CH32V307), SWDIO to DIO (PA13).
Works with MounRiver Studio (download and debugging), WCH's OpenOCD (programming and GDB), wlink (flash, erase, reset, read protection) and probe-rs.
The probe programs the target's flash itself through the RISC-V debug module. The flash routine the host tools send along (a WCH binary) is received and thrown away, so no WCH code ever runs on the probe.
Virtual COM port, tested at up to 2 Mbit/s.
Tested on the CH32V307. The CH32V20x and V10x use the same interface but are not tested yet. The one-wire SDI of the CH32V003 is not supported.

Not supported: JTAG (the Jolt Connect only routes SWD), SWIM and the USB mass storage drag-and-drop function.

USB power

Both the Jolt Connect and the Streamline Connect bring 5 V and 3.3 V out on the target connector, and their supply easily handles 1 A, so a target board can be powered straight from the probe.

What a USB device may draw is set by what it asks for: each configuration descriptor carries bMaxPower, and USB 2.0 allows at most 500 mA. A genuine ST-Link/V2-1 only asks for 100 mA (bootloader and firmware alike), so a target drawing more than that is over the probe's budget. Hosts and hubs that enforce power budgets (bus-powered hubs, some laptops and single-board computers) may then cut the port or refuse the device.

Hybridlink asks for the USB 2.0 maximum, 500 mA, in every mode and in the bootloader. The probe itself draws only a few tens of milliamps, so most of that is available to the target. Beyond 500 mA it depends on the port: many ports (chargers, USB 3 and USB-C ports) supply more without asking, but the probe does not negotiate it.

Downloads

No toolchain needed - every release on GitHub has:

hybridlink-<version>.tar.gz / .zip - the hybridlink tool (bin/) and all firmware images (share/hybridlink/). Unpack and run bin/hybridlink install (on Windows python bin\hybridlink install). Needs Python 3 with pyusb and cryptography, and dfu-util.
hybridlink-daplink.bin - for probes running DAPLink: drag and drop onto the DAPLINK drive.
hybridlink-full.bin - bootloader and application, for flashing over SWD.

The latest release is always on the releases page; see Release history below for what changed.

Installing

The firmware consists of two parts:

Part	Address	Purpose
Bootloader	`0x08000000`, 15 KiB	USB DFU and ST's update protocol
Configuration page	`0x08003C00`, 1 KiB	Probe mode and reported version
Application	`0x08004000`	The probe itself

Over USB only

No second programmer is needed. On a probe running ST's ST-Link firmware, DAPLink or an older Hybridlink, a single command converts it:

hybridlink install

What happens depends on what is on the probe:

ST's firmware - the tool switches the probe into ST's bootloader and uploads a small installer through ST's own update protocol. The installer replaces ST's bootloader with the Hybridlink bootloader, after which the application is installed with DFU. Probe mode and reported version are kept.
DAPLink - the tool copies hybridlink-daplink.bin to the DAPLINK drive, which DAPLink accepts as a bootloader update. This also works by hand without any tools: drag hybridlink-daplink.bin onto the DAPLINK drive, wait for the drive to come back and reconnect the probe. DAPLink must be running its interface firmware (the DAPLINK drive, not MAINTENANCE) with "Automation allowed: 1" in DETAILS.TXT.
Hybridlink - the bootloader is updated if needed, then the application.

A probe whose microcontroller is read protected (RDP set in the option bytes - some ST-Links leave the factory like that) keeps ST's bootloader. Read protection makes the first 4 KiB of flash unwritable, and lifting it erases the whole chip. In that case Hybridlink is installed as an application under ST's bootloader instead. Everything works the same, including updates and mode switching.

If the probe reports a very old ST-Link version (older than J46, as left behind by old ST firmware), install resets it to the default, so current ST tools accept the probe.

Over SWD

With any other programmer, flash the full image:

st-flash --reset write hybridlink-full.bin 0x08000000

Updating

hybridlink update

Or by hand with dfu-util:

hybridlink dfu
dfu-util -d 0483:3748 -a 0 -D app.bin -R

Going back to ST's firmware

ST-LinkUpgrade (stand alone or from within STM32CubeIDE) works on a Hybridlink probe and installs ST's firmware on top of the Hybridlink bootloader. hybridlink update brings Hybridlink back.

The hybridlink tool

hybridlink is a small Python 3 tool (needs pyusb, cryptography and dfu-util). It runs directly from the source tree (tools/hybridlink) or can be installed together with the firmware images:

git clone https://github.com/STM32World/hybridlink.git
cd hybridlink
git submodule update --init lib/tinyusb
make
sudo make install

This installs hybridlink in /usr/local/bin and the images in /usr/local/share/hybridlink. Use make install PREFIX=~/.local for a user install. Building needs arm-none-eabi-gcc and picolibc.

Command	Purpose
`hybridlink info`	Show mode, versions and target voltage
`hybridlink install`	Convert a probe (ST firmware, DAPLink, older Hybridlink) over USB
`hybridlink update [app.bin]`	Update the application
`hybridlink dfu`	Switch the probe into its bootloader
`hybridlink set-type stlink` / `dap` / `wch`	Switch between ST-Link, CMSIS-DAP and WCH-Link mode
`hybridlink set-version V2J49M36` / `auto` / `default`	Change the ST-Link version the probe reports
`hybridlink swo-status`	Show the probe's SWO receiver (bytes received, delivered, dropped) while a trace session is open

All commands take --serial SN to pick a probe when more than one is connected.

Switching mode

hybridlink set-type dap
hybridlink set-type wch
hybridlink set-type stlink

The mode is stored in the configuration page and the probe restarts in it.

The reported version and STM32CubeIDE

ST's tools check the ST-Link firmware version and refuse to work below a certain version, or nag about updates:

gdbserver	From	Refuses below	Warns below
7.10.0	STM32CubeCLT 1.18	J45	-
(2.2.400 plugin)	STM32CubeIDE 2.1.x	J46	-
7.14.0	STM32CubeIDE 2.2.0	-	J46

Reporting a higher version changes nothing else - ST's tools send exactly the same commands. So in Hybridlink the reported version is just a setting. When a new STM32CubeIDE starts complaining:

hybridlink set-version auto

This runs every ST-LINK_gdbserver it can find against the probe and raises the version until none of them complain.

SWO and the Serial Wire Viewer

SWO works with STM32CubeIDE's Serial Wire Viewer as with a genuine ST-Link. If something looks wrong, run this while the debug session is open:

hybridlink swo-status

It shows how many bytes the probe received from the target, delivered to the host and dropped.

Overflow packets in the SWV views are not lost data in the probe: they are generated by the target's ITM when it produces more trace data than the SWO clock can carry. PC sampling with a timestamp on every packet is the usual cause. A higher timestamp prescaler, a coarser PC sampling resolution or a faster SWO clock helps.

Tested

Probes

Jolt Connect - converted over USB from stock ST firmware V2J48M35 and from DAPLink, both modes.
Streamline Connect - converted over USB from DAPLink 0259.
DIY STM32 Programmer (ST-Link/V2-1) rev D (STM32F103C8, 64 KiB) - converted over USB from ST's V2J32M1 "STM32+Audio" firmware.
DIY STM32 Programmer (ST-Link/V2-1) rev G - read protected; Hybridlink runs under ST's bootloader.

Tools

ST-Link mode, against an STM32F407:

STM32CubeProgrammer: connect, read (~136 KB/s), program and verify.
STM32CubeIDE (ST-LINK_gdbserver): connect, reset, step, hardware breakpoints, Serial Wire Viewer (ITM console and statistical profiling at 2 MHz - 1.8 MB of trace without a lost byte).
OpenOCD 0.12: reset/halt, step, memory access, registers, breakpoints. 128 KiB RAM download in 0.9 s at 4 MHz. Both the stlink and the stlink-dap driver, also on an STM32H723 (since 0.6.0).
stlink: probe, read 512 KiB, write and verify.
ST-LinkUpgrade: installs ST's firmware on the Hybridlink bootloader and switches back.
VCP: 16 KiB at 921600 baud byte exact while SWD is busy.
SWO: 2 Mbaud sustained, byte exact.

CMSIS-DAP mode, against an RP2354 (RP2350) and an STM32F407:

OpenOCD: both Cortex-M33 cores of the RP2350, program and verify at 4 MHz. 512 KiB STM32F407 flash programmed and verified in 16.5 s.
GDB: reset, breakpoints, step, watchpoints.
pyOCD 0.45.
SWO through DAP_SWO_Data at 2 Mbaud.
VCP: random data echoed through the RP2350 at 921600 and 2 Mbit/s without a single error (about 180 kB/s each way at 2 Mbit/s).
Flashing from VS Code with the Pico SDK.

WCH-Link mode, against a CH32V307 (the CH32V307V-R1 board with its own WCH-Link disconnected):

wlink 0.1.3: status, registers, flash (20 KB in about 3 s), erase, reset, read protection on and off.
probe-rs 0.32: list, info, download, reset, memory read.
WCH's OpenOCD: program and verify; GDB with hardware breakpoints, stepping and memory access.
MounRiver Studio 3.0.0: download and debugging - the USB traffic matches the genuine WCH-Link's command for command.
VCP: random data echoed at 921600 and 2 Mbit/s without a single error.

Not tested yet: Windows, multidrop (RP2040), CH32V20x/V10x.

Future

The code is written to be portable: everything outside port/ and boards/ only uses a small hardware abstraction and TinyUSB. Ports to other probe microcontrollers - CH32V407 and RP2350 - are planned, as is support for more CH32 families in WCH-Link mode.

FAQ

Does Hybridlink contain any ST, Arm or WCH code?: No. It is written from scratch on top of TinyUSB. The ST-Link and WCH-Link protocols are re-implemented from the observed behaviour of the vendors' own tools, CMSIS-DAP from the published specification. No vendor firmware, libraries or headers are used or shipped.

Which mode should I use?: ST-Link mode for STM32 work with STM32CubeIDE and STM32CubeProgrammer. CMSIS-DAP mode for everything else that speaks SWD - RP2350 with the Pico SDK, pyOCD, probe-rs. WCH-Link mode for WCH's CH32V RISC-V chips with MounRiver Studio, WCH's OpenOCD, wlink or probe-rs. OpenOCD works in all three. Switching takes a second: hybridlink set-type stlink, dap or wch.

STM32CubeIDE says the ST-Link firmware needs an upgrade.: The version the probe reports is a setting. Run hybridlink set-version auto after installing a new STM32CubeIDE; it raises the reported version until ST's tools are happy.

Can I go back to ST's firmware, or to DAPLink?: ST's firmware: yes, over USB - ST-LinkUpgrade (or STM32CubeIDE's update) works on a Hybridlink probe, and hybridlink update brings Hybridlink back. DAPLink: only over SWD, because DAPLink's bootloader is replaced during the install.

What happens if an install or update is interrupted?: The bootloader writes the first application page last, so an interrupted update simply leaves the probe in its bootloader; run hybridlink update again. Only losing power during the bootloader write itself (well under a second, during install) leaves a probe that needs an SWD reflash.

Which CH32 chips work in WCH-Link mode?: Tested on the CH32V307. The CH32V20x and V10x use the same two-wire RVSWD and flash controller and should work, but are not tested yet. The CH32V003 family uses a one-wire interface (SDI), which is not supported.

Does WCH-Link mode run WCH's flash routine?: No. The host tools send a small flash routine along with every download. Hybridlink receives it and throws it away, and programs the flash itself through the RISC-V debug module.

I have a genuine WCH-Link connected too - which one do the tools use?: Both identify as 1A86:8010, so tools pick the first one they find. Select the probe by serial number (wlink and probe-rs can), or unplug the one you don't want.

Does it support JTAG?: No. The Jolt Connect and Streamline Connect only route SWD to the target connector.

Does it work on Windows?: It should - CMSIS-DAP mode uses WinUSB through Microsoft OS 2.0 descriptors, so no driver is needed - but it has not been tested yet.

The Serial Wire Viewer shows overflow packets. Is the probe losing data?: No. Overflow packets are generated by the target's ITM when it produces more trace than the SWO clock can carry. hybridlink swo-status shows whether the probe dropped anything; it normally hasn't.

Release history

Version	Date	Changes
0.6.0	2026-11-13	New WCH-Link mode: WCH-Link (firmware 2.12) compatible, for WCH's CH32V RISC-V chips over RVSWD. Works with MounRiver Studio, WCH's OpenOCD, wlink and probe-rs; the probe programs the flash itself. ST-Link mode: memory commands now use the access port they name. Fixes OpenOCD's `stlink-dap` driver on chips with several access ports, such as the STM32H723. `hybridlink set-type wch`.
0.5.3	2026-11-12	OpenOCD's `stlink-dap` driver works (queued access port commands). New `hybridlink swo-status`: bytes received, delivered and dropped by the SWO receiver.
0.5.2	2026-11-11	The probe reports its patch level to the `hybridlink` tool.
0.5.1	2026-11-11	SWO: fixes STM32CubeIDE's "SWV info, Failed to read data!!!".
0.5.0	2026-11-11	First public release: ST-Link/V2-1 and CMSIS-DAP v2 modes, bootloader with USB DFU and ST's update protocol, installing over USB from ST firmware, DAPLink or a read protected ST bootloader, release packages.

Miscellaneous links