Two details separate this from a wrapper around a command line. Nicknames bind to the physical MCU rather than the probe, so a name keeps meaning the same board after you move cables around. And serial_sequence exists because a model cannot time separate tool calls: sends, delays, expected responses and memory reads go into one call that runs with real timing. It is built around one specific bench — an ST-Link V3 mini with VCP on the header — and it gives the assistant unsandboxed access to the hardware attached to it.
A Python server that hands an assistant your STM32 toolchain: compile with CubeIDE's headless builder, flash over ST-Link SWD, open serial connections, and read or write memory by address or by variable name resolved from the ELF symbols.
- stm32_build compiles a project through the CubeIDE headless builder, stm32_flash writes an .elf, .bin or .hex over SWD, and stm32_build_and_flash covers both in the one step you usually want
- stm32_list_probes shows every connected board with its MCU ID, and stm32_set_nickname names a board by MCU UID or a probe by ST-Link serial number — board nicknames follow the physical chip across probe swaps, and any probe parameter accepts one
- stm32_board_info reads device ID, flash size and voltage straight off the ST-Link
- Serial work end to end: list the ports with ST-Link VCP ports marked by nickname, connect, send data and read the response, read what is buffered, disconnect
- serial_sequence puts several steps into one call — sends, delays in milliseconds, an expected response, webcam captures and SWD memory reads or writes — so timing happens inside a single tool call instead of across several the model cannot pace
- stm32_read_memory and stm32_write_memory take an address or a variable name looked up in the ELF symbols
- live_memory_start runs continuous background memory monitoring over SWD, live_memory_read returns the recent entries, and live_memory_stop ends the session
- The same code is available as CLI wrappers, and those builds queue behind an agent-driven build on the shared CubeIDE workspace lock rather than colliding with it
Python 3.10 or newer, installed from the repository into a virtualenv — there is no published package. The real toolchain has to be present: STM32CubeIDE at /Applications/STM32CubeIDE.app on macOS or /opt/st/stm32cubeide_* on Linux, OpenOCD for flashing, memory access and live monitoring, the open-source stlink tools for probe enumeration, an ST-Link over USB, and a serial port. The author states plainly that this is not a sandbox: the assistant gets your compiler, debug probe and serial ports, and can flash firmware, overwrite memory and send arbitrary data to whatever is attached.