If you used Gecko OS for WGM160P, you must have heard about development vs production many times. The development and production terms are used across different topics and get confusing sometimes. This article explains the difference in detail and helps to understand the different use cases for these terms.
Development vs Production Device Credentials:
To communicate with Zentri Device Management Service (DMS), a device needs to establish a secure channel with the server. That is done using the device’s credentials. The device's updatable security credentials reside in a specific memory section of the device’s flash. This memory section will persist through Device Firmware Update (DFU). The credentials are programmed during manufacturing and updated during DFU if needed. These can be also flashed and replaced with development credentials as explained below. Without valid credentials (either production or development), a device cannot communicate with DMS.
Production Credentials:
Silicon Labs programs DMS credentials into the device during the manufacturing process (hence the term production credentials). Once programmed, the process makes sure to 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 erase those credentials along with the rest of the internal flash. That guarantees devices with unlocked debug interface cannot expose the production credentials at all. In other words, the device is considered compromised once it has its debug interface unlocked. We do not know what users used it for and it will live forever as a development device.
Development Credentials:
Once a device is unlocked, the production credentials are deleted (and never recovered). Now, how to use the device if you still need to work with DMS? You need to use development credentials. During development, the device is given development DMS credentials that expire after 30 days. This is done during the device setup step of development (using Gecko OS Studio or Gecko OS SDK). The credentials are re-renewed every time the device is setup again using Gecko OS Studio. Once credentials expire, the device will not be able to communicate with DMS (any update or query will fail with error 403/400).
In the final product, never ship non-locked devices to end users. Always make sure that the device is 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:
Using factory/offline DFU via the UART interface, as described here.
Development vs Production DMS Flow:
The second context that uses production and development terms is the production flow via DMS. In this case, we are distinguishing between a development and production product on DMS. The difference is highlighted below. Note that this context has nothing to do with the device credentials explained earlier.
Development Product:
This is the default, most commonly used product type used during the development cycle. Once you create a project in Gecko OS Studio, a development product is created on DMS. 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 DMS UI and either add a new bundle or copy it from another product you have access to. This is also explained in this tutorial.
To update your device’s firmware with a development product bundle, you will need to 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. Latest released bundle is obtained via the “dfu_update” command, while you can choose a different bundle if you specify the bundle number using the -b argument.
If you have many products you have access to, you can easily move across different products via activating 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:
Once you are happy with the firmware you developed, it is the time to “productize” it. That means creating a production product and moving the bundle across. A production product is not linked to a DMS user, but to a DMS customer account. That is, it does not start with a user code but with customer code. A customer code is a 6-character length string you chose while creating a customer account. An example of a production product is SILABS-AZURE_DEMO. More about creating a customer account and linking it to your user account is explained here.
Production products can have an unlimited number of devices activated to it. The main differences introduced for production products are explained below:
You cannot use the product code anymore. You will have to use activation tokens to activate a device to production product. Also, you do not need to claim the device first. The reason here is that device is not “owned” by your user account anymore but associated to the customer account instead. If you have access to the customer account, you still have access to the device on DMS. More about activation tokens and how to obtain them is described here. 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.
Devices cannot pick a random bundle to update using the -b parameter. 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 can not reactivate to another product from the device’s side. In other words, you can issue the command “dms_activate ” only once using Gecko OS command API. Second activation will fail unless device is reset first (explained later). 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 has access to the device’s terminal to change it to a “fridge”).
As an account owner, you can move devices across different products under the same customer account. This is from the DMS UI only though, and only the account admin can do that. 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 UI. You can also factory reset the device back to the platform product (SILABS-WGM160P) from the DMS UI.
Caution: once you factory-reset the device, you will lose access to the device and it needs to use the terminal to activate it again. You should not perform this factory reset to a device in field, or a device you do not have a physical access to.
The regular recommended DMS flow is to first use a development product to release your firmware. Evaluate and test the bundle on your development device. Once everything is alright, create a production product and clone this bundle across. Always activate fleet devices to a production product (using an activation token) before shipping.
DMS & Gecko OS: Development vs Production Explained
Note: this app note below is also published on Gecko OS online docs here: https://docs.silabs.com/gecko-os/4/standard/latest/sdk/development/development-v-production
If you used Gecko OS for WGM160P, you must have heard about development vs production many times. The development and production terms are used across different topics and get confusing sometimes. This article explains the difference in detail and helps to understand the different use cases for these terms.
Development vs Production Device Credentials:
To communicate with Zentri Device Management Service (DMS), a device needs to establish a secure channel with the server. That is done using the device’s credentials. The device's updatable security credentials reside in a specific memory section of the device’s flash. This memory section will persist through Device Firmware Update (DFU). The credentials are programmed during manufacturing and updated during DFU if needed. These can be also flashed and replaced with development credentials as explained below. Without valid credentials (either production or development), a device cannot communicate with DMS.
Production Credentials:
Silicon Labs programs DMS credentials into the device during the manufacturing process (hence the term production credentials). Once programmed, the process makes sure to 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 erase those credentials along with the rest of the internal flash. That guarantees devices with unlocked debug interface cannot expose the production credentials at all. In other words, the device is considered compromised once it has its debug interface unlocked. We do not know what users used it for and it will live forever as a development device.
Development Credentials:
Once a device is unlocked, the production credentials are deleted (and never recovered). Now, how to use the device if you still need to work with DMS? You need to use development credentials. During development, the device is given development DMS credentials that expire after 30 days. This is done during the device setup step of development (using Gecko OS Studio or Gecko OS SDK). The credentials are re-renewed every time the device is setup again using Gecko OS Studio. Once credentials expire, the device will not be able to communicate with DMS (any update or query will fail with error 403/400).
In the final product, never ship non-locked devices to end users. Always make sure that the device is 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:
Over-The-Air (OTA) via the DMS, as explained here.
Using factory/offline DFU via the UART interface, as described here.
Development vs Production DMS Flow:
The second context that uses production and development terms is the production flow via DMS. In this case, we are distinguishing between a development and production product on DMS. The difference is highlighted below. Note that this context has nothing to do with the device credentials explained earlier.
Development Product:
This is the default, most commonly used product type used during the development cycle. Once you create a project in Gecko OS Studio, a development product is created on DMS. 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 DMS UI and either add a new bundle or copy it from another product you have access to. This is also explained in this tutorial.
To update your device’s firmware with a development product bundle, you will need to 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. Latest released bundle is obtained via the “dfu_update” command, while you can choose a different bundle if you specify the bundle number using the -b argument.
If you have many products you have access to, you can easily move across different products via activating 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:
Once you are happy with the firmware you developed, it is the time to “productize” it. That means creating a production product and moving the bundle across. A production product is not linked to a DMS user, but to a DMS customer account. That is, it does not start with a user code but with customer code. A customer code is a 6-character length string you chose while creating a customer account. An example of a production product is SILABS-AZURE_DEMO. More about creating a customer account and linking it to your user account is explained here.
Production products can have an unlimited number of devices activated to it. The main differences introduced for production products are explained below:
You cannot use the product code anymore. You will have to use activation tokens to activate a device to production product. Also, you do not need to claim the device first. The reason here is that device is not “owned” by your user account anymore but associated to the customer account instead. If you have access to the customer account, you still have access to the device on DMS. More about activation tokens and how to obtain them is described here. 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.
Devices cannot pick a random bundle to update using the -b parameter. 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 can not reactivate to another product from the device’s side. In other words, you can issue the command “dms_activate ” only once using Gecko OS command API. Second activation will fail unless device is reset first (explained later). 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 has access to the device’s terminal to change it to a “fridge”).
As an account owner, you can move devices across different products under the same customer account. This is from the DMS UI only though, and only the account admin can do that. 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 UI. You can also factory reset the device back to the platform product (SILABS-WGM160P) from the DMS UI.
Caution: once you factory-reset the device, you will lose access to the device and it needs to use the terminal to activate it again. You should not perform this factory reset to a device in field, or a device you do not have a physical access to.
The regular recommended DMS flow is to first use a development product to release your firmware. Evaluate and test the bundle on your development device. Once everything is alright, create a production product and clone this bundle across. Always activate fleet devices to a production product (using an activation token) before shipping.