Firmware decides how a product behaves on a bad day: when power dips, the network drops or a sensor sends nonsense. We write firmware in C that recovers on its own, can be updated remotely, and tells you what went wrong.
Firmware for a new board, from bring-up to release.
Firmware for a board you already have, or a rewrite of code that has become hard to change.
Drivers and protocols: sensors, displays, BLE, Wi-Fi, LoRa, cellular, Modbus RTU and CAN with UDS diagnostics.
Over-the-air update systems with automatic rollback.
Low-power firmware for battery products.
Taking over a codebase from another vendor.
How we write firmware
We write the watchdog, reset and update paths first, because they decide whether a unit in the field can recover without someone driving to site. Every boot records why the device restarted, and that reason travels with the first message to the cloud.
Communication code gets timeouts, retries and counters from the start. When a Modbus meter stops answering or the cellular link drops, the firmware keeps working, buffers what it can, and reports the problem.
We test on the real board as early as possible. Drivers that pass on a development kit can still fail on a custom board with a different clock, power rail or antenna.
What you get
Source code with build instructions that work on a fresh machine.
A short document on how to flash, configure and update a unit.
Release notes for each version.
A handover session with your engineers, if they will maintain it.
For your engineers
Parts, protocols and tools we use for this work. The full list is on the technologies page.
Embedded C
FreeRTOS
Zephyr
TI SYS/BIOS
ESP-IDF
Bare metal
ESP32 and ESP32-S3
STM32
ST SPC58
TI CC32xx and Tiva C
Nordic nRF
BLE
Wi-Fi
LoRa
LTE Cat-1
Modbus RTU
CAN and UDS
MQTT
OTA updates
Questions about this
Which microcontrollers do you work with?+
Mostly ESP32 and ESP32-S3, STM32, TI CC32xx and Tiva C, Nordic nRF and ST SPC58 for automotive work. New parts are usually a datasheet away from what we already know.
Can you take over firmware written by someone else?+
Yes. We start by reading it and building it on a clean machine, then tell you what we would keep and what we would change before adding features.
How do you handle updates in the field?+
Two firmware slots, a check that the new version starts and connects, and an automatic return to the old version if it does not. A failed update should never need a site visit.
