Firmware is the software that is permanently stored on embedded systems and IoT devices. It plays a critical role in ensuring that the device works as intended and can be updated to fix bugs or add new features to optimize the product’s added value.
With the increasing number of connected devices and the growing threat of cyber-attacks, it is important for embedded systems to have robust firmware upgrade features. These features allow device manufacturers and users to easily update the firmware on their devices to address security vulnerabilities and prevent hackers from taking control of the devices.
One of the key benefits of firmware upgrade features is that they allow device manufacturers to quickly and easily address security vulnerabilities as they are discovered. In addition to protecting against security threats, firmware upgrade features can also be used to add new features and functionalities to a device. This can be especially useful in the case of IoT (Internet of Things) devices, which are becoming increasingly popular and are expected to have a long lifespan. By regularly updating the firmware on these devices, manufacturers can ensure that they remain relevant and useful over time.
Overall, the importance of firmware upgrade features in embedded systems cannot be overstated. These features play a critical role in ensuring the security and longevity of devices and are essential for protecting against the growing threat of cyber-attacks. Advanced IoT products often consist of multiple processors with their distinct roles, each having standalone firmware components, but mounted on the same PCB or inside the same product. Firmware upgrade complexity of such a system is significant and cumbersome to implement and thus IRNAS and AVSystem have been working together to provide a good example on how to do this on Nordic Semiconductor platforms. The primary challenge of the state of technology to date is that there are no defacto solutions in place and each product has a slightly custom solution in place versus for example Bluetooth DFU setup which has a common implementation of Nordic Semiconductor devices.
Remote Firmware Updating is Instrumental in Environmental Sustainability of Solutions
At IRNAS, we are putting environmental sustainability and carbon footprint minimization as our top priority, incorporating the principles of better devices manifesto in our daily work. Remote firmware update functionality lengthens the lifespan of devices, reducing the risk of them being obsolete, minimizes human intervention at remote sites, and unlocks the possibilities for the devices to follow the fast technological maturity process in the long run.
Long-term Cybersecurity with Remote Firmware Update Capabilities
With cybersecurity becoming an integral part of the RED directive (fully coming into action in August 2024), device manufacturers will have to step up their game in long-term thinking related to cybersecurity, encryption, and other aspects of development. As these mature, it is important to ensure the device is long-term compatible with these requirements, which is impossible without remote update capabilities.
See the article on The proposed EU Cyber Resilience Act.
Ready-to-use solution for firmware upgrade: example
An example solution is introduced using the AVSystem LwM2M backend for mobile connected devices with options to perform firmware upgrade also locally though BLE interface. Let’s take an example product like Thingy91 from Nordic Semiconductor, which contains the nRF9160 processor with mobile connectivity capabilities and an M33 dual-core processor, as well a nRF52811 BLE capable processor with a single M4 core. The following remote upgrade paths are possible:
- Upgrade nRF9160 from the cloud
- Upgrade part of nRF9160 from the cloud
- Upgrade nRF52840 from the cloud via nRF9160
- Upgrade nRF52840 via BLE
- Upgrade nRF9160 via BLE via nRF52840
IRNAS and AVSystem have been working together to introduce a working example solution for Zephyr RTOS and the LwM2M communication protocol, supporting such multiprocessor upgrades and DFU methods. Multi-processor architectures of products are increasingly common in connected products which may contain multiple highly optimized purpose-built modules; however, such an architecture disproportionately increases the complexity of upgrading remotely. The following example of implementing it on hardware, firmware and cloud levels gives an example on how to tackle this challenge.
Onboard a product, there may be both nRF9160 and nRF52811 and SPI external flash hardware components. A shared SPI flash is placed on a bus connected to both processors, such that each of them can access it directly and boot from this eternal flash, as well as update the image in the external flash slot for the other processor.
To make this work, an implementation of SPI coordination between processors with a GPIO pin is required, as well as preferably an UART link to coordinate the actions of the two processors. Special care is to be taken in low-power scenarios where the SPI bus must be correctly put in low-power on both processors.
Using Zephyr RTOS, we are implementing the DFU at the application layer, such that low-level drivers for SPI and similar protocols remain untouched, but we implement the logic at the flash driver level. See IRNAS flash driver example with this functionality here – https://github.com/IRNAS/zephyr-spi-flash-en25-driver. The key aspect here is that SPI flash is shared on the same SPI lines between multiple processors and as such bus access must be negotiated. This is done such that one processor can insert the DFU image for the other processor into flash.
To achieve reliable operation, the following key components must be in place:
- Hardware interface between the two or more processors must include:
- A communication bus (GPIO, UART or SPI or similar) to indicate from one processor to the other that the DFU image is available.
- SPI bus shared between the two or more processors and a single flash. Other SPI peripherals should be on a separate bus.
- GPIO line to indicate SPI bus lock, such that the other processor knows the bus is in use.
- Flash memory driver with coordination logic included which performs the following functions:
- Before a set of SPI transactions, check if the SPI bus is free and assert the lock via GPIO to it.
- Perform the memory write transactions to the flash memory.
- Release the lock via GPIO line.
- Application logic for downloading firmware upgrades with the following logic:
- Download the DFU image from the cloud split into separate chunks, AVSYSTEM implementation of this via LwM2M is packets of about 500b or alternatively HTTP range requests can be used.
- Write each chunk into the external flash memory using the access mechanism described above.
- Once all chunks are written, the download process is completed, LwM2M will implement the reliability of the download.
- The communication bus is used to indicate to the other processor(s) that a DFU is awaiting them in the external flash.
- Application logic for applying the firmware upgrade:
- Communicate to the other processor that DFU image is available.
- Let the processor reboot and perform the DFU procedure.
- Wait for the feedback if it was successful.
Advanced firmware upgrade use cases: the need for updating all components
Why is updating of all components needed? Let’s bring up two possible scenarios which were defined by AVSystem to develop two key features for multi-component firmware upgrade through the LwM2M protocol.
Let’s take a look at a device that has multiple independent components, each with its own firmware. For example, in the nRF91 series devices, we have an ARM microcontroller and an LTE radio module in the same package. Till today we can update only the microcontroller while the LTE modem firmware is developed and updated only by Nordic Semiconductor. The end device vendor manages the code on the ARM core with a completely independent release cycle. This situation can cause complications with late updates and can disrupt the components’ lifetimes.
Updating only LwM2M Client application
In the first scenario defined by AVSystem, we can update not only the microcontroller but also the radio module and we would need an advanced single device FOTA feature to update only a device component. AVSystem is on the way to provide such a feature soon. With it, developers could upgrade the firmware on the component level that couldn’t have been upgraded before. As a result, all components are up to date and devices get longer lifetimes and better stability thanks to better resource management.
All components firmware upgrade
We may also want to update only specific components of the microcontroller. It’s worth noting that modern MCU firmware is already composed of multiple separate components. The typical use case is a secure bootloader, secure firmware (e.g., running in an ARM TrustZone), and a main non-secure application. However, it may also be desirable to update only a single component (e.g., the main non-secure application).
If we only update this element, the network bandwidth can be saved, as code for the unchanged components is not transmitted. It could result also in a shorter time of update, and less power consumption needed to process it. Based on our knowledge, AVSystem is already working on such a solution to provide it in the near future.