(Embedded software)

Embedded software for hardware that has to work unattended

Embedded software development is judged by what happens when nobody is watching: a device that reboots cleanly, a battery that lasts the quoted year, and an update that cannot brick the fleet.

Talk to an engineer What we deliver
Interactive product render
Embedded software

(Close to the metal)

Firmware has nowhere to hide. There is no autoscaling, no rolling back a container, and often no screen to show an error on. A bug that ships is a bug in a thousand boxes on a thousand shelves, and the fix has to reach them over a radio link that might be asleep.

So the work is slower and more written-down than application development. That is not ceremony — it is the cost of not sending an engineer to site.

(What we deliver)

Embedded and firmware work we take on

Engagements usually start at bring-up or at a stalled firmware project. Hardware design is handled with partner electronics teams when you do not have your own.

  1. First light on new silicon: clocks, power rails, boot sequence, memory, JTAG or SWD debug access, then a blinking LED that proves the toolchain end to end. Schematic review happens before the boards arrive, because a pin conflict caught on paper is free.

  2. SPI, I²C, UART, CAN, USB, ADC and DMA drivers written against the datasheet and the errata sheet, not copied from a vendor example. A hardware abstraction layer underneath so application logic can be compiled and tested on a workstation.

  3. Zephyr, FreeRTOS or a bare-metal superloop, chosen by what the device has to guarantee. Task priorities, stack sizing, interrupt latency and watchdog strategy are decided deliberately and documented, because that is where field hangs come from.

  4. BLE, Wi-Fi, LoRaWAN, NB-IoT, Matter or plain MQTT over cellular, with the reconnection and back-off logic that decides whether the fleet survives a network outage. Protocol choice follows the power budget and the site survey.

  5. A signed-image update path with A/B partitions, a bootloader that verifies before it commits, resumable downloads over unreliable links, staged rollout and automatic rollback on failed boot. Built early, because retrofitting OTA onto shipped devices rarely ends well.

  6. Measuring real current draw across sleep states with a power analyser, then cutting the wake-ups, the radio chatter and the polling that dominate the budget. A quoted battery life should come from a measurement, not a spreadsheet.

(Silicon and tooling)

(How we work)

Firmware follows the hardware calendar

Boards arrive when they arrive. These phases replace the studio’s usual six so that software is useful before, during and after each hardware spin.

  1. 01

    Requirements and constraints

    Power budget, timing guarantees, memory ceiling, operating temperature, certification targets and expected field life. Written down first, because every later trade-off is settled against this page.

  2. 02

    Schematic and toolchain review

    Comments on pin assignment, debug headers, test points and boot straps while the layout can still change. Toolchain, build system and continuous integration are stood up in parallel so nothing waits on hardware.

  3. 03

    Simulation and host-side build

    Drivers behind a HAL, application logic compiled for the workstation, protocol and state machines tested in Renode or QEMU. Weeks of bugs get found before the first board is powered.

  4. 04

    Bring-up on real boards

    Power, clocks, boot, peripherals, then each driver validated with a scope or logic analyser rather than a print statement. Findings feed straight back to the electronics team while a respin is still affordable.

  5. 05

    Integration and field trial

    Full firmware on a small fleet in real conditions — cold, distant, badly powered, poorly covered. Logs come home, the failure modes get reproduced on the bench, and OTA is exercised properly before volume.

  6. 06

    Release and sustain

    Signed production images, a versioning and rollout plan, manufacturing test firmware, and a maintenance arrangement for errata, security patches and the next silicon shortage substitution.

(Why Team of Keys)

How we keep firmware faults out of the field

Recalls, truck rolls and bricked units are the real cost of embedded defects. Most of them trace back to three habits that are cheap to adopt early.

  1. 01

    Tested on hardware, in the pipeline

    A rack of target boards runs the test suite on every commit. Unit tests on the host catch logic; only a real device catches timing, brown-outs and the peripheral that behaves unlike its datasheet.

  2. 02

    An update path before the first shipment

    Secure OTA with verified images and automatic rollback is built in the first release, not the third. It is the difference between a field bug costing an afternoon and costing a fleet.

  3. 03

    Portable code, replaceable parts

    Hardware abstraction keeps the application independent of the chip. When a part goes out of stock — and it does — the port is a known amount of work rather than a rewrite.

  4. 04

    Ready for the certification lab

    Test hooks, calibration modes and documentation are built for EMC, radio and safety submissions as a practice. Failing a lab booking on a missing test mode is an expensive way to learn.

(Related)

More in development

All development services

(FAQ)

Questions, answered

Firmware, drivers and on-device software are done in-house. For schematic capture, PCB layout and manufacturing we work alongside electronics partners or your existing design house, and we review their work from the software side — pin mapping, debug access, test points and boot configuration — before boards are ordered.

It is driven by peripheral count, certification scope and how new the hardware is. A sensor node on a well-supported module with an existing reference design is a modest project; a custom board with a radio stack, safety requirements and an OTA fleet is a much larger one. Scoping produces a phase plan with a price against each phase.

Most often STM32, Nordic nRF52 and nRF53, ESP32 and NXP i.MX, running Zephyr, FreeRTOS or bare metal, plus embedded Linux with Yocto on the larger parts. If your platform is already chosen we work within it; if it is not, the selection follows power, peripherals, long-term availability and the quality of the vendor’s support.

Three layers. Logic runs on the workstation behind a hardware abstraction layer, whole-system behaviour runs in Renode or QEMU, and the real firmware runs on target boards in a test rack wired to the build server. Devices live in our lab or yours, with remote power control so a hung board can be recovered.

Yes, and it starts with a read rather than a rewrite. A week or two on the code, the build, the hardware and the bug history produces a written assessment: what is sound, what is unsafe, what has no tests. Usually the first work is a reproducible build and a test rack, because without those nothing can be changed with confidence.

(Global presence)

Nine countries, one studio behind them.

Every project is designed, built and shipped from one studio.
Turn the globe, or pick a country to see what we deliver there.

NoidaDrag to turn

Studio · Noida, India · --:--

(Next step)

Tell us what the device has to do

Send the schematic, the datasheet or just the product idea and the battery target. You get a technical read on the board, the firmware and the risks, with a phase plan to follow.

START

Or write to info@teamofkeys.com · Noida, India