Why founders pick Nordic for low-power BLE
Nordic's nRF52 family has been the default low-power BLE silicon for a decade because the radio is efficient, the SoftDevice / Zephyr Bluetooth stack is mature, and the tooling — nRF Connect, PPK II, Cellular Monitor — actually helps you debug. We ship on Nordic every week and have a tuned bring-up checklist for new boards.
What we build on Nordic
Zephyr / nRF Connect SDK
New programs default to nRF Connect SDK (built on Zephyr). Device tree, Kconfig, Zephyr Bluetooth host + Nordic controller — set up so your codebase is easy to maintain past v1.
nRF5 SDK + SoftDevice
Legacy projects on the nRF5 SDK with S132 / S140 SoftDevice are routine for us — both maintenance and migration paths.
Power profiling, in real units
Every release ends with a Nordic PPK II current trace covering sleep, advertising, connected idle, and active states. Battery model is grounded in measurement.
Sensor fusion
IMU, magnetometer, biosignal front-ends. Sensor processing routed through Zephyr device drivers and event-driven application architecture.
Secure boot & signed DFU
MCUboot with code-signed images, A/B partitions, rollback on boot failure, nRF Secure DFU for the legacy SDK.
nRF5340 dual-core
Application core for app logic, network core for BLE stack and radio. We have shipped products that use the security split to isolate signed update logic from application code.
The Nordic bring-up checklist we follow
- Bootloader + secure boot first. Get MCUboot signed images working before you write a line of application code.
- Sleep current second. Measure idle on PPK II before adding any peripherals. A 50 µA leak you find now is a 50 µA leak you do not find later.
- BLE next. Get a connection up with a real phone, nRF Connect Mobile, and your service UUID before adding GATT logic.
- Sensors and pipelines. Bring up sensors one at a time. SPI / I²C protocol capture on Saleae before believing any datasheet bring-up.
- OTA last. Wire OTA only after the application is stable. Test rollback by intentionally corrupting an image.
Stack we ship on Nordic
| Layer | What we use |
|---|---|
| Silicon | nRF52832, nRF52840, nRF5340, nRF54L when available |
| SDK / RTOS | nRF Connect SDK (Zephyr), nRF5 SDK with SoftDevice S132 / S140 (legacy) |
| Bootloader | MCUboot, Nordic Secure DFU |
| Security | ARM TrustZone (nRF5340), KMU key storage, ATECC608 for external keys |
| Tools | SEGGER J-Link Ultra+, Nordic PPK II, nRF Connect for VS Code, Ozone, Wireshark over Ubertooth |
Proof — Nordic programs we have shipped
FAQ
Zephyr or nRF Connect SDK?
nRF Connect SDK is built on Zephyr, so for new programs we default to it — you get upstream Zephyr plus Nordic's BLE, OTA, and security libraries. Legacy projects on the nRF5 SDK and SoftDevice are routine for us to maintain or migrate.
How low can you push sleep current on nRF52?
On nRF52832 we have shipped 1.5–3 µA sleep current in a connected-but-idle state, measured on a Nordic PPK II. The exact number depends on which peripherals are clocked, the high-frequency oscillator strategy, and the BLE connection parameters.
Do you support secure boot and signed OTA on Nordic?
Yes. MCUboot with code-signed images, A/B partitions, automatic rollback on boot failure. On nRF5340 we use the application core for OTA orchestration and the network core for BLE when device complexity justifies it.
Can you do nRF + TI ADS1299 or other biosignal front-ends?
Yes. EEG headsets on nRF52 + TI ADS1299 over SPI, ECG / PPG devices with Maxim and ADI front-ends. Bring-up checklist and signal-quality validation are routine.
Nordic firmware contractor for hire
Bring your nRF52 / nRF5340 project — clean sheet or rescue — and we will tell you what we would do in 30 minutes.
Book a free 30-min call