Firmware Development Services
Bare-metal and RTOS firmware for ARM Cortex-M, ESP32, Nordic and embedded Linux. Bring-up, driver work, connectivity, safe over-the-air update, and taking over firmware someone else left behind.
Why Firmware Is Not Just Software on Smaller Hardware
Application developers work with effectively unlimited memory, a debugger that always attaches, and the ability to ship a fix in an afternoon. Firmware has none of those. You may have 64 kilobytes of RAM, a bug that only appears after eleven days of running, and a device sitting inside a customer's machine on the other side of the world.
That changes what good practice means. Dynamic allocation is avoided not out of preference but because heap fragmentation over months of uptime is a real failure mode. Interrupt handlers stay short because the timing budget is fixed by hardware. State machines are written explicitly, because a device that is power-cycled mid-operation has to come back to something valid. And every bug is assumed to be reachable in the field, since recalling hardware is not an option.
It also changes what a developer needs to be able to read. A firmware engineer who cannot read a schematic and a datasheet will misdiagnose hardware problems as software problems and waste weeks. Most of the difficult bugs in a new product are somewhere in the boundary between the two, and finding them requires an oscilloscope or a logic analyser rather than a print statement.
What We Do
What we usually get asked for first
Three requests account for most of the firmware work that reaches us, and it is worth knowing which one you are making. The first is a new product that has hardware but no working software yet, where the job is bring-up followed by feature development. The second is a product already selling, where the firmware works but nobody can safely change it, and the real deliverable is a reproducible build plus documentation. The third is a specific defect: a device that locks up after several days, a battery claim that field data contradicts, or a radio that drops its connection in one customer site and nowhere else. Those three have different first weeks, different risks and different prices, so naming yours in the first message shortens the conversation considerably.
Board bring-up and hardware validation
When the first prototype boards arrive, someone has to prove the hardware works before any product features can be trusted. That means clocks and power rails, then each peripheral in turn: does the SPI flash respond, does the sensor return plausible values, does the ADC read what the reference says it should, does the board actually enter and leave its low-power modes.
Bring-up is also when hardware errata surface, and finding them here rather than during system testing saves a board revision. We report findings against the schematic so the hardware team can act on them, including the ones that are cheaper to work around in firmware than to respin.
Device drivers and peripheral integration
Most products need a set of drivers that the vendor's library does not quite provide: a specific sensor over I2C with an awkward initialisation sequence, a display over SPI with tight timing, an external flash with a wear-levelling requirement, a motor controller with a safety interlock.
We write these against the datasheet rather than adapting example code that happens to compile, because example code routinely omits error handling and assumes the happy path on the bus. A driver that does not detect a NACK or a timeout will fail silently in the field, and silent sensor failure is how a device reports confident nonsense for months.
RTOS and scheduling architecture
The decision about whether to use a real-time operating system belongs early, and the honest answer is often no. A device with one sensor, one radio and a simple duty cycle is frequently better as a well-structured super-loop with interrupts, because an RTOS adds memory overhead and a class of concurrency bug that a super-loop cannot have.
Where concurrency is genuinely needed, we build on FreeRTOS or Zephyr with the task structure, priorities and stack sizes reasoned about rather than guessed, and with priority inversion and stack overflow treated as design concerns rather than things to debug later. Zephyr brings more built-in subsystems and more structure; FreeRTOS is lighter and easier to reason about. We pick per product and explain why.
Connectivity: BLE, Wi-Fi, LoRaWAN, cellular and industrial buses
Connected devices spend most of their engineering budget on the connection behaving badly. Bluetooth Low Energy work covers GATT service design, pairing and bonding, and the connection-interval tuning that decides battery life. Wi-Fi on ESP32 covers provisioning, which is a user-experience problem as much as a technical one, and reconnection behaviour when the access point disappears.
For long-range low-power work, LoRaWAN with its duty-cycle constraints; for wide-area, cellular over LTE-M or NB-IoT with careful attention to what the modem does to your power budget. On the industrial side, Modbus over RTU or TCP, CAN and CANopen, and RS-485 networks where electrical noise is part of the problem.
In every case the firmware has to behave sensibly when the network is absent, which means local buffering with a defined overflow policy, backoff that does not hammer a struggling gateway, and time handling that survives a device booting with no idea what the date is.
Power optimisation for battery devices
Battery life is decided by architecture, not by tuning at the end. A device that must run for years on a coin cell spends almost all its time asleep, and the engineering question is how little it can wake up and how briefly.
We measure rather than estimate, because current profiling routinely finds a peripheral left enabled, a pull-up resistor fighting a sleeping pin, or a radio retransmitting more than anyone expected. The output is a measured energy budget per operation and per day, which is what turns a battery-life claim into something you can put on a datasheet honestly.
Bootloaders and over-the-air update
A deployed fleet without a safe update path is a fleet you cannot fix, and retrofitting update capability into a product already in the field is often impossible. This belongs in the first architecture conversation.
We build dual-bank or A/B image layouts so the running firmware is never overwritten by the incoming one, signature verification in the bootloader so an unauthorised image will not run, atomic switchover that survives power loss at any point, and automatic rollback when a new image fails to confirm itself healthy after boot. Where the product is regulated or valuable, secure boot and key provisioning are designed alongside it rather than added later.
Taking over existing firmware
A common situation: the product works, the engineer who wrote it has gone, and nobody can build it. Takeover starts with a reproducible build, which is frequently the hardest step because embedded toolchains are version-sensitive and build steps live in people's habits rather than in scripts.
From there we read the code against the schematic, document what each module does, establish what is tested and what is merely believed, and identify the timing-sensitive sections that must not be casually refactored. We do not rewrite working firmware because it is unfamiliar. The first deliverable is usually a build anyone on your team can run, plus a written map of the system, because that is what removes the key-person risk you actually hired us to remove.
How We Work on Device Projects
Hardware review before firmware
We read the schematic early and comment from a firmware perspective while pin assignment and peripheral selection can still change cheaply. A five-minute conversation at this stage prevents a board respin.
Version control and reproducible builds
Toolchain version pinned, build scripted, output reproducible on a clean machine. If your current firmware only builds on one laptop, fixing that is the first task, not a nicety.
Test on hardware, not only in simulation
Unit tests for the logic that can be isolated, and a hardware-in-the-loop rig for the rest. Timing and peripheral behaviour cannot be validated on a desktop, and pretending otherwise is how firmware passes tests and fails in the field.
Instrument for field diagnosis
Structured logging with severity levels, a fault handler that records why a reset happened rather than restarting silently, and counters for the events you will wish you had counted. Devices in the field cannot be attached to a debugger.
Long-run and abuse testing
Bugs that appear after a week of uptime will not be found in an afternoon. We run soak tests, and we deliberately abuse power, network and input, because that is what customers do accidentally.
Documentation that outlives us
Architecture notes, module map, build instructions, the hardware quirks we worked around and why. The point is that your next engineer does not need us, and that is a deliberate outcome rather than a courtesy.
Where This Fits With Our Other Work
Firmware is one layer of a device product. Embedded systems covers the wider picture where the work spans hardware, firmware and the software around it. Where devices report into a platform, the backend and ingestion side is enterprise integration and data pipeline work, and the fleet dashboard is a normal web build.
If you would rather add engineers to your own team than outsource a project, you can hire IoT developers directly, and for the mobile application that pairs with a BLE device, Flutter or React Native developers handle the phone side. If the device programme needs sequencing before anyone writes code, start with a technology roadmap.
Frequently Asked Questions
What is firmware development?
Firmware is the software that runs on a device rather than a general-purpose computer: a microcontroller in a meter, a sensor node, a motor controller, a medical instrument. It runs close to the hardware, often with no operating system or a small real-time one, within tight limits on memory, processing and power. The discipline differs mainly in its constraints and in the cost of a mistake, since a device in the field cannot always be patched easily.
Which microcontrollers and platforms do you work with?
Predominantly ARM Cortex-M parts: STM32, NXP, Nordic nRF for Bluetooth Low Energy, and Espressif ESP32 where Wi-Fi and cost matter. Also 8-bit parts such as AVR and PIC where the application is simple and unit cost dominates, and embedded Linux on ARM application processors where the workload needs a filesystem, networking stack or display. RTOS work is usually FreeRTOS or Zephyr, and plenty of products are correctly built with no RTOS at all.
Can you take over firmware someone else wrote?
Yes, and it is a large share of what we are asked to do. Takeover starts with getting a reproducible build, often the first real obstacle, since embedded builds tend to depend on a specific toolchain version and sometimes on one engineer's machine. Then comes reading the code against the schematic and datasheets, establishing what is tested, and identifying the timing-sensitive parts. We do not rewrite working firmware because it is unfamiliar.
How do you handle over-the-air firmware updates safely?
With a dual-bank or A/B layout so the running image is never overwritten by the incoming one, a bootloader that verifies a cryptographic signature before switching, and automatic rollback if the new image fails to confirm itself healthy after boot. Updates must survive power loss at any point in the transfer. Designing this in from the start is far cheaper than retrofitting it, and a fleet without safe update is a fleet you cannot fix.
Do you handle certification and compliance testing?
We prepare firmware for it and work alongside your test house rather than replacing them: designing for EMC from the start, keeping the documentation and traceability regulated markets require, and supporting the retest cycle when something fails. For medical, industrial or automotive work, tell us the target standard at the outset, because it changes how the code must be structured and documented, not just what tests run at the end.
Do you work with our hardware team or design the hardware too?
We write firmware and work closely with whoever owns the board. If you have a hardware team or a contract design house, we integrate with them and review schematics from a firmware perspective early, when pin assignment and peripheral choices can still be changed cheaply. We are not a PCB design house, and we will say so rather than subcontract it quietly.