Firmware upgradability feature is so critical that it can almost kill your business if you don’t have it.
One might ask, why field firmware update is so critical for any product these days?
Some of the possible answers could be:
- Complex Embedded Products: Today, embedded systems are getting way too complex with lots and lots of integration, features, there is a need for the best user experience, high performance, etc. It is also getting difficult to judge what is the best features at the time of launching the product. Testing time is also limited which poses the need of having upgradabiliy in the future, atleast of the firmware/software.
- Bug Fixing: If you find a bug in your code when it is already deployed, how would you handle that situation. It is way too expensive to send service engineers to the field and get all the devices updated.
- User Experience Improvement: There could be another scenario where once you deploy your devices in the field, you understand the working environment or users expectation or behavior, now how do you adapt your device to improve the situation or user experience?
- Customer asks modification: If customers asks for a new features or a small tweak?
I hope with the above points you are convinced that firmware update feature is quite important for any product. Now, lets us is what if we want to implement it in our MCU based products.
Is it easy to implement firmware update feature?
I am sure you are afraid of firmware update feature implementation because you have never tried it. It seems little complex when you think about it but it is not that difficult.
Let me know if you have tried the implementation and could not complete due to complexity involved. Please contact me, I will try to help.
Some of the key challenges while implementing firmware update are as mentioned below:
- File Download: You need to download the firmware from internet or using external wired or wireless interface like USB, UART, Ethernet, WiFi, Bluetooth, etc. Need to check the integrity of the downloaded file. Need to also decrypt the file, if it is encrypted.
- Extra Memory: You need storage space, Choices are either external Non-Volatile Memory or you can have a bigger size (more than double the size of the program) Flash in your MCU.
- IAP: You need to implement in-application-programming for the MCU.
- Bootloader: You need to have a boot loader implementation which will check availability of new firmware at every boot and execute the reflashing procedure. One need to also think about mechanism to update the boot-loader itself in rare cases.
- FailSafe Mechanism:
- Power should not go while the reflashing of the firmware is in progress.
- Keeping a backup of the old firmware so as to rollback in case new firmware has some issues should be implemented.
Although there are a couple of challenges associated with the firmware update implementation, it is not that complex that you need any special guidance or expertise. Let me try to help by providing you with basic implementation steps.
Steps to implement firmware update feature
- You need to download the firmware and check its integrity. If you have firmware encrypted, you need to also decrypt after it is downloaded.
- You must have a bootloader code that will check at every boot if there a new firmware available or not. If available, it will update the firmware using in-application programming. Otherwise, it will pass the handle to the main program execution.
- New firmware can be stored in the following:
- External memory (EEPROM, SPI Flash, SD card, etc.)
- If you are using GPRS modem, they also have space available for file storage which could be used.
- One can also have MCU with bigger flash memory like double the size of the program.
- Download the file in RAM if you are 100% sure of power availability/backup.
- The main program will check periodically on the cloud or get a trigger via an external interface for downloading the new firmware. Once downloaded and checked the integrity, will set the flag and initiate the soft restart.
- There are different ways, you can download the full firmware or can implement sector wise download and re-flashing. Both have their pros and cons. I recommend downloading complete file so that uncertainty of proper file download won’t be there.
- While firmware update is in-progress, power should not go away. One strategy could be power-off all not-required sections on the board and use a big size cap/super cap/battery backup to ensure power availability during reflash. Consider 1.5 time of re-flashing time as the back up.
- Rollback mechanism should also be created so that in case the new firmware doesn’t work for whatever reason, it should easily roll back to the old one and product becomes operational.
- Mechanism to update the boot-loader itself should not arise so think thoroughly before implementation and test it really well. If you are unsure, please do implement a mechanism to update boot-loader also.
- One can off-load in-application programming to another small external MCU which will update the firmware via UART, etc. These days many MCU provides boot-loader in ROM which provides easy UART based programming interface already implemented. In this case file will be downloaded and stored in the Memory connected to this special MCU whose purpose is to program the main MCU. This special MCU Can be programmed in such a way that it keeps the bootloader, & 2 copies of firmware one old and another new in the memory.
You should also make sure whatever way you are implementing this feature, it is quite generic and not using some very specific feature of an MCU which will only be available on one of your project’s MCU. Generic implementation can always be reused across your projects where different MCU from different vendors are used. In special cases you might want to ignore this advice.
I hope above explanation has helped you understand the basic concept of firmware update and its implementation.
Do you have a firmware update feature implemented in your product?
Let me know if you need any help. I will be happy to help.
If you have any suggestions or feedback please share it in the comments below or send me an email.
Read my other articles on Embedded System Design.
Hi, I have implemented the firmware update and it is working fine. Right now, the program and GUI images are in one binary file and I download that .bin file to update. But in future, I thought of moving the GUI images in external ROM. If that’s the case, how should I implement the update logic to update program as well as GUI images?
Thanks in advance.
That is simple, you can download updated images on external Flash as second copy and use the latest version from next boot onwards.
Are you suggesting me to download images like .jpg files after I download the .bin files. The new image download login should go in new .bin file? or If its not. Could you explain a little more?
Glad you found it useful!