Share via

Downstream OTA Updates with Azure Sphere

  • Article

Many Azure Sphere solutions incorporate both an Azure Sphere certified MCU and other processors as part of a complete IoT solution. These other processors need regular firmware updates. This guide describes how to enable downstream OTA updates using Azure Sphere.

Depending on the particular application scenario, there are a number of different ways to achieve this. Each solution has a common flow:

  1. Trigger the firmware update.
  2. Acquire the firmware update.
  3. Determine an intermediate download location.
  4. Validate firmware and update downstream processor.

Stage 1: Trigger the firmware update

Problem: How is the firmware update process initiated?

Options:

  • Each Azure Sphere app version is tied to a downstream firmware version:

    • Description: When the Azure Sphere app starts, the supported firmware version is compared with the deployed version on the downstream processor. If the versions do not match, an update is needed.
    • Pros: Defined support contract between the Azure Sphere app and the firmware version. Also, leverages the existing Azure Sphere app update process.
    • Cons: Must update the Azure Sphere app to trigger a firmware update even if there are no Azure Sphere app changes. Also, must add monitoring of update progress.

  • Azure IoT Hub device management firmware update:

    • Description: When a firmware update is ready, an IoT Solution operator creates a new device management configuration with the updated firmware. The Azure Sphere application receives the firmware update request and can begin the update.
    • Pros: Easy management solution to define, trigger, and monitor an update.
    • Cons: Must use Azure IoT Hub, no other cloud endpoints are supported.

  • Separate firmware check (custom solution):

    • Description: Build a custom firmware check into the Azure Sphere application. Regularly check a defined endpoint for a new version and if one is detected, initiate an update.
    • Pros: Works with any cloud endpoint to download firmware.
    • Cons: Must add monitoring of update process. Custom built solution, so not leveraging any existing update pathways.

Recommended Solution: If triggering updates for downstream processors via the Azure Sphere app updates works for your scenario, this approach is recommended. This solution ensures that the Azure Sphere and downstream firmware versions are always matched, and it does not require building out another system for triggering updates. Otherwise, if the application already uses Azure IoT Hub, IoT Device Management is the recommended solution, else a custom solution is required.

Examples:

Stage 2: Acquire the firmware update

Problem: How should the firmware be downloaded given the memory constraints of the Azure Sphere MT3620?

Options:

  • Include the downstream firmware into the imagepackage deployed to MT3620. This is possible if the total size of the MT3620 software including the downstream image does not exceed the documented flash limit.

  • Download the firmware from a hosted location, for example using Azure Blob Storage. It may be necessary to download the firmware in chunks since the RAM limit of MT3620 may preclude the whole image being downloaded to RAM. It is important to validate the server used for firmware download—for example, by using HTTPS—to ensure that only trusted firmware is downloaded and applied on the downstream processor. Note that in this case, it is possible for a device to be online while the Azure Sphere app is updated, but then go offline before the new app can download new downstream firmware. If this is a possibility for your use case, it is important to maintain compatibility between the Azure Sphere app and older downstream firmware versions.

Recommended Solution: If the firmware image fits into the flash limit of the Azure Sphere imagepackage, and if it is acceptable to update the MT3620 software each time a downstream update is needed, then it is recommended to include the downstream image into the MT3620 imagepackage. Otherwise, you will need to download the firmware image from your hosted location.

Examples:

Stage 3: Determine an intermediate download location

Problem: This problem is only relevant if you are not using a firmware image incorporated into the Azure Sphere imagepackage, and where the firmware downloaded is larger than the available RAM on MT3620.

Options:

  • External flash connected to Azure Sphere.
  • Downstream MCU or PC storage.

There is no right or wrong answer for where to store the downloaded firmware. This choice depends on your hardware setup and cost. What is the best option for you? You might consider attaching external flash memory to your Azure Sphere device or selecting a downstream processor with large enough storage to receive the firmware update.

Recommended Solution: Select the best option for your setup.

Examples:

Stage 4: Validate firmware and update downstream processor

Problem: How do you validate and apply the firmware update to your downstream processor?

Options: Every processor will have a different solution. Most processor manufacturers have samples that show how to perform firmware updates on their devices and you should follow the best practices for your specific solution. Your firmware download and update should perform an integrity check to validate the firmware before starting the update.

Recommended Solution: Differs for every processor. Please see your processor manufacturer’s sample.

Example: ExternalMcuUpdate reference solution demonstrates how to update a Nordic nRF52 over a UART interface from MT3620.