← All case studiesSystems for harsh environments

A rugged interface that updates in the field and never bricks

A portable, battery-powered unit that powers and controls two remote devices over isolated channels. The hard part was making it reliable far from any lab. Its firmware updates in the field and, if something goes wrong, rolls back on its own to the last working version.

3D render of the control board: microcontroller in the centre, connectors for the two isolated channels on the side, pluggable terminal blocks and power and service connectors
23 tests in ~75 s
automated functional test, 100% pass
3 copies
of the firmware in memory: running, incoming and factory
5 boots
failed, then the bootloader rolls back to the good version
System architecture
Operator PCUSB, service software
Control unitSTM32U5 · ThreadX · 3-partition bootloader
Powersmart battery + charger over SMBus
Isolated channel 1RS-485 up to 10 Mbaud + isolated power
Isolated channel 2RS-485 up to 10 Mbaud + isolated power
Remote devicespowered and monitored by the unit

The context

The client works with systems installed in harsh environments, far from any lab. They needed a portable, battery-powered unit in a rugged case, with which an operator connects their PC to two remote devices to power them, communicate with them and keep them under control.

On paper it is an interface. In practice it brings together problems that are usually tackled one at a time: isolated power, communication in noisy environments, the battery and field updates. And a demanding EMC qualification was on the horizon.

Why it is hard

  • Two channels that must not “touch”. Each carries power and data to a different device: a fault or disturbance on one cable must not reach the other channel or the operator’s PC.
  • Long lines in electrically noisy environments, where a wrong bit becomes a wrong command.
  • The battery powers everything, the unit and the remote devices, and the operator needs to know how much runtime is left.
  • A failed update means a dead unit. There are no programmers or technicians in the field: if the firmware hangs halfway through an update, the unit goes back to the lab.
  • EMC qualification starts with the first schematic, not when the prototype is finished.

The precautions, and why

An architecture split into blocks from the feasibility study. Power, control unit and line interface are separate blocks with clear boundaries. Each block is designed and tested on its own, and a change in one does not ripple into the others.

Galvanic isolation on every channel, for data and power. Each channel has its own isolated power and its own isolated RS-485. The two remote devices, the unit and the PC stay electrically separate, and a disturbance on one cable stays on that cable.

Power measured channel by channel. The voltage and current of every output are measured continuously, so the operator sees at once if a device draws more than expected.

A battery that reports its own charge. Battery and charger talk to the firmware over SMBus, with error checking on every message. The state of charge comes from the battery itself, not from a voltage-based estimate.

RS-485 at 10 Mbaud with DMA and receiver timeout. Differential RS-485 copes with noise on long lines. DMA receives data without loading the CPU, and the receiver’s hardware timeout detects the end of each frame without parsing data byte by byte. The binary protocol carries a CRC on every message.

STM32U5 and ThreadX. The microcontroller draws little while the unit waits on battery, yet has enough memory for three firmware images and hardware accelerators for CRC and hashing, so verifying updates does not load the CPU. ThreadX is deterministic, uses statically allocated memory and has a track record in safety certification: behaviour is predictable and qualification is easier.

A three-partition bootloader. Updates arrive in blocks into a staging partition while the running application keeps working. The switch happens only after full integrity verification. If the new version fails to boot five times in a row, the bootloader rolls back to the last good version on its own. As a last resort there is a factory image that is never overwritten.

The EMC standard read requirement by requirement. Instead of leaving everything to the test lab, we went through the standard item by item, isolated the requirements that apply to this system and grouped them into two test campaigns to contain cost and waiting time.

How we verified it

  • Unit tests on firmware modules, each module specified before being written.
  • High-speed transfers verified byte by byte: 512 kB DMA blocks at 20 Mbps without a single error.
  • RS-485 loopback at 10 Mbaud, half and full duplex.
  • Cross-platform test software with an automated test sequence and a log for every unit.

The result

The functional prototype was released with an automated test of 23 checks in about 75 seconds, passed 100% in the latest campaigns. The unit updates in the field from the operator’s PC and recovers on its own if an update fails: a bad firmware does not cost a trip back to the lab.

What we bring to your projects

Systems with isolated channels and power to remote devices, smart batteries, robust communication over industrial buses, RTOS firmware designed for qualification, secure bootloaders and updates, and automated production testing.

Got a deadline?

Tell us about your project: within 48 hours you get a proposal with phases and dates. If needed, we sign an NDA before seeing your files.