A finger pressing a button on a development circuit board

Every DFU Button Is a Failure

Firmware updates are inevitable, even for a 45 year old space probe, and so we need to build into our designs the ability to flash new firmware images. While it's unfortunately common to require pressing a "DFU" button to do so, this doesn't scale.

Remotely Challenged

Sending an operator to an installed device will always carry a large cost and possibly downtime. Electrical enclosures have interlocks requiring shutdown before they can be opened. So no matter how small the action required, it can become a show-stopper. Good products avoid this by giving proper thought to ensuring remote operations are seamless.

The Shortest Path

The reason it's common for designs to require the press of a DFU button is that the microcontroller being used already implements a USB DFU bootloader in silicon. Many MCU families ship with a small bootloader burned into ROM, activated on startup by setting a specific pin low or high – which is exactly what the "DFU" button wires up to. The vendor has already done the work of implementing the USB DFU protocol, handling enumeration, and writing the flash routines. From a firmware developer's perspective, this is a complete, tested, free solution that requires zero lines of code.

This is not so much firmware developers being lazy as it is them using what works out of the box. Building a custom field-update mechanism that doesn't require physical access means writing and maintaining your own bootloader, deciding how to validate images, handling power loss mid-write, etc. That's real engineering effort with real consequences if you get it wrong, like bricking a device if the implementation is not sound.

The problem shows up once the device leaves a context where someone can walk up to it. Given our ideals at UMI, this violates holistic system design. The design is serving itself best, but no longer the system as a whole.

DFU at Runtime

The solution is that the firmware upgrade capability needs to always be available to the host. Rather than requiring a special mode entered at boot, the application firmware implements USB DFU and new images can be written even while the device is running normally.

M.2 CAN FD Adapter card held between two fingers.

We provide this on our CAN FD Adapters. Firmware updates can be attempted without interrupting CAN communication, only restarting when the update completes successfully. The process is power-fail safe and ensures the integrity of the firmware image before every trying to boot into it. We own that complexity because it is essential to the value provided by our product.

Back to blog