Every embedded product I’ve worked on has required field update capabilities in order to deploy firmware upgrades. Unfortunately, the pressure to get a product to market can lead to bad practices like deferring non-customer-facing features, even if they are critical.
It’s important to get key product features done — and sales, marketing, and management will push hardest on their own must-haves — but having a seamless upgrade strategy in place is crucial for ensuring the long-term success of your product.
To help give you and your team the proper ammunition and avoid getting dragged into this situation, here are some common themes that cause a project to end up in this dismal situation.
Bootloaders are HARD, so don’t deprioritize!
Management always knows that this is a crucial feature, but they seldom doesn’t understand the complexities involved and the level of customization and robustness required to have this safety valve in place. After all, field updates are a fallback mechanism in the event that a crucial bug gets discovered too late, or if research and beta-testing didn’t catch that an important feature was did not hit the mark expected by customers.
No Bootloader means developers will have to update prototypes… again and again.
There are valuable, but not necessarily obvious, benefits of having a convenient update mechanism in place during the course of product development as well. In the absence of such a mechanism, I personally have spent hours with a JTAG adapter, various tools, and rigged up connectors applying updates to dozens of devices, burning valuable development time… not to mention the interruption and time it takes to get back on track, to getting the real work done.
Partitioning your resources early saves time!
Getting your bootloader in place early forces the proper partitioning of the system at an early stage, when the separation and allocation of code and resources is much easier to do. Even if you don’t get the separation completely right the first time around, you will know it earlier and will have more time to carefully address the issues. Furthermore, you are getting more road-time to test, refine, and document the procedure with the help of test technicians and system engineers.
Take the reigns and just do it!
If you have read this far, you likely have experienced many of the pitfalls I have mentioned. This is disappointingly too common of a problem, and one that occurs over and over — despite the retros, missed deadlines, and returned devices due to a flaw or lack of a solid bootloader.
Don’t let this happen to you, your teammates, and the products you develop any longer. Stand up for the early introduction of an update strategy. It is unethical to do otherwise, and doing so will result in a notable increase in your sanity, and your coworkers, and even you beta and end users.
If you have been, or are in this situation now, please share your war stories and frustrations!