SW upgrade - The unavoidable process in embedded system
Tell us about your product and we'll give you right SW upgrade method for it!.
Whichever embedded product you are having, upgrading SW on that is unavoidable. This upgrade fulfills both the producer and consumer of that product by doing followings
Running latest version of SW.
Getting rid of bugs in current running SW
Making use of new/reserved HW features in product
Define your product
Before thinking about SW upgrade method, first describe your product features, capabilities
Hardware features available for user intervention : Headless or Multilple Heads (i.e Displays), Audio, KeyBoard and Mouse interface
Media/Connectivity available for upgrade: USB host, Serial Port, Ethernet, WiFi
Storage size and Size of boot binaries
Embedded system Boot binaries
Following are list of common boot binaries present in embedded system
Bootloader - Not an upgradeable one ?
You may have this question "What? Bootloader can't be upgraded?". The answer is "No. it can be upgraded". But our recommendation is to not
upgrade it.
Always keep your basic bootloader very simple and small. There should be no reason to update that once you release the product to market.
Because bootloader is the first SW running in your product when it s powered on. If the upgraded bootloader is a false one (or malfunctioning),
then your product will become a brick. There are the some ways to overcome this. One is split your bootloader into two binaries (for example MLO and u-boot.bin) and keep the first one fixed (i.e non-upgradeable) and second one upgradeable.
Define Thumb rules for SW upgrade
It is always good to define output of a process by setting rules to that. Following are my thumb rules for SW upgrade.
Rule 1: It should be an atomic one. Basically by atomic I mean, either you update to the new one or stay where you were before you started the
update. You should NOT GO INTO an unknown state
Rule 2: SW upgrade should not affect the functionality of the product. Worst case, It has to intimate the user that "system is not accessible till
completion of SW upgrade"
Rule 3: When SW is upgraded and functionality is not met, it has to rollback to previous SW
Rule 4: Whether the SW upgrade is success or not, it has to log the details in the product
SW upgrade Categories and Types
There are N number of methods for SW upgrade. Here I am listing those in following categories
User Intervention
Storage device Size for boot binaries
Media/Connectivity options available on the product
Boot binaries upgradeable
Types of SW upgrade mode in terms of user intervention
Manual upgrade
Auto upgrade
Types of SW upgrade mode in terms of storage size
Single Copy
Fail-safe mode
Dual Copy mode
Types of SW upgrade mode in terms of media/connectivity options available in product
Over The Air (OTA) mode
non-OTA (i.e non network connection) mode
Types of SW upgrade mode in terms of binaries
Full (i.e all binaries) upgrade
Part (i.e selected binaries) upgrade
Following table gives you the overall picture of sw upgrade methods with its risks and limitations. Advantage of each sw upgrade method can be
droved with these two (risk and limitation) inputs.
Sl.No
Criteria
Mode
Risk
Limitation
Suitable for
1
User
Interaction
Manual
Unable to do SW upgrade when product in
human non-accessible area
Human resource is involved
Cost for upgrading matters when human
resource needs to travel for this
number of products is
in small count (1-100)
2
Auto
number of products is
in large count(>100)
3
Storage Size
and size of
boot binaries
Single
Copy
When SW upgrade is interrupted or
functionality not met after upgrade,
product will become useless until it is
recovered manually
Always we have one version of SW
Rolling back to previous version can not be
done
Can't upgrade all binaries.
Very small amount of
storage space for boot
binaries
4
Fail-safe
When SW upgrade is interrupted or
functionality not met after upgrade, product
will become useless until it is recovered itself
by doing SW upgrade again
Rolling back to previous version can not be
done.
When storage size is
more than but not
double the amount of
boot binaries.
5
Dual
Copy
At a time, we can have two versions of SW
only
When storage size is double the amount of boot binaries.
6
media/connectivity options available in product
Over
The Air
(OTA)
network devices
7
non-OTA
non network devices
8
Binaries
Full
upgrade
Entire binaries has to be upgraded always
SW upgrading takes more time
Preparing upgrade image and transferring
takes more time
Very small
amount of storage
space for boot
binaries
Any binary
upgrade or all
binary upgrade
requirement.
9
Part
upgrade
Only specific binaries can be upgraded
When storage size is
more than but not
double the amount of
boot binaries.
SW upgrade method selection flow
Conclusion
Now you have the basic details of SW upgrade in Embedded System. In older days , product owners used to choose either Fail-Safe mode or
Single Copy mode to upgrade full/part binaries due to storage size (NOR/NAND flash) limitation. Its the right time to choose the right upgrade
method instead of just blindly following the old methods.
Wait for next article to have more details on SW upgrade
We use cookies to ensure that we give you the best experience on our website. You can change your cookie settings at any time but our site requires cookies to function properly.
You may not be able to access content or other services correctly without cookies. Know more
We use cookies to ensure that we give you the best experience on our website.
Mr. Thomas Yoon
+82-10-5380-0313
Articles
Employee Login
