Wearable Device Firmware: The Constraints That Interact and Where Teams Get Burned

A wearable has a small battery, sensors that run all day, a radio that talks to a phone only some of the time, and a housing pressed against skin. None of these is unusual on its own. Together they produce a class of problems that general embedded experience does not fully prepare you for, because the constraints are coupled: sampling faster improves the signal and drains the battery; connecting more often improves freshness and drains the battery; storing more data protects against disconnection and wears the flash.

This note is a map of those interactions, written for teams starting a wearable or inheriting one that misbehaves in the field. It stays at the level of mechanisms and trade-offs, and links to our deeper notes where a topic has its own. For the engineering we do in this area, see firmware and embedded firmware development.

Power is a property of the whole system

Battery life is not decided by the processor you picked. It is the sum of everything that draws current, weighted by how long it does so. In practice that means the average is dominated by what stays on, not by the peaks everyone remembers to optimize.

Audit wake sources. Every interrupt, timer and peripheral that can wake the core is a line item. A noisy interrupt line or a timer left running can keep the device out of its deepest sleep state without any visible symptom except a short battery life.
Power things off, not just idle. A sensor, regulator or external flash left powered between uses draws current continuously. Decide for each rail whether it is switched, and verify it actually is.
Batch, then sleep. Letting a sensor buffer samples in its own FIFO and waking the processor once to read many of them is usually far cheaper than waking per sample.
Measure, then trust. Current has to be profiled over time on real hardware with real firmware. Spikes from the radio, flash erases and sensor start-up are invisible in a code review. Our note on power profiling firmware covers the method, and MCU selection for battery IoT covers why the part choice should start from a power budget.

The sensor pipeline: timing and signal integrity

Wearable data is only as useful as its timing and cleanliness. The firmware decisions that affect this are easy to treat as plumbing until an algorithm team asks why the data is unusable.

Timestamps must survive sleep. If samples are batched in a sensor FIFO, you need to reconstruct when each one was taken, not when it was read. Clock drift, resets and low-power modes where a timer stops can all corrupt time. Decide early which clock is the source of truth and how it is corrected when the phone reconnects.
Sampling rate is an algorithm requirement. Sample at what the downstream processing needs, not at the maximum the sensor offers. Higher rates cost power, storage and radio airtime.
Motion is noise for some sensors and signal for others. Optical and bioelectric measurements are corrupted by movement; an accelerometer is often the cleanest way to know when to distrust them. Firmware needs to carry that context alongside the raw data.
The analog front end is firmware's problem too. Settling times, gain settings and duty cycling of the front end affect both power and data quality; the PPG signal chain shows how they play out stage by stage. See sensor selection and the analog front end.
Decide where processing lives. Running detection on the device avoids streaming raw data and saves radio energy, at the cost of compute, memory and a harder update story. Our fall-detection wearable work is an example of analyzing motion locally rather than continuously transmitting raw data; the architecture is covered in always-on motion pipeline for fall detection.

Storage when the phone is not there

A wearable cannot assume a connection. Users leave the phone behind, turn Bluetooth off, or move out of range for hours or days. The device becomes a data logger whether or not that was the plan.

Make writes power-loss safe. A battery that browns out mid-write must not corrupt the log or the configuration. Use a structure that tolerates interruption, such as append-only records with integrity checks, or a flash file system designed for it.
Respect flash wear. Frequent small writes to the same region wear it out. Spread writes, buffer in RAM where loss is acceptable, and be explicit about what data is allowed to be lost.
Define the overflow policy. When storage fills, something has to go. Dropping the oldest, the newest, or the least important is a product decision with consequences, and it should be made deliberately rather than discovered.
Plan the reconciliation. When the connection returns, the backlog has to be transferred, deduplicated and acknowledged without repeating or losing records. This is a joint design with the app; see offline-first companion apps.

Bluetooth Low Energy under real conditions

The radio is usually the largest controllable consumer of energy, and its behavior is where the phone, the operating system and your firmware meet.

Connection parameters are a trade-off. Connection interval and latency settings trade responsiveness against power. Pick them for the use case, and expect the phone's operating system to impose or renegotiate values that you must tolerate.
Throughput is not the headline number. Syncing a large backlog depends on the negotiated packet size, the phone, and interference. Design the transfer protocol to be resumable and to make progress in short, unreliable sessions; see BLE throughput and sync protocol design.
Reconnection is the normal case. Links drop. Firmware must recover without user action, avoid advertising more aggressively than needed, and keep state consistent across drops.
Pairing and bonding need a recovery path. Lost bonds and mismatched state between phone and device are a frequent source of support tickets. We cover the user-facing side in BLE pairing UX.

Failure containment: assume it will go wrong unattended

A wearable runs for long periods with nobody watching and nobody able to reboot it easily. Firmware has to be built to recover on its own and to fail in a way that is safe.

Watchdogs, used properly. A watchdog that is fed from a timer interrupt regardless of application health hides hangs. Tie it to evidence that the important work is actually progressing.
Brownout and low-battery behavior. Define what the device does as the battery falls: which features shut down first, how data is saved, and how it restarts cleanly after charging. Voltage sag under radio or motor load can cause resets well before the battery reads as empty.
Persist what you need to diagnose. Reset reasons, fault records and counters stored across resets turn an unexplained field failure into something you can investigate.
Know your safety class. If the device informs a health decision, the expectations change substantially, and fail-safe behavior becomes a design input rather than an add-on. See fail-safe design for medical wearables.

Updates and security on a tiny battery

You will ship bugs, so the device must be updatable, and a wearable is a personal device that may carry sensitive data. Both have energy and storage costs that desktop-class thinking ignores.

Updates must be resumable and reversible. A transfer interrupted by distance or a dying battery should resume, not restart, and a failed image must roll back to a working one. Check that there is enough charge before starting an update at all.
Flash layout is a long-term decision. Space for a second image, a bootloader and persistent data has to be reserved at the start. Retrofitting it later usually means a hardware change.
Verify what you boot. Signed images and a trusted boot chain protect the device and the user data on it. See OTA firmware updates and firmware security and secure boot.
Treat the link as hostile. Authenticate and encrypt what leaves the device, and minimize what is stored on it in the clear.

The body is part of the system

Few embedded products are worn for a living. The physical conditions of wear leak into firmware requirements.

Wear detection. Knowing whether the device is on the body lets firmware stop sensing, change sampling, or discard data. It also needs to be robust to loose fit and to being set down on a table.
Skin contact and environment. Sweat, movement, different skin tones and different fit all change sensor behavior. Firmware that adapts gain or flags low-confidence data is more useful than firmware that silently reports a number.
Heat and charging. A device on skin has tighter thermal limits than one in a box. Charging behavior and any heat from processing or the radio should be designed with that in mind.
Size limits everything. A small enclosure means a small battery, a compact antenna and little room for debug access. Plan test and programming access early; see our smart wearable ring work for an example of a design operating under tight size, power, wireless and sensor constraints.

Testing and validation that matches field use

Test logic off the target. State machines, parsers, storage formats and data handling can be tested on a host machine quickly and repeatedly. See firmware unit testing.
Put real hardware in the loop. Sensors, radios and power rails behave differently from simulations. Automated tests against real devices catch timing and integration faults earlier than manual testing.
Soak for days, not minutes. Memory leaks, counter overflows, clock drift and slow storage problems only appear over long runs.
Measure battery life under realistic use. Datasheet figures describe ideal conditions. Measure with the actual firmware, real connection patterns, realistic user behavior and temperature variation.
Test the unhappy paths. Phone out of range for days, battery at its limit during an update, power removed mid-write, and a corrupted bond. These are the cases that decide whether the product is trusted.

Questions to ask before you start

What is the power budget, and which item in it is the largest?
What is the longest period the device must work without a phone, and what happens to data in that time?
What is the clock source of truth, and how is time corrected?
Which processing runs on the device, and how will that code be updated?
What does the device do at low battery, and after a reset in the field?
Is flash reserved for a second image and persistent logs?
Which regulatory or safety class applies to the data this device produces?
How will battery life be verified on production-like hardware?

How we approach this

We treat these as one design problem rather than separate tickets: power budget, sensing, storage, radio and update strategy are decided together, early, and then measured on real hardware. Our wearable work spans a smart ring, an AI sleep coach, a fall-detection wearable and a remote patient vitals patch, which is where these interactions show up in practice. One of the first architectural decisions in any of them is covered in RTOS versus bare metal.

Common questions

Why is wearable firmware harder than other embedded firmware?

A wearable combines a very small battery, always-on sensing, intermittent wireless connectivity to a phone, contact with skin and long periods without supervision. These constraints interact: a decision that saves power can hurt data quality, and a decision that improves connectivity can cost battery life, so they have to be designed together.

What causes poor battery life in wearables?

Most often it is not the main processor but things that never go to sleep: a peripheral left powered, a bus or interrupt that wakes the processor too often, a radio connection configured more aggressively than the application needs, or a sensor sampled faster than the algorithm requires. These are found by measuring current over time, not by reading code.

How should a wearable handle days without a phone connection?

It should store data locally in a format that survives power loss, keep reliable timestamps across sleep and resets, manage flash wear, and define clearly what is dropped first when storage fills. The companion app then has to reconcile that backlog when the connection returns.

How do you test wearable firmware?

Combine host-based unit tests for logic with hardware-in-the-loop tests against real sensors and radios, long-duration soak tests for leaks and drift, and battery-life measurement on production-like hardware under realistic usage, rather than relying on datasheet figures.