Firmware on STM32, from bring-up to the production build.
Drivers, timing, communication stacks and the flashing procedure your line will actually use. Written by the same people who can read the schematic, and usually who drew it.
What this is
STM32 firmware is the code that runs on the microcontroller itself: no operating system underneath it worth the name, no package manager, and no way to attach a debugger once the board is inside a machine on a customer's floor. Getting it right is mostly about the parts that are invisible in a demo, which is why so much embedded work looks finished long before it is.
We write it from first power-on. That means bring-up in the order that isolates faults rather than the order that looks fastest: clock tree, then power rails under load, then one peripheral at a time with a scope on it. A board that boots on the third day of a project and a board that boots because three unrelated things happen to line up look identical until the first temperature cycle.
Most of this work arrives attached to something else. A custom board we designed, a machine that has to talk to a PLC, a sensor whose vendor library does not survive contact with an interrupt. We do the firmware as part of the system rather than as a component thrown over a wall, because the interesting failures live at the boundary between the firmware and whatever it is bolted to.
What you get
Board bring-up
Clock, power, memory and each peripheral verified individually, with the measurements written down rather than remembered.
Drivers and HAL layer
Written against the datasheet where the vendor library is unreliable, which on some peripherals it is.
RTOS or bare-metal, argued
Whichever the timing budget actually needs. FreeRTOS is a default, not an answer, and a superloop is often the right call.
Communication stacks
UART, SPI, I2C, CAN, USB or Ethernet, including the error handling and the recovery path when the other end goes away.
Bootloader and field update
So a unit already installed can be updated without somebody driving to it with a programmer.
Production flashing procedure
The exact steps, fixtures and checks your assembly line runs, documented for people who are not us.
Test rig
Hardware-in-the-loop where the volume justifies it, so a regression is caught on a bench rather than in a field.
The source, and the toolchain that builds it
Repository, build scripts and documentation handed over. You can build the exact binary without us.
When this fits, and when it does not
A good fit
- You have a custom board, or you need one, and the firmware has to come from the same place as the schematic.
- The device has to talk to industrial equipment: PLCs, drives, sensors, a fieldbus.
- Timing matters and you have already found that a Raspberry Pi and Python cannot hold it.
- Somebody wrote firmware that mostly works and nobody left understands it.
- You need the thing certified, and that means the firmware has to be legible to an auditor.
Not a good fit
- You want the cheapest possible firmware for a one-off prototype that will never be manufactured. A freelancer will be cheaper and that is the right answer.
- The product is really an app and the hardware is an off-the-shelf module. Talk to us about the app instead.
- Safety certification to IEC 61508 or ISO 26262. We build to be auditable, but we are not a functional-safety house and will say so rather than learn on your project.
- You need somebody on site every day. We visit when a machine has to be seen rather than described, but the work is mostly remote.
How it runs
- 01
Read the hardware
Schematic, datasheets and whatever firmware exists. You get a written list of what will be difficult before anybody quotes a number.
- 02
Bring-up
First power-on, peripheral by peripheral, on the real board. This is where surprises live and where the schedule is actually decided.
- 03
Build
Drivers, application logic and the communication layer, in the order that keeps something demonstrable on the bench at all times.
- 04
Harden
Brown-out, watchdog, what happens when the bus partner disappears mid-frame, what happens after ten thousand power cycles.
- 05
Hand over
Production flashing procedure, documentation and the repository. Plus support afterwards if you want it, and none if you do not.
Questions we get
Do you design the board too?
Often, yes. Custom PCB design is in-house, and when the same team draws the schematic and writes the firmware, the pin that turns out to be on the wrong timer gets found in the layout review rather than after the boards arrive. We are equally happy taking a board somebody else designed.
Which STM32 family do you work with?
F0 through F7, G0 and G4, H7, and the L series where power budget drives the choice. If you have not picked yet, that decision usually falls out of the timing and power requirements in the first week rather than being made up front.
Can you take over firmware somebody else wrote?
Yes, and it is common. We start by building it, flashing it and reading it, in that order, then write down what is actually there. A rewrite is the last resort. Most of these projects need three things fixed and a build that reproduces.
Who owns the code?
You do. Repository, toolchain and documentation are handed over as part of the engagement, not held back after it.
More robotics and electronics
Have a board that needs firmware?
Send the schematic, or just describe the machine. An engineer reads it and you get a straight answer about whether we are the right people for it.