Skip to content
Shenzhen, China · Service

Embedded software and firmware

Firmware that survives the field: bare-metal, RTOS and Embedded Linux, written to be debugged by someone who is not us.

What this solves

  1. The prototype firmware works on the bench and fails intermittently on the line, and nobody can reproduce it.

  2. A silicon vendor's reference BSP is three kernel versions behind and the board needs peripherals it never supported.

  3. Field units need updating and there is no safe path to do it without bricking a customer's device.

Outcomes

What is different afterwards

Deliverables are the artefacts you receive. These are the things that are true once the work is done.

  1. The intermittent failure is reproduced on the bench, named, and fixed — not worked around with a retry

  2. A field unit can be updated safely, and an interrupted update recovers rather than bricking

  3. A production technician can bring up and test a board without an engineer on the call

Datasheet

What we have actually shipped

Every figure here is one already delivered on a published project. Check your requirement against it before you write to us.

Cores
Cortex-M0+ through Cortex-A, C2000 DSP
Runtimes
Bare-metal, FreeRTOS, Embedded Linux (Yocto)
Update
A/B OTA with rollback, signed images
Bring-up
JTAG / SWD, every peripheral exercised and reported
Handover
Reproducible build from a clean checkout
Method

How we work on this

What we actually do

Bare-metal C and C++ where the timing budget leaves no room for a scheduler, FreeRTOS where it does, and Embedded Linux where the product needs a filesystem, a network stack and a package of userspace tooling around it.

Most of the work that matters is not writing the happy path. It is bring-up on a board nobody has powered before, chasing an interrupt that fires once an hour, and building the instrumentation that makes an intermittent fault reproducible.

Bring-up and debugging

We expect to be handed a board that does not boot. Bring-up work is structured: power rails and clocks first, then a minimal boot path, then peripherals one at a time with a test that proves each. Every failure found gets written down, because the same class of fault usually reappears in the next revision.

Update pipelines

An OTA path is a safety feature, not a convenience. We design for the case where power is lost mid-write: A/B partitions or a validated staging slot, a watchdog that rolls back a boot that never reaches userspace, and a signed image so a field device cannot be persuaded to install someone else's firmware.

Handover

Firmware you cannot build is firmware you do not own. Everything ships with a build that runs from a clean checkout on a machine that has never seen the project, and a written account of what each subsystem does and where the known sharp edges are.

A board on the bench with a debug ribbon attached and a debugger session open behind it
Bring-up: every peripheral exercised and reported before firmware is called done.

What you receive

Every engagement ends with a complete handover. The design is yours.

  • Firmware source with a documented build, reproducible from a clean checkout
  • Board bring-up report covering every peripheral, with the failures found and fixed
  • Driver and BSP sources, including any kernel patches, as readable commits
  • OTA update design with rollback, and the test record showing an interrupted update recovers
  • Test procedures a production technician can run without an engineer present

Work in this area

2 published
TMS320F28FOC / DTC11 kW

11 kW sensorless AC servo drive

Sensorless field-oriented control at 380 V and 75 A, validated on elevator traction loads from 3.3 to 7.5 kW.

Read the case study →
BLEsub-5 µAiOS + Android

Sub-5 µA BLE sensor node with companion app

A connected dosing device with flash-backed event logging, native iOS and Android apps, and idle current held below 5 µA.

Read the case study →
Questions

What buyers ask us first

Answered here rather than on a call, because the answer does not change and your time is worth more than a discovery meeting.

Will we get the source, or a binary?
The source, with a build that runs from a clean checkout. Firmware you cannot rebuild is a supplier you cannot leave, and that is not the relationship we want either.
Our vendor BSP is years behind. Can you work from it?
Usually we start from it and then say plainly what has to be replaced. Kernel patches are delivered as readable commits rather than one squashed diff, so your team can carry them forward at the next kernel bump.
Can you take over firmware somebody else wrote?
Yes, and it is a large part of what we do. The first deliverable is a bring-up report covering every peripheral and what we found — including the things the previous team knew about and the things they did not.

Platforms we work with

  • STM32 (F/G/H)
  • nRF52
  • ESP32
  • i.MX
  • TMS320F28
  • Raspberry Pi CM
  • FreeRTOS
  • Embedded Linux
  • Yocto
  • U-Boot
  • Keil
  • IAR
  • GCC / GDB
  • JTAG / SWD

Next step

Send us the hard part.

A schematic, a spec, or a rough idea. We’ll come back within one business day with an honest read on feasibility, risk and timeline.