Introduction

When it comes to IoT device management, over-the-air (OTA) firmware updates play a key role.

OTA enables product manufacturers to remotely update connected devices with bug fixes, feature enhancements and security patches.

If you are evaluating one of our EFM32 32-bit MCUs such as the one onboard the Giant Gecko GG11 Starter Kit (SLSTK3701A) and want to learn a simple way to enable OTA firmware updates then this blog will get you started by presenting the example illustrated in the following diagram:

 

• Figure 1-(1): The embedded application acts as an HTTP-client and will connect to your web server to send a GET request to download a firmware update file (myupgrade.gbl). 
• Figure 1-(2): Your server responds with the firmware update file (myupgrade.gbl)
• Figure 1-(3): Once the file myupgrade.gbl is downloaded, the embedded application will store it by using the bootloader interface API to reprogram the bootloader storage area.
• Figure 1-(4): The embedded application will use the bootloader interface API to validate the firmware update image and upgrade the current application.

There are several criteria for the firmware update image to be flashed:

• The file myupgrade.gbl needs to be valid. This is checked by the embedded application using the bootloader interface API. 
• The embedded application checks the version of the firmware update image stored in myupgrade.gbl. If the version of the embedded application is the same or older than the running application, the image file will not be flashed.

The bootloader storage area will be erased, and the embedded application will try to establish a new HTTP/HTTPS connection, if:

• The loaded file is not a valid .gbl image.
• The version of the image stored is the same or older than the running version.
• Anything goes wrong with the HTTP/HTTPS protocol.

 

Hardware Requirements

• EFM32 Giant Gecko GG11 Starter Kit SLSTK3701A
• Web Server to host the firmware update file

 

Software Requirements

• Simplicity Studio
• 32-bit MCU SDK
• Micrium OS Kernel
• Micrium OS Network

 

Getting Started

1. Order an EFM32 Giant Gecko GG11 Starter Kit SLSTK3701A from our website

 

2. Install Simplicity Studio

• Download and Install the latest version of Simplicity Studio from our website at: http://www.silabs.com/simplicity-studio
• Download the software and follow the installation instructions.
• When asked to sign-in, enter your Silicon Labs username and password. Sign up for a new account if you don’t already have one. This is required to gain access to all of the software components.
• After signing in, register your kit with Simplicity Studio. If the kit is not registered, Simplicity Studio will only enable access to the Micrium Kernel; however, if the kit is registered, Simplicity Studio will enable access to all the other applicable Micrium components as well. The license number is on the box of the kit.

 

3. Connect the board as shown in the image below:

 

4. Open Simplicity Studio, from the Launcher perspective, select the example named SLSTK3701A_micriumos_httpcloader as shown below:

 

5. Open the file httpclient.c located in the /src folder in the Project Explorer and enter the full URL where you plan to host the firmware upgrade image:

#define  FULL_URL   "http://mywebserver.com/myupgrade.gbl"

 

If your webserver is secured (i.e. https) then this demo includes mbedTLS. Simply make sure that the certificate required by your website is defined in SSL_ROOT_CA[] in the file ssl_certificates.c located in the /src folder of the Project Explorer.

You may also have to tweak the number of bits and bytes that match your website's certificates by setting the proper sizes in MBEDTLS_ECP_MAX_BITS and MBEDTLS_MPI_MAX_SIZE in the configuration file config-ssl-
httpcloader.h located in C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.5\app\mcu_example\SLSTK3701A_EFM32GG11\micriumos_httpcloader\config-ssl-httpcloader.h

#define MBEDTLS_MPI_MAX_SIZE   256
#define MBEDTLS_ECP_MAX_BITS   384

 

6. Open the file application_properties.c in the /src folder of the Project Explorer and set the version number of the embedded application to 2 to simulate a firmware upgrade:

#define APP_PROPERTIES_VERSION 2

 

7. Build the project

 

8. Generate the firmware upgrade file myupgrade.gbl by opening the utility Simplicity Commander located at C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\commander and by providing the path to your binary file .s37 to a command line similar to this:

commander.exe gbl create myupgrade.gbl --app "C:\Users\[YourUsername]\SimplicityStudio\v4_workspace\SLSTK3701A_micriumos_httpcloader\GNU ARM v7.2.1 - Debug\SLSTK3701A_micriumos_httpcloader.s37"

 

 

9. Upload the file myupgrade.gbl to your web server

 

10. Open the file application_properties.c in the /src folder of the Project Explorer and set the version number of the embedded application back to 1:

#define APP_PROPERTIES_VERSION 1

 

11. Build the project again

 

12. Connect the starter kit as previously shown in Figure 2

 

13. Open Device Manager in Windows to find out the COM Port number of the USB device listed as J-Link CDC UART Port

 

14. Open a Serial Console application such as PuTTY to see the debug messages during run time

 

15. Select the item J-Link Silicon Labs from the list of Debug Adapters, right-click to open the context menu and select the option Upload Application... as shown below:

 

16. In the field Application Image Path, select the file SLSTK3701A_micriumos_httpcloader.s37 that you just built by browsing to the workspace folder where you have your project, a path similar to the following:

C:\Users\[YourUsername]\SimplicityStudio\v4_workspace\SLSTK3701A_micriumos_httpcloader\GNU ARM v7.2.1 - Debug\SLSTK3701A_micriumos_httpcloader.s37

 

Tick the checkbox to Upload a Bootloader image and select the bootloader that comes with the example by browsing to the file bootloader-storage-internal-single-combined.s37 in a path similar to this:

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.5\app\mcu_example\SLSTK3701A_EFM32GG11\micriumos_httpcloader\bootloader-storage-internal-single-combined.s37

 

 

17. Press the button Ok to flash both images. The bootloader image will be flashed in a reserved area of Flash and from this point forward you can simply Launch a Debug Session from Simplicity Studio to program the device with a different application image as the bootloader image will be stored in a reserved area of Flash that won't be deleted unless you overwrite it with this tool or from the command line with Simplicity Commander.

 

18. Watch the serial terminal as the embedded application starts the Ethernet interface, connects to your website to download the file myupgrade.gbl and reboots on the new upgraded embedded application. 

 

 

Further Reading

The firmware update situation described in this example assume no authentication and no encryption of the firmware update file. However, these features along with secure boot are supported by our system but it is beyond the scope of this blog.

To sign and encrypt a firmware update file, you can use Simplicity Commander as follows:

commander.exe gbl create --app --bootloader --metadata --compress --encrypt --sign --force

 

For more information on how to use Simplicity Commander see the section GBL Commands on Page 34 of the following document: 

• UG162: Simplicity Commander Reference Guide: 

https://www.silabs.com/documents/public/user-guides/ug162-simplicity-commander-reference-guide.pdf

 

For more information on the Gecko Bootloader see the following documents: 

• UG266: Gecko Bootloader User's Guide:

https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf

• UG103.6: Bootloader Fundamentals:

https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf

 

 

 

We recently had the opportunity to sit down with the CTO and co-founder of Notion, Ryan Margoles to talk about the release of their Gen 3 sensors and how the IoT will impact homeowners in ways that go beyond just convenience. 

 

Tell us about the history of Notion. What was the impetus for starting the company and what were the immediate challenges?

The idea for Notion was literally sparked by a sounding alarm in the middle of the night. My wife and I had just adopted a puppy and our carbon monoxide alarm went off at 2am; it was a pretty jarring experience. We jumped out of bed and opened all the windows and exited the house. Fortunately, it was only the furnace fizzling out. The next day, I called my business partner and childhood friend, Brett, with the idea to make a Wi-Fi connected smoke/carbon monoxide alarm. We set out to learn more about the value proposition of a smart smoke alarm, and how we could make it valuable for customers. We learned quickly that people loved the use case, but were not used to buying smoke or CO2 alarms; they are usually already installed in the apartment or in the home you buy. The product evolved and coalesced into a concept of a single sensor that could do multiple things: listen for smoke/CO2 alarms, detect movement, doors and windows opening/closing, freezing temperature, and leak detection. The competition offered several single-function sensors: a door sensor, a temperature sensor or a leak sensor. In our opinion, this was a barrier to entry for people who aren’t as tech savvy. We knew we had found the right idea to pursue.

 

What is your background?

I have a mechanical engineering degree from the University of Colorado. My background is in product development, manufacturing and big data. I spent most of my early career with Titleist and Callaway developing smart golf clubs.

 

When you set out to do this, size and battery power were obvious considerations. What were some other known design challenges?

There were three challenges on the onset: 1.) Battery usage: Battery power and replacing batteries every three months is tough for a customer to get used to; it’s a hassle. Our Gen 1 kit had a coin-cell battery that was difficult to swap out. We learned over time that just two AAA alkaline batteries were important since they are readily available and easy to change out. 2.) Ingress protection: Devices that are placed outside, in really cold environments or used for water leaks need to limit the amount of water that gets into the devices. 3.) Simple user

experience: it was a challenge to design a simple user setup. One of the areas of opportunity was the pairing process. With most smart devices, you have to go through a pairing process. We identified that as a pain point for users so we developed our own protocol for pairing devices. Our goal is ease-of use. Every device is the same. It detects all five “senses” and device tasks are 100% configurable in the Notion smartphone app.

 

How did Silicon Labs become part of Notion?

First and foremost, the account management team at Silicon Labs is easy to work with. We were able to get the answers we needed to make important decisions and the team availed themselves to all-levels of the Notion organization, from executives to hardware engineers. Second, the Gecko platform allows us to configure specific protocols and free our team to focus on other things. Previously, the Notion team developed everything – from OTA update mechanisms to the security protocols. It was very labor intensive. Silicon Labs helped alleviate much of this burden. Third, the Silicon Labs team spent the time building rapport and working with us on a pricing model that worked for our start-up.

 

What’s been the market’s response to Notion?

Overwhelmingly positive. It’s the best multi-functional sensor on the market with its simple 15-minutes-or-less set up, increased range, and long battery life. Our channel strategy includes not only B2C, but also B2B; we are partnered with several of the top insurance companies in the U.S. Similar to car sensors that help lower your insurance premiums for good driving, we’ve pursued a similar path for home ownership. Now a homeowner or renter can augment their monthly premium by installing Notion. Additionally, we’re the first IoT company to have

a partnership with HomeAdvisor. So, if you have a water leak, we not only detect it, but we can connect you with an available plumber in your area within 30 seconds.

 

What do you see is the vision for the future of Notion, and the IoT in general?

We believe the services extension of IoT is changing what it means to have a smart home. Being a homeowner is hard and our mission is to help you take care of your home. We have a 10-year goal of making Notion a requirement to obtain property insurance -- that’s how powerful we think our product and data is. We partnered with one of our insurance partners, Hippo, to be the first fully-integrated smart insurance product on the market. Every customer who buys Hippo insurance receives a Notion starter kit for free. Once the customer sets up their

Notion system, they get an exclusive discount on their premium. We’re driving insurance to make a change while adding thoughtful services to the Notion brand to help homeowners take care of and secure their home.

 

The most successful loT products make Bluetooth and Wi-Fi connectivity easy for end customers to set up and use. The lack of time and resources in companies with limited in-house wireless design expertise can lead to slipped delivery schedules and multiple product re-designs.

There are four typical stages of the wireless development process:

1. Software/firmware development
2. Hardware design and certification
3. Mobile applications development
4. Cloud connectivity

The development process can take up to a year to complete. Let’s discuss and highlight the unique challenges presented in each development stage.

Software/Firmware Development

In the firmware development stage, developers using unprogrammed modules must become experts in Bluetooth communication or Wi-Fi protocols and vendor-specific software stacks. In traditional Bluetooth and Wi-Fi design, developers must create an embedded host + network co-processor design with a communication link that operates at a low level controlling the network co-processor. Half of the development work includes writing firmware code and the other half is spent on testing.

 

Hardware Design

Choosing the right hardware is a critical piece of wireless functionality and the integrity of system design. Using unprogrammed modules to add wireless connectivity to their products poses a variety of problems including potential delays, antenna design issues, and RF certification hurdles. FCC certification alone can cost thousands of dollars and take months of testing and validation. Good RF performance is a critical design challenge.

 

Mobile Applications Development

The mobile app development stage is often the most challenging for companies since many don’t have developers in house with mobile application experience. For this development stage, developers must become experts in both Android and iOS development, which means more APIs to understand. They often outsource to vendors who build the mobile infrastructure, perform testing, etc. which can be very time consuming and costly due to the difficulty in finding subject matter experts in both iOS and Android development.

 

Cloud Connectivity

This stage of product development is a critical one and can be challenging and prone to errors and potential launch delays that affect the success of the loT applications. Getting and maintaining reliable cloud connectivity and properly collecting data are huge concerns in loT applications today. It’s almost impossible for companies, especially small ones, to develop a cloud-connected framework/infrastructure from scratch. Developers also often have problems with unreliable links and connectivity and they might also be restricted by the MCU. Having reliable connectivity links is a critical piece of product longevity and customer satisfaction. Firmware updates are also an important part of product maintenance and are usually outsourced by companies. Using an integrated solution that already has the infrastructure for adding cloud connectivity can save developers months of framework development.

 

Benefits of Pre-Programmed Wireless Modules

loT developers today want robust functionality in the smallest footprint possible and they want solutions that support easy Wi-Fi and Bluetooth connectivity. Leveraging integrated modules that already include pre-programmed firmware, pre-certified RF and hardware, easy mobile app framework, and cloud connectivity, streamlines the development process and takes the guesswork out of successful connectivity.

 

Key Points to Consider

• Select a product with functional and tested system firmware that’s pre-programmed at manufacturing
• Use a model instead of designing with SoC
• Start mobile app development with a wireless interfacing library that’s been optimized for ease of use
• Connect to cloud infrastructure already in place as part of an integrated product

 

Silicon Labs Wireless Xpress products, powered by Gecko OS, and application firmware running on pre-certified Silicon Labs modules combines these product development cycle stage optimizations to provide a streamlined embedded-to-phone and embedded-to-cloud connectivity.

 

Value of Gecko OS

Gecko OS is a highly-optimized loT operations system designed specifically to power hardware platforms with secure Wi-Fi networking capability and is the best choice for resource-constrained devices. Hardware running Gecko OS provides products with a powerful and secure wireless connection to a mobile device or the cloud. The Gecko OS API is a huge benefit to loT developers because it provides a common software foundation across multiple product lines.

Gecko OS products maintain much of the wireless interface without external MCU intervention, only exposing critical variables and commands for external MCU control.

To learn more about how Wireless Xpress can help IoT developers deliver ease-of-use to end customers, read the full whitepaper: