BLE Firmware for IoT: What You Need to Know Before You Start
You're building a device that needs to pull data from a sensor, blood pressure monitor, scale, or industrial peripheral over Bluetooth. Sounds like a two-week task. In reality, BLE firmware is the highest-risk component of any IoT product. Here's what we learned building a real medical device.
What This Article Covers
We build BLE firmware for embedded devices at QA Platform. One of our projects: an adapter for medical check-up terminals — a compact device that automatically receives blood pressure readings from a Bluetooth tonometer and passes them to an information system.
Simple on paper. In practice: 6 months of development, two production bugs, a detective investigation through 470,000 log lines, and a microcontroller that must run reliably in hundreds of clinics with no way to update remotely.
This article is for decision-makers on IoT products with Bluetooth. CTOs, technical directors, product managers. Not about code — about risks, architecture decisions, and what to look for when choosing a contractor.
First Surprise: Your Device Is Not a "Bluetooth Speaker"
When people hear "Bluetooth," they think of headphones and speakers. Pair, connect, done. In IoT, everything is reversed. Your adapter must:
- Find the target device on its own — no human with a phone
- Connect on its own — multi-step BLE authentication
- Pull data on its own — via a standardized application protocol
- Recover on its own after disconnections, interference, or errors
- Do all of this on a microcontroller with 256 KB of RAM
This is the BLE Central role (like a smartphone), not BLE Peripheral (like headphones). A fundamentally different level of firmware complexity.
What "Adding Bluetooth" Actually Involves
Our adapter receives a blood pressure reading from a commercial tonometer. Here's what the firmware does — every time a patient presses the button:
| Step | What Happens | Time |
|---|---|---|
| Scanning | Firmware searches for the target device by name or stored address | 1–3 sec |
| Connection | Establishes BLE connection at the radio level | < 1 sec |
| Encryption | Key exchange (or restoring previously stored keys) | < 1 sec |
| Service discovery | Full GATT characteristic tree traversal | 1–2 sec |
| Subscription | Registering for data from the tonometer | < 1 sec |
| Waiting | Tonometer measures blood pressure | 20–30 sec |
| Receive & decode | Parsing the packet in IEEE 11073 medical format | instant |
| Forward to host | Result sent to terminal via serial port | instant |
Full cycle: 25–40 seconds. But every step can fail. The firmware must handle every failure mode — no hangs, no data loss, no reboots required.
Three Architecture Decisions That Define Reliability
1. Self-Recovery Without Host Intervention
When BLE drops (and it will — interference, distance, battery), the firmware must return to a working state on its own. No command from the terminal. No reboot.
Our adapter clears internal state on any disconnection and restarts scanning automatically. The terminal doesn't even know something happened.
Business impact: Terminals are deployed in clinics with no IT staff. If the adapter needs manual intervention after every disconnect — that's a service outage, patient complaints, and an engineer dispatch.
2. Persistent Storage for Bonding Keys
BLE devices exchange cryptographic keys on first connection — bonding. If keys are lost on reboot, every connection starts with re-pairing. Some devices (including medical) allow only a limited number of pairing sessions.
Our firmware stores bonding keys and settings in the MCU's flash memory. Power loss, reboot, firmware update — everything persists.
Business impact: Without persistent bonding, every power outage (common in clinics) requires manual re-initialization.
3. Hardware Watchdog Against Freezes
The BLE stack is hundreds of thousands of lines of real-time code. Guaranteeing zero freezes is impossible. But you can guarantee that a freeze lasts no more than 8 seconds: the hardware watchdog reboots the device, and it returns to working state with all settings intact.
Business impact: A device that "sometimes freezes and needs manual reboot" is a dead product. A device that self-reboots in 8 seconds without losing settings is a reliable product.
Bugs That Only Live in the Field
The most treacherous aspect of BLE development: errors you can't reproduce in the lab.
Our firmware passed complete bench testing — hundreds of connections, measurements, disconnections. Everything worked perfectly. In production: 30% of measurements were lost on one device.
How We Found It
Devices deployed nationwide, no physical access. But the host driver logs every exchange with the adapter in systemd journal. We pulled a week's log — 470,000 lines — and ran automated analysis.
Result: 936 measurement sessions, 62 failures:
| Issue | Sessions | Root Cause | Fix |
|---|---|---|---|
| Firmware freeze | 33 | Bug in failed BLE connection handling | Firmware patch |
| Instant disconnect | 8 | Bug in security failure handling | Firmware patch |
| Tonometer not found | 21 | Device off or out of range | Not a firmware bug |
Key insight: The freeze occurred on a radio-level BLE connection error. In the lab, with the tonometer 50 cm away, this error never happens. In a clinic, through a wall, surrounded by a dozen Wi-Fi routers — twice a week. One freeze blocked all measurements for 2+ hours.
Lessons
- BLE firmware must be instrumented for remote diagnostics. Without logs from real devices, you're debugging blind.
- Lab testing under ideal conditions is useless. You need stress tests: long range, interference, thousands of connection cycles.
- Fixing a bug is two lines of code. Finding it is a week of analysis. Team competence shows not in writing code, but in diagnosing problems from indirect data.
What Goes Into BLE Firmware Development
Hardware — module, PCB, antenna, enclosure — is relatively cheap, especially at volume. The real cost is firmware. What's included:
- BLE Central stack — scanning, connection, security, GATT discovery
- Application protocol — parsing the specific device profile (Blood Pressure, Glucose, Weight Scale, or proprietary)
- Host interface — UART, SPI, USB, or whatever's needed
- Reliability — watchdog, self-recovery, persistence
- Testing — bench + field conditions + log analysis
Realistic timeline with an experienced team: 2–4 months to first release, another 1–2 months for stabilization based on production data.
What to Look for in a Contractor
Ask About BLE Central Experience
Most embedded teams have experience with BLE Peripheral (beacons, sensors waiting for a phone connection). BLE Central is a different task entirely. Ask: "Have you built a device that initiates BLE connections to peripherals on its own?"
Ask About Medical Profiles
Standard BLE profiles (Blood Pressure, Glucose, Heart Rate) aren't just "read some bytes." They require mandatory security, indication (not notification), and IEEE 11073 data format. If the team doesn't know what SFLOAT is — they'll spend a month figuring it out.
Ask About Production Debugging
How will they diagnose issues on deployed devices? What logs does the firmware write? Are there AT commands or equivalent for remote diagnostics? If the answer is "we'll attach a debugger" — every bug will require physical access to the device.
Ask About Error Handling
Ask what happens if the BLE connection drops at each phase: during connection, security setup, GATT discovery, subscription. The answer should be the same: "firmware clears state and restarts scanning." If any phase requires a reboot — that's a red flag.
Summary
- BLE Central ≠ BLE Peripheral. A device that initiates connections is an order of magnitude more complex than one that waits for them.
- Bugs live in the air. Lab testing doesn't cover real radio conditions. You need instrumentation for remote diagnostics.
- Hardware is cheap. Firmware isn't. Unit cost at volume is low. Firmware development takes months. Cutting costs on team experience means cutting corners on a working product.
- Reliability is architecture, not testing. Watchdog, self-recovery, persistence — these are designed at the start, not bolted on before release.
We build BLE/IoT firmware for medical, industrial, and consumer devices — from prototype to production.
If your product needs Bluetooth — tell us about your project. We'll estimate timeline and cost without inflated numbers.