Embedded firmware
STM32 Firmware Development
Kyros Engineering develops production STM32 firmware across the H7, F4 and U5 families — FreeRTOS and bare-metal, DMA-driven data paths, dual-core boot, HRTIM high-resolution PWM, FDCAN, and field-update systems. We are most often brought in when an STM32 design already exists and is not behaving, or when the architecture is still open and the wrong choice would be expensive to unwind.
Scope this with usMost STM32 work that reaches us is not greenfield. It is a board that boots but drops frames, a DMA ring that corrupts under load, a bootloader that bricks one unit in forty, or a peripheral that was configured from a reference project nobody on the team fully understands.
Those are architecture problems wearing a debugging costume. We start on the bench with the actual hardware, find the mechanism, and then decide what to change — rather than rewriting on instinct and hoping the symptom moves.
Where STM32 projects actually go wrong
The failures cluster. After enough bring-ups you stop guessing and start checking the same short list first.
- Clock tree and PLL configuration copied from an unrelated reference design, leaving peripherals subtly out of spec
- DMA and cache coherency on the H7 — the D-cache will happily serve stale data to a peripheral buffer nobody invalidated
- Interrupt priority inversion that only shows up when two subsystems are busy at once
- Bootloader and flash partitioning that works until the first power loss mid-write
- Peripheral initialisation order, where an enable happens before its filter or message RAM is configured
How we work an STM32 program
Bench first, instrumented, on your hardware. We log with timestamps, capture on the scope or analyser, and reproduce the failure before proposing a fix. A change we cannot demonstrate on the device is not a fix — it is a theory. Firmware is done when the device runs correctly post-operation on real hardware, not when the build compiles and the CRC matches.
Architecture decisions we help make early
If you are still choosing, the cheapest hour you will ever spend is the one before the schematic is frozen.
- RTOS versus bare-metal, sized against your real latency and determinism requirements
- Part selection within the family — memory, cache, core count, peripheral set, and long-term availability
- Data path architecture: DMA, double-buffering, and where the copies actually happen
- Update strategy — dual-bank, A/B, or external flash — decided before the pin map is committed
- Where the safety and diagnostic boundaries sit, if the product is heading for certification
When to call
You probably want this if…
Frequently asked
Can you take over STM32 firmware someone else wrote?
Yes — inherited code is a large share of our work. We start with a read of what exists and a bench reproduction of the problem, then give you a written assessment of what is salvageable before anyone proposes a rewrite. Rewrites are sometimes right, but they are the expensive answer and they deserve evidence.
Do you work in STM32CubeIDE or CMake?
Both. We work in your toolchain so your team owns and can maintain the result. For new projects we usually recommend CMake with arm-none-eabi-gcc, because it makes CI and reproducible builds straightforward.
What is the smallest way to start?
A two-week architecture diagnostic at $6,000. You get a written decision artifact — the architecture read, the risks we found, and what we would do — and you keep it whether or not you engage us for the build.
Do you do CAN work on STM32?
Regularly. On the H7 that means FDCAN rather than bxCAN, with message RAM and filter banks configured before the peripheral is enabled, named ID constants in a shared header, and an RX callback with a dispatch table rather than polling.
Have an STM32 problem that will not reproduce?
Bring us the board and the symptom. We will tell you what we think it is before you commit to a scope.