Understanding the Terms Development and Production

In Gecko OS, the terms development and production are used often and across different topics with different meanings. The two primary use cases for these terms are when referring to Development vs Production Device Credentials and Development vs Production DMS Flow . This article explains the difference in detail of these two use cases.

Development vs Production Device Credentials

To communicate with the Zentri Device Management Service (DMS) , a device needs to establish a secure, authenticated channel with the server. That is done using credentials that are programmed into the device. The device's security credentials reside in a specific memory section of the device’s flash. This memory section will persist through Device Firmware Update (DFU). Production credentials are programmed into the device during manufacturing and may be updated during DFU if needed. These credentials can be replaced with development credentials as explained below. Without valid credentials (either production or development), a device cannot communicate with the DMS.

Production Credentials

Silicon Labs programs DMS credentials into the device during the manufacturing process. These are called production credentials. Once programmed, the manufacturing process will lock the device. Locking the device refers to “debug interface locking” which disables access to the internal flash and the Cortex-M4 core from the debug interface.

Unlocking the debug interface will automatically erase the DMS credentials along with the rest of the internal flash. This guarantees that the production credentials cannot be exposed by unlocking the debug interface. Once a device has its debug interface unlocked it will live forever as a development device.

Development Credentials

With the production credentials deleted (and never to be recovered), the device must be given new credentials to work in a development environment. During the device setup step of development , the device is given development DMS credentials that expire after 30 days. This allows the device to communicate normally with DMS during development. Once the credentials expire, the device will no longer be able to communicate with DMS (any update or query will fail with error 403/400). The development credentials can be re-renewed by performing device setup again.

In a final product, you should never ship non-locked devices to end users. Always make sure that devices shipped to end users are locked and programmed with production credentials. In other words, once the device is used for development once, never use it in a consumer product. Keep it for development and testing.

Devices come locked and pre-programmed with production credentials. To keep those during your production process, you should only program your devices via one of the methods below:

Development vs Production DMS Flow

The second context in which the terms production and development are used is the DMS production flow. In this case, the terms are used to distinguish the differences between development and production product types on DMS. Note that this context is separate and independent of the device credentials explained earlier.

Development Product

This is the product type used during the development cycle. When a project is created in Gecko OS Studio, a development product is automatically created on DMS. You can view your development products on the DMS as discussed here . The product code always starts with your user account code (6-character length code, starting with 0). For example, 0ST3XD-AZURE_DEMO . Once you use the Gecko OS SDK/Studio to release a bundle, this linked product is used. More about bundle release (application deployment) is described in this tutorial .

You can also create a development product directly using the DMS user interface by either adding a new bundle or copying it from another product you have access to. This is explained in this tutorial .

To update your device’s firmware with a development product bundle, first claim the device to your account, then activate it to the product using the product code. Once activated, you can pick any bundle published on this product. The latest released bundle is obtained via the dfu_update command. You can choose a different bundle if you specify the bundle number using the -b argument. More details on how to update a device with a development product can be found in the Application SDK tutorial .

If you have access to many products, you can easily move across different products by activating the device using the product code, then issuing the dfu_update command.

Note that a DMS user account is limited to a number of devices that can be activated to development products. As explained earlier, this phase is only recommended for development and testing activities.

Production Product

After development and testing of the application is complete, the next step is to "productize" it. That involves creating a production DMS product and moving the bundle across to this new product. A production product is not linked to a DMS user, but to a DMS customer account. It is not prefixed with a user code but with a customer code . A customer code is a 6-character string that is chosen while creating a DMS customer account. An example of a production product is SILABS-AZURE_DEMO. More about creating a customer account and taking a product to production is explained here .

The main differences introduced for production products are:

  • A production product can have an unlimited number of devices activated to it.
  • You cannot use the product code to activate a device to the product. Instead, you will have to use activation tokens . Remember that a token is a secret key, and anyone that knows your activation token can use it to activate any device to your product and obtain a copy of your firmware binaries.
  • You do not claim a device before activating it to a production product. The reason here is that a device in the field is not “owned” by a user account anymore but is instead associated to the customer account. If you have access to the customer account, you still have access to the device on DMS.
  • Devices cannot pick a random bundle to update using the -b parameter of the dfu_update command. The extra argument will be ignored, and only the latest released bundle that matches the device’s tag will be downloaded.
  • Devices activated to a production account cannot reactivate to another product from the device’s side. In other words, you can issue the command dms_activate <token> only once using the Gecko OS command API. Subsequent activation attempts will fail unless the device is reset first (explained later) from the DMS. The reason here is that production devices are distributed to end users, and you do not want a user to change the device’s standard product (if you shipped the device as a “toaster”, you do not want anyone with access to the device’s terminal to change it to a “fridge”).

As a customer account owner, you can move devices across different products under the same customer account. However this capability is from the DMS user interface only, and only the account admin can do so. The use case here is that if you wanted to upgrade the device from a “toaster” to a “toaster plus”, you can do that using the DMS user interface. You can also factory reset the device back to the platform product (SILABS-WGM160P) from the DMS user interface.

Caution: once you factory-reset the device, you will lose access to the device and it requires the terminal to activate it again. You should not perform this factory reset to a device in the field, or a device you do not have a physical access to.

The regular recommended DMS flow is:

  1. Use a development product to release your firmware.
  2. Evaluate and test the bundle on your development devices (up to 50 devices).
  3. Once everything is tested and verified, create a production product and clone the development bundle across.
  4. Always activate fleet devices to a production product (using an activation token) before shipping.