Every DFU Button Is a Failure<br>– Universal Machine Intelligence
Skip to content
Log in
Country/region
Australia |<br>AUD
Search
Australia
AUD
Austria
EUR
Belgium
EUR
Canada
CAD
Cyprus
EUR
Czechia
CZK<br>Kč
Denmark
DKK<br>kr.
Finland
EUR
France
EUR
Germany
EUR
Hong Kong SAR
HKD
Ireland
EUR
Israel
ILS
Italy
EUR
Japan
JPY
Malaysia
MYR<br>RM
Netherlands
EUR
New Zealand
NZD
Norway
AUD
Poland
PLN<br>zł
Portugal
EUR
Singapore
SGD
South Korea
KRW
Spain
EUR
Sweden
SEK<br>kr
Switzerland
CHF<br>CHF
United Arab Emirates
AED<br>د.إ
United Kingdom
GBP
United States
USD
Search
Log in
Cart
Share
Share
Link
Close share
Copy link
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.
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
Choosing a selection results in a full page refresh.
Opens in a new window.