DFU bricking

[lCannon]

What are the failure points of a properly developed DFU for OTA updates?  On a consumer device where a user may do anything and everything to a device that is executing a DFU update, what types of failures could be observed?  We are looking at mostly application updates but may be required to update the SD and bootloader as well.  We are trying to determine what kind and how often failures may occur that would require returns.  My initial assumption is that there would be no way to brick a device if only an application update was occurring but if the SD or bootloader was being updated and a user managed to cut the power or if the device lost connection for too long, it could become a brick.

 

Thank you for any comments and feedback.

[tesc]

Hi,

The DFU solution from nRF5 SDK has very few (if any) failure points.

For SD and bootloader, the image is always downloaded to a separate location in flash than where it will finally be put, so that it does not overwrite existing SD / bootloader. After full download, the image is checked (checksum, signature) before being copied to replace SD / bootloader. Copy to final destination is not performed by the DFU bootloader itself, but outsourced to Master Boot Record (MBR). MBR is located at the beginning of flash, and is where execution always starts on reset. MBR is delivered as part of the SoftDevice, but during DFU the MBR itself is never replaced. MBR does few things (very little complexity) and does those things well (well tested, years of use with almost no issues experienced in the field.) If the flash copy operation fails at any point in the MBR, the operation is continued/restarted on next reset.

For the application, you can choose to either use separate flash ("dual bank DFU", same concept as with bootloader / SD), or to download in place (replacing existing application directly, "single bank DFU").

Now, there are a couple of pitfalls:

• If you:
  • use BLE for transport, and
  • require bonding, and
  • perform single bank application DFU, and
  • the upgrade fails, leaving you with only SD and Bootloader working, and
  • you lose the bonding info on the device delivering the new firmware...
  • ...then you have a bricked device, as it can only be upgraded using the now lost BLE credentials and without application you have no way to establish a new bond.
• We have seen issues where DFU over BLE from a smartphone fails. This may be due to errors in the application used on that phone for performing the upgrade, or BLE related behavior on that device/OS. If that leaves you without a working application on the device, then you must use a different phone for DFU in order to get an application back in. Device is not bricked per se, as using a different smartphone will work.
• Usually you want the DFU process to be triggered from the application. If you can only enter DFU mode from the application (e.g. no "press button x during reset for DFU"), and you upgrade to an application without this functionality, then you cannot enter DFU mode again and you are unable to upgrade the device further. Note that the DFU bootloader will automaticaly enter DFU mode if the application is not present or if the application checksum is wrong, so device will never get bricked if application is corrupted or missing. The pitfall is simply that the upgrade path will be broken by an application not supporting further DFU.
• The size of the DFU bootloader cannot increase. If you need to upgrade to a bootloader that is bigger in size, then it is possible on the nRF52 series, but it is a two step process (first getting a bootloader that can upgrade into a bigger bootloader), and increasing the bootloader size involves erasing and rewriting the UICR flash page, which gives a window where losing power will brick the device.

Most DFU questions that we get here are related to getting DFU to work in the first place, during development. We seldom get questions regarding DFU bricking devices in the field, and when we do it is usually due to one of the pitfalls mentioned above.

Regards,
Terje