stlink: the open source replacement for ST's own tools

Four hardware generations, one toolset

stlink is an open source toolset to program and debug STM32 devices and boards manufactured by STMicroelectronics, working through the STLINK programmer boards and their clones, small dongles whose microcontroller translates USB commands into JTAG or SWD. The project supports all four generations on the market, and the README documents each with its transport and its habitats, STLINK/V1, obsolete as of November 2019 yet still supported here, speaking SCSI passthru over USB, found standalone and on STM32VL Discovery boards, V2 and V2-1 on raw USB across Discovery and Nucleo boards, and V3 in its standalone V3SET, V3MINI and V3MODS forms plus the on-board V3E. The sentence that makes the toolset pleasant to operate follows the table, on the user level there is no difference in handling or operation between these revisions, the hardware archaeology is absorbed once, by the library, rather than by every user.

Seven tools from st-info to stlink-gui

The toolset decomposes into focused programs. st-info reports programmer and chip information, the identification tool you run first with unfamiliar hardware. st-flash manipulates flash, the workhorse for writing and reading target memory. st-trace records execution information, the observability tool. st-util is a GDB server, explicitly supported in Visual Studio Code and VSCodium through the Cortex-Debug plugin, which is the documented bridge into a modern editor workflow. st-server serves a local STLINK over TCP for remote stlink tools, letting a programmer attached to one machine serve another, the small feature that laboratory benches and CI racks actually need. Beneath the executables sits stlink-lib, the communication library, and an optional stlink-gui for users who prefer windows to terminals. The naming discipline, every tool prefixed st-, makes the suite discoverable from a shell.

Windows binaries, Linux packages, macOS from source

Installation is documented per platform with the reasons attached. Windows has stand-alone binaries again since release v1.6.1, published on the release page in i686 and x86_64 forms, unzippable anywhere because the archive contains no hardcoded paths, with a suggested Program Files location and the note that the toolset itself is 32-bit. Linux recommends the stlink-tools package from the distribution repository, with links for Debian, Ubuntu, Arch, Alpine, Fedora and FreeBSD, but the README adds a pointed caveat, the Debian and Ubuntu repository packages differ from the project's self-maintained deb, and the latter is recommended because it lets the project handle user-reported package issues directly rather than through external maintenance guidelines. macOS gets the short entry, compile from source, no binaries provided, with CI-only build testing, honest about being the third platform rather than pretending otherwise, and the compiling manual covers the from-source path for every platform.

Documentation as a trio of device lists

The project's confidence lives in three committed documents rather than marketing. supported_devices.md lists the currently known working MCU targets, the make-or-break question for any STM32 family a buyer is considering. version_support.md lists the supported operating systems, so the OpenBSD user quoted in the reviews section and the FreeBSD user reading the package links can both check their standing before compiling. tutorial.md carries advanced tasks and additional how-to material beyond the README's basics. Together they form the contract the toolset offers, hardware support stated per chip, platform support stated per OS, procedures stated per task, and a CHANGELOG recording what each release changed, the documentation shape of a tool people rely on to recover bricked boards, where guessing is expensive.

A Makefile that drives CMake politely

The build system wraps CMake in a Makefile veneer, and the wrapper's help text reads like a menu, debug, release, install, uninstall, package, lint, test, clean and rebuild_cache targets, each invoking the corresponding CMake build directory. The ci target chains debug, release and test for the automation pipeline, the test target builds the debug tree and runs the suite there, and CMAKEFLAGS is exposed for an install-prefix override, the example in the file pointing at a home-directory install for users without root. Around it, the repository carries vcpkg.json for Windows dependency management, gen_binaries scripts for both MSVC and shell environments producing the release archives, a debian directory feeding the self-maintained packages, and a flashloaders directory, the target-side stubs the toolset uploads to drive flashing on the MCU itself. It is orthodox systems plumbing, maintained with visible care, including CodeQL and C/C++ GitHub Actions workflows for static analysis and building.

Contribution rules with a sharp edge about hashes

The contributing section mixes the standard with the memorably specific. Semantic versioning governs releases. Before creating a pull request, always open a new issue to discuss intended features, bugfixes exempt but expected to be described in a few words when they appear. Forks should start from the develop branch, since pull requests land there. And then the rule typeset in capital letters, never ever use the hash character to count up points in a listing, because hash is exclusively reserved for referencing GitHub issues and pull requests, and casual counting accidentally introduces false cross-references across the project. A rule that particular can only exist because someone watched it happen, and it tells a newcomer exactly what review culture to expect, one that has been burned by tooling behavior and wrote the scar tissue down. A code of conduct and contribution guidelines back it up formally.

A user review as the closing argument

The README ends, unusually, with a user review quoted in full, an OpenBSD user writing in December 2021 that after frustration with AVR tooling, stlink building out of the box without touching anything made their weekend, thanking the maintainers for software that is not unfriendly to the fringe operating systems. Choosing to close the front page with gratitude rather than a feature list is a statement about who the project serves, embedded developers on whatever platform they landed on, including the ones the commercial vendors forgot. The release cadence is unhurried, v1.6.1 in May 2020, v1.7.0 in April 2021 and v1.8.0 in January 2024, with the repository's last push on 2026-09-23, the steady heartbeat of a toolset that is finished more often than it changes, and the maintainers' names in the review, Nightwalker-87 and xor-gate among them, mark it as stewarded rather than abandoned.

Editorial conclusion

Use stlink when you flash or debug STM32 targets and want open source tooling that treats all STLINK generations and their clones identically, integrates with GDB and VS Code, and ships for your platform. Use STMicroelectronics' proprietary utilities when a workflow depends on their specific features or vendor support chains. Verify first that your exact MCU appears in supported_devices.md and your OS in version_support.md, prefer the project's own deb packages over the Debian and Ubuntu repository versions as the README advises, and remember macOS users must compile from source since no binaries are provided.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. README
4. Releases
5. stlink-org/stlink on GitHub