1. Background

There is no perfect software; due to design flaws and business requirement updates, software is constantly being upgraded and improved. This article focuses on how to replace the currently running old software with new software, especially for electronic products where Over-the-Air (OTA) upgrades are constrained by hardware resources, necessitating different solutions for software upgrades.

2. OTA Upgrade Process

The online upgrade process can be simplified as the device running old software while obtaining a new software package, executing special operations to overwrite the old software with the new software, and finally running the new software.

Depending on hardware resources and the overall system framework, different upgrade solutions need to be selected. The choice of solution should be based on practical considerations, with technical aspects being secondary.

3. OTA Upgrade Solutions

3.1 Full Package Upgrade

Taking the STM8 microcontroller upgrade as an example, the minimum system operation flow of the microcontroller is as follows:

To incorporate the online upgrade function, the main application program needs to be split, similar to having two sets of programs running within the device. The standard terminology is bootload + app, where the bootload remains unchanged and is responsible for receiving the new software package and overwriting the app area.

Hardware Limitations	Solutions
The microcontroller itself does not have network connectivity and can only download new software packages from a remote server using an external network module, then transfer it to the microcontroller via serial port.	The external host downloads the new software package and notifies the microcontroller to enter upgrade mode.
The internal RAM of the microcontroller is small, unable to perform copy operations or cache large amounts of data; the internal EEPROM is small, unable to store the entire new software package.	New software can only be received in segments during the Bootload period and immediately written to flash.

The overall solution is illustrated in the figure below:

Challenges and Risks:

1) When the app on the microcontroller receives an upgrade request, it needs to restart and enter bootload. For devices where the microcontroller is the main controller, it is necessary to ensure that the network module remains powered during the microcontroller’s reboot. Therefore, to enter bootload due to the upgrade, the power supply to the network module must be restored immediately, and hardware support may be needed if necessary.

2) Due to the limited RAM and ROM of the microcontroller, new software packages are received in segments and written directly to flash. Therefore, it is crucial to ensure that the data packets are not erroneous, lost, or need retransmission at the application layer protocol level. Currently, the Ymodem protocol is predominantly used. The upgrade package needs to be converted into a bin file, which is then written to the starting address of the app after being received by the microcontroller.

3) The process of writing new software received in segments to flash takes more than 10 seconds. If power is lost during this period, the app software of the microcontroller may become corrupted. The microcontroller must have a timeout mechanism to restart, reinitiate the upgrade, and actively request the network module to retransmit the new software package.

4) Generally, PC software does not need to consider memory and storage space and also uses full package upgrades, saving two files simultaneously. For example, when app.exe is running, it downloads a new app_new.exe. After verifying the download, app.exe self-destructs and deletes itself, then renames app_new.exe to app.exe and starts it.

3.2 Differential Upgrade

The framework for differential upgrade software is similar to that of full package upgrades, with the distinction being in the method of providing the new software package.

Microcontroller software generally does not exceed 50KB, while software for complex microprocessors is usually larger. However, with larger RAM, downloading the entire new software package takes longer and wastes bandwidth. Therefore, based on the differences between the old and new software versions, differential files can be sent to the device, which computes and restores the new software package for the upgrade.

Challenges and Risks:

1) The creation and restoration algorithm verification for the differential package must consider RAM when restoring the new software package in bootload. The differential package is generated in blocks, and restoration is also performed in blocks. Before writing each new software block, the old block must be backed up to prevent failure to restore due to unexpected power loss.

If an exception occurs, rebooting still enters bootload, checking which block has been restored last, and continuing with the subsequent operations. Some may also compress files to further reduce the size of the differential package, decompressing before restoration.

2) During the upgrade, it is essential to ensure that the generated differential package is based on the current version running on the device. For example, if the device is running V01, but the provided differential package is based on V02 to V03, it will cause exceptions. Alternatively, special version characters can be preset in the file, allowing differential restoration upgrades only when versions match. Full packages do not have this drawback, as long as bootload is normal, any app software version can be upgraded to another.

3.3 Dynamic Loading

Dynamic loading is common in PC software, where multiple executable files share a DLL library file, resulting in smaller executable files. However, the downside is that to ensure the executable runs correctly, the DLL files must be stored in specified paths.

For embedded platforms, dynamic loading can be understood as maintaining a stable underlying framework while modifying or replacing different upper-layer business logic to achieve different effects. To ensure the calling relationship between the underlying and upper layers, certain interface addresses must be fixed, which is primarily achieved through linking.

The steps for embedded software from source code to downloadable image files for devices are as follows:

Dynamic loading occurs at the linking stage, where upper-layer code objects are compiled into dynamically loadable AXF files instead of directly merging with other object files into executable files. This is mainly achieved by using armlink to configure -entry to specify the initial entry point of the image file or using the #pragma arm section code keyword in the code to ensure that the dynamic upper layer has a fixed entry address. All lower-level interface function pointers called by the upper layer are assigned empty instructions during the compilation stage to ensure compilation, and later point to the actual addresses of the lower layer.

This action takes place during system startup, loading from flash to memory, where the relative addresses of all interfaces within the file remain unchanged, maintaining an overall offset. This way, the software can still calculate and obtain the entry address of the dynamic image file. When loaded into the memory area, it must be ensured that this area is not occupied; otherwise, memory overwrite will definitely lead to exceptions.

After the lower layer starts, only the entry function of the dynamic loading file can be found, but the actual interaction interfaces between the lower and upper layers are certainly more than one, and the upper layer will inevitably call lower-level interfaces. This requires implementing address mapping between the upper and lower layers within the first function body with a clear address. There are two solutions: one is to assign function pointers, and the other is to search for pointers based on strings. The lower layer needs to provide the upper layer with the interface function pointer table for the interfaces called by the lower layer, assigning values to the upper layer function pointers in a fixed order; or the lower layer only provides the upper layer with one function, but within that function body, it retrieves function pointers based on strings. This way, the upper layer can call the fixed lower layer interfaces in advance.

The interfaces provided by the upper layer to the lower layer are also fixed function pointers, connected using the above methods. The core of interface mapping is that there is a function address in the dynamic loading block specified during linking, where the mapping between upper and lower layer functions is implemented. In addition to functions, global variables are also passed using pointers in the same manner.

Challenges and Risks:

1) The first two methods using bootload + app are relatively conventional solutions, where essentially one chip runs two sets of software that do not interfere with each other. In contrast, dynamic loading has fixed interfaces between the upper and lower layers, and interactions outside of these interfaces cannot be used.

2) Dynamic loading has high requirements for linking and ARM lower layers, and its application in upgrade scenarios is limited due to restrictions on software development interfaces. However, dynamic loading achieves isolation between upper and lower layers, avoids code calling confusion, and provides a foundation for cross-platform and multi-language development.

4. Conclusion

Online upgrades aim to resolve after-sales issues at a lower cost without product recalls; upgrades are intended to solve problems, but once they fail, it may lead to devices becoming inoperable. Preliminary testing should simulate upgrade anomalies using different devices, such as forced power outages or software package exceptions, and devices must have self-recovery mechanisms.

END

Source: Embedded Systems

Copyright belongs to the original author. If there is any infringement, please contact for deletion.

▍Recommended Reading

Example of Layered Isolation in Embedded Software

My First Driver Program Written on ARM Board

Why Are Embedded Salaries Much Lower Than Pure Software Salaries?

→ Follow to avoid getting lost ←