Every production line has a bottleneck hiding in plain sight. The board gets programmed at one station, moved to another for functional test, and maybe a third for calibration. More fixtures, more equipment, more points of failure — and more time between "flashed" and "shipped." I've seen floors where the test station alone adds 30 seconds per board. At volume, that's a line item on your BOM.
In this video I show how to collapse all of that into a single station using the SEGGER Flasher SDK and the SEGGER Flasher Compact. The Flasher hosts an S32 virtual CPU, which means you can write ordinary C applications, compile them to a .pex file, drop them on the Flasher, and have them run standalone — no PC attached. One button press programs the board, then runs your custom test and validation sequence.
The demo is a real one: a flatsat I use as a propulsion-system simulator, built around an STM32U585 IoT Discovery board driving a BLDC motor (the pump) and LEDs (the valves). The Flasher Compact is powered from a wall outlet only. Press PROG, and it flashes the target, then talks to it over a USART built from two spare pins on the 20-pin ARM connector, sending Protobuf command frames, parsing the telemetry that comes back, and confirming the hardware actually works before the board leaves the fixture.
I walk through the whole thing end to end — the wiring, the C source, the Flasher App Builder CLI, the build-and-go workflow, how to lay out the project folder on the Flasher's mass storage device, and the one flasher.ini detail that's very easy to miss and will leave you staring at error 255.
📖 READ THE COMPANION BLOG POST
"SEGGER Flasher SDK: Build Custom Production Test Apps"
https://www.beningo.com/segger-flasher-sdk/
The post covers the simpler on-ramp examples — an 84-byte LED blink app, a UART loopback test, pin configuration, how the Go vs. Run workflows differ, why the sandboxed 64KB address space makes this safe to run on production hardware, and a look at emApps, SEGGER's standalone virtualization platform. Start there, then build up to something like the end-of-line tester in this video.
⏱️ CHAPTERS
00:00 The bottleneck hiding on your production line
00:47 What the Flasher SDK and Flasher Compact actually let you do
01:26 The flatsat: a propulsion system simulator as the DUT
02:06 Live demo — one button press, program + validate
04:54 Behind the scenes: the Flasher SDK ecosystem
05:06 The S32 virtual CPU, the C compiler, and .pex files
07:52 Where to find the blog post and the basic examples
08:21 Wiring: the 20-pin connector and keeping SWD intact
09:01 Repurposing spare pins 5 and 11 as UART TX/RX
10:19 Inside the C application: macros, telemetry parser, frames
12:51 Flasher SDK 2.2 and the Flasher App Builder CLI
13:49 CLI options and why I use "go"
14:24 Compiling and running the end-of-line test live
16:28 Building the project folder: firmware, config, and the .pex
17:42 Loading the Flasher Compact as a mass storage device
18:58 The flasher.ini gotcha (and the error 255 it causes)
20:57 Why this matters: one fixture instead of three
22:46 Full sequence, one more time
🔧 HARDWARE & TOOLS SHOWN
• SEGGER Flasher Compact (Zynq-7000 based, running embOS Ultra)
• SEGGER Flasher SDK v2.2 + S32 C Compiler + Flasher App Builder
• STM32U585 IoT Discovery Kit
• BLDC motor control board (pump simulation) and LED valve simulation
• Protobuf-based command/telemetry protocol over USART
💡 WHO THIS IS FOR
Embedded engineers, test engineers, and manufacturing teams who are tired of shuttling boards between a programming fixture, a test fixture, and a calibration fixture — and anyone who didn't realize their flash programmer could run their code.
Questions about the setup, the SDK, or the flatsat? Leave a comment below and I'll answer.
Happy coding!
— Jacob Beningo
#EmbeddedSystems #SEGGER #FirmwareEngineering #ProductionTest #EndOfLineTest #EmbeddedC #Manufacturing #STM32 #FlashProgramming #TestAutomation
