Return to Blog Home

Dodging the Brick: How Helium Safely Updates Devices In the Field

brick | verb
cause an electronic device to become unable to function, typically on a permanent basis.
“installing an unofficial OS voids the warranty and may brick the phone”

Dodging the Brick

Helium allows you as the developer to program the behavior of your sensors, from basic alterations to data sample and transmission rates to more advanced logic running on the end node, such as local data analysis or machine learning at the edge. One of the more thorny challenges with crafting user-facing embedded systems is how to apply software updates securely and safely. This becomes even more critical when the devices are airgapped from the access point, programmable with the understanding that configuration changes can occur as frequently as the user wants, and battery-powered so that there are sleep cycles – all characteristics of Helium devices.

In the field, Helium-based sensors can be far away from human hands, in a completely unattended automated facility, or literally in a field/desert/ocean/etc. They will always be connected over a wireless link to the Helium Element Access Point.

For us, brick dodging isn’t mere sport, it’s a way of life. The Helium Atom Wireless Application Module uses a few strategies to prevent device failures as a result of deployed user code.

The Lua Programming Language

The Helium Atom Wireless Application Module runs a slightly modified Lua interpreter responsible for executing user-defined code. Whether you’re modifying sensor sample and transmit rates or creating programs to run on the Atom, all of this is expressed in Lua scripts delivered from the Helium Cloud to your device. There are several reasons Helium uses Lua, but the most pertinent one for this post is that it helps sandbox user code from the rest of the system. With Lua, we can architect a system that isolates the user’s code from the core components that control power, radios, storage, and scheduling. The result: when a user’s Lua script crashes, it cannot cause the rest of the system to fail.

Limiting Execution Time: The Script Hangman

The Helium Atom expects that user scripts give the whole system a chance to go into low power mode in order to conserve battery power. The system only attempts to do this when there’s no work left to be done by any task in the system. In other words, if anything having to do with storage, radios, logging, or the user’s Lua script is busy, the system will not go into sleep. The one thing that Helium doesn’t directly control is the user’s Lua script. For this reason, the Lua interpreter is given a limited number of instructions it can run without giving the rest of the system a chance to go to sleep. If the script exceeds this instruction limit, it is terminated and restarted.

Memory Partitioning: The Lua Quarantine

In order to prevent the user’s Lua code from corrupting memory belonging to the core system, the heap used for the Lua interpreter is entirely separate from the heap used by the main system. This prevents a user script from consuming memory that the main system needs. When a script runs out of memory in its dedicated heap, only the script fails, leaving the core system untouched.

Script Storage During Device Updates

The user’s Lua script is stored and loaded from flash memory. A common practice in development will be updating the script stored in flash and reloading the interpreter from it. There is a period of time where loading this new script could be interrupted due to loss of power or a long interruption in the wireless link; in order to prevent this from corrupting the existing user script, this new script is copied into a spare memory region. When fully loaded, this new upload is made the current script and it becomes the running script.

Conclusion

Dodging bricks takes practice, experience and more than your fair share of contusions. Embedded systems engineers have long faced off against the risk of bricking devices, with varying degrees of success in industry. Since our products are designed to be easy to use for developers as well as end customers, we take the risk of bricking very seriously and will continue to deploy checks to prevent it from happening in order to allow developers to ship bulletproof products based on Helium.

Want to Learn More About Helium? Talk to us!

  • If you’re interested in finding out more about Helium, visit www.helium.com for an overview of our products.

  • Development kits and all necessary hardware to start building connected products can be purchased at store.helium.com.

  • Join our Slack community at chat.helium.com and speak directly to the Helium team as well as other Helium developers.

  • If you’d like to discuss an upcoming project with us, let us know and we’ll get in touch soon.