Embedded firmware development for devices nobody can visit.
A device that nobody can visit has to look after itself, and writing firmware that does is rarely something a company without embedded engineers can do alone. We have written that kind of firmware for a four-channel LoRaWAN temperature node, now in a field trial of one unit.
The problem
Most firmware works on the bench. The harder question is what it does after running unattended for a long time, when the radio drops out or the processor stops responding. We would typically write firmware on the assumption that it will stall at some point, and give it ways to recover and to be examined afterwards. On our node that meant an independent hardware watchdog and a cap on how long it may sleep. It also meant leaving progress markers where we could read them after a reset, and making two patches to the vendor sleep and timer code.
The same habits would go into a client project. Before the firmware is written, we would agree how the device is to recover if it stops, how its progress can be read after a reset and which parts of any vendor code need review. We would choose the toolchain to suit your team and the part: ours is a vendor SDK built with arduino-cli, but another target might call for a different one. How the node behaves while joining a network is covered on our LoRaWAN sensor design page, and the power side on our low-power IoT page.
Testing firmware that runs unattended means testing the failure paths as well as the working ones. We would deliberately stop the device, cut its network and starve it of supply on the bench, and check that it recovers or reports what happened before it goes anywhere it cannot be reached. We would keep the firmware small and its behaviour predictable, with each sleep, wake and radio step easy to follow, because the person who inherits it may not be the one who wrote it. Where your product already uses a vendor module, we would read its documentation and its known issues first.
What we've built
Firmware for a LoRaWAN temperature node
Firmware for a battery-powered node built on a RAK3172 module, using RUI3 4.2.4 and arduino-cli. It is in a field trial of one unit in a plant room, and is not a product. Recovery rests on several independent protections and not on one fix.
In a trial of one unit; designed from schematic to field trial.
| Layer | What we did | Detail |
|---|---|---|
| Recovery | An independent watchdog with a 32 s timeout resets the node if the main loop stops, and sleep is capped at 20 s. | Verified with a forced hang: the watchdog reset the node and it rejoined by itself |
| Debugging | Progress markers are held in backup registers that survive a reset, and read over ST-Link. | |
| Vendor code | Two patches applied to the vendor RUI3 code that handles sleep and timers. | RUI3 4.2.4 |
| Toolchain | Built with arduino-cli for the STM32WL inside the RAK3172 module. |
How working with us goes
- 01 Scope We agree what has to be built, where it lives and where the data goes.
- 02 Prototype Working hardware and firmware on your bench, tested against real conditions.
- 03 Pilot A small batch on real sites, with fixes folded back into the design.
- 04 Production Design for manufacture, a production run, and support once it is in the field.
Related
PCB design ·LoRaWAN sensor design ·Low-power IoT design ·Embedded firmware and PCB design, London · All sectors →