Gopalakrishnan M
05. March 2024 Categories: Technology,

In the last blog, we have covered introduction to bootloader, its different stages and its features. In the current IoT world, electronic products in all domains require a software update to add new features and improve performance for consumers. This way product owner or OEM can retain the customers with them. This is like a double-sided sword, a failure in software update can make the customer unhappy and OEM can lose a market share of their product. For this a robust DFU (Device firmware update) architecture is required. In today’s blog, we will cover software update design principles and architectures need to aware for developers to build a robust DFU.

Need for robust DFU

An embedded product contains multiple components such as application, bootloader, product configuration etc. So, during firmware update OEM should be able to update each component individually on a need basis. This can be achieved by updating those sections in flash memory using a low-level flash driver. Post upgrade/update, keeping the user experience intact is very critical.
For example,

  1. Android phones after security or OS upgrade also, it should still be connecting with preconfigured wireless configurations. Otherwise, customers need to re-pair their BLE devices which will make them unhappy.
  2. In case of upgrade failure, the phone should still boot with previously known good configurations. In case of failure, if we ask a customer to visit the service center, the customer will be unhappy and stop using the product.

In the field, it’s advisable to do software updates only for components with critical bug fixes, security patches, and performance enhancements.

Software Upgrade process

Let’s take an example of electronic product used by everyone i.e., Smartphone to understand the basics of software upgrade. Smartphone is a powerful embedded product using a processor. It contains components such as bootloaders, kernel (OS), root filesystem, application, and user data components. Software or Firmware upgrade for this system can be achieved by generating and rolling out a single file/image containing all components or by rolling out an individual component file/image for update.

This update image could be downloaded over the internet or local connectivity mechanism and made available completely before the start of the upgrade process (for e.g. Smartphone update). Or the bootloader can download the update image part by part dynamically during the upgrade process (for e.g. ECU update over UDS).

Software Upgrade Process

Software Upgrade Process


In either case, due to power fluctuation or corrupted file an upgrade process can be disturbed and fail. In those situations, consumer experience on usage of the product should not be impacted. So, a robust failure recovery mechanism needs to be implemented as part of DFU architecture. In the DFU architecture, an architect/developer can provision non-volatile storage space for 2 copies of the kernel & application, one as active partition and another for upgrade/golden partition for fallback during failure.

Software Upgrade Process during failure

Software Upgrade Process during failure


Or the bootloader can detect update failure and reinitiate the process once again by itself.

DFU Architecture

Architect can adapt the right device firmware update approach based on the customer impact and resources we have in the product such as RAM, Flash, Boot medium etc. So, there are few approaches possible such as.

  1. DFU – Updating only application
  2. DFU – Updating the bootloader
  3. DFU – Updating the bootloader with recovery

The below sections describe the same in detail.

DFU - Updating only Application

In this case, generally the DFU software is kept separate from the main application as a part of bootloader software. So that the application alone can be updated by keeping the bootloader fixed without any change. The challenge in this architecture is DFU code must be robust. In case of any bug or defect in DFU software after the product is released in market, OEM left with only 3 options,

  1. Either they must recall the product to factory and update using professional tools
  2. They must swap existing products with a new product with fixes and new features.
  3. In case number of devices in market is less, Field engineers can go in person and update the software with wires.
DFU - Updating Only Application

DFU - Updating Only Application


Or the bootloader can detect update failure and reinitiate the process once again by itself.

So, this type of upgrade is preferable only if the number of products is very less in market and possibility of upgrade necessity is very less.

DFU - Updating Bootloader

The number of embedded products in the market is growing every day with more and more features. DFU architecture with only applicate upgrade will not be suitable for all product lines. For example, smartwatch or android phone use cases cannot be deployed with the above limitations. As per Jack Ganssle, on average for every 1000 lines of code developed there are about 50+ bugs. DFU in bootloader is also expected to have bugs. So, the DFU architecture must have provision to update DFU itself on a need basis.

DFU - Updating Bootloader

DFU - Updating Bootloader


To support that, an additional component (DFU updater) is added in the bootloader. This DFU updater is responsible for validating the Bootloader software integrity and flash the same. Post flashing the bootloader software, DFU updater will reboot the device to boot from new Bootloader. The limitation in this architecture is Bootloader software update should never fail in any scenario due to factors such as power failure or corrupted Bootloader software.

DFU – Updating Bootloader with recovery

The above bootloader upgrade failure limitation can be addressed with a slight change in the above architecture. Additionally, a first stage Bootloader component is added to validate the checksum of the second level bootloader and jump to it. In case of checksum failure, the first stage bootloader shall jump to DFU updater to do the second stage bootloader update.

DFU - Updating Bootloader with recovery

DFU - Updating Bootloader with recovery


In this approach, the

  1. First stage Bootloader can be very light and do only one job of validating the checksum and jump.
  2. DFU updater shall be capable of updating Bootloader memory. 
  3. Second stage bootloader software can have the intelligence to update all other components of application.

Conclusion

For an electronic product, firmware upgrade must be robust and DFU architecture needs to be chosen as per device use cases and impact to customer. By choosing the right architecture OEM can have a happy customer experience and retain the market share. At Embien we have designed firmware upgrade from microcontroller to processor and single core to multi core systems for automotive, medical and industrial domains. We have enabled bootloaders with secure upgrade as well setting the root of trust as well.

Subscribe to our Blog