Include a remote update boot loader: 5 reasons why
In an article I wrote for EDN's sister site Design News -- 5 Tips for Remotely Updating an Embedded System -- I offered a few recommendations on how embedded system designers might go about designing in remote updating ability. But that begs the question why they should bother. After all, isn’t it just added cost and time to develop and validate yet another piece of software?
There are five key reasons why a developer should consider including a boot loader to add remote update ability to their next design.
Reason #1 – To fix bugs in the field
One of the greatest reasons to remotely update an embedded system using a boot loader is to fix bugs once a product has been deployed. Development teams work extremely hard to ensure that shipped products have squashed every bug in sight. But developers are only human and there are bound to be a few errors that slip through. Experience has taught repeatedly that bugs are most likely to show their faces for demos in front of bosses or clients and, of course, during the initial deployment stage of production. A boot loader provides an easy method for a development team to remove such bugs with no fuss.
Reason #2 – To allow access to programming ports
During product development the JTAG, SWD, or other microcontroller programming and debugger ports are readily accessible. In the final product, though, the programming port is not always easily accessible and, for security reasons, it shouldn’t be. But if field software updates are needed, opening the product to gain access can be difficult or time consuming, especially if the circuit board is encased in a potting material. The use of a boot loader that is accessible through a communications port bypasses any difficulty in gaining physical access to the programming port and instead provides a method to more easily update the firmware.
Reason #3 – To avoid the need for specialized hardware tools
Even if the programming port were reachable, programming tools wouldn’t necessarily be readily accessible to technicians. Microcontroller programming tools are rarely inexpensive. A typical production programming tool can easily cost $300 to $1000. Most companies aren’t willing to invest in outfitting their field technicians with the tools that would be necessary to update firmware locally.
Reason #4 – To reduce maintenance costs
Maintenance costs can include the hardware tools mentioned in Reason #3 but sending technicians on-site to update firmware can also be a costly endeavor. A deployment of thousands or tens of thousands of devices in the field makes it impractical to outfit an army of technicians to run around updating products. Setting up an embedded system to be accessible remotely, instead, is a great way to reduce manpower required to update a product's software. Rather than sending people on-site, the latest firmware can be uploaded to a server and, when the device deems that it is ready, its firmware can be automatically updated.
Reason #5 – Upgrade product features
One the most important reasons to update firmware remotely is to upgrade product features. Society is driven by technology and consumers expect ever-more enhancements and features. Many companies can thus benefit from making periodic firmware updates. Start-ups especially need to leverage this concept. It allows them to initially focus on their core differentiating product features, launch into the market to generate a revenue stream, and then remotely start to update their features and capabilities as competition expands customer expectations.
Remotely updating firmware is a good and standard practice for embedded systems if it is done properly. The five reasons in this article are just a few examples of why designers should consider using a boot loader in their product. Once the decision to include one is made, though, it is critical that the boot loader be designed properly. Security, fail-safes, and robust operation are essential to prevent system from being comprised or bricked in the field.
Jacob Beningo is a Certified Software Development Professional (CSDP) whose expertise is in embedded software. He works with companies to decrease costs and time to market while maintaining a quality and robust product. Feel free to contact him at firstname.lastname@example.org, at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter here.