LogoLogo
GitHubBlynk WebsiteLogin to Blynk.Console
  • Introduction
  • Getting Started
    • Supported Hardware
    • Quickstart
      • Next Steps After Quickstart
      • Quickstart Device: Code Overview
      • Troubleshooting
    • Device Activation Methods
      • Manual Device Activation
      • WiFi provisioning
      • Static Token
    • Template Quick Setup
      • Set Up Datastreams
      • Set Up Web Dashboard
      • Set Up Mobile App Dashboard
      • Prepare Your Code
      • Test your Template
    • Send Data From Hardware To Blynk
    • Control Devices (GPIOs and beyond)
    • Events
    • Notifications (Alerts)
    • Sign Up / Sign In
  • General Concepts
    • Developer Mode
    • Device
    • Device Template
    • Connection Lifecycle
      • Disconnections And Heartbeat
    • Users
      • Multi-tenancy
    • Organizations
    • Automations
      • Forward Device Data
  • Message Usage
  • Integration Guides
    • Node-RED
    • The Things Stack
      • Getting Started
      • Device Grouping
      • Automated Device Onboarding
      • System DataStreams
    • Blues
    • NCD Industrial Vibration Sensor
    • Particle - monitor with Blynk
    • Particle - control with Blynk
    • AWS IoT Core
  • Myriota
  • OpenWeather
  • Blynk.Console
    • Overview
    • Dashboards
      • Dashboard Widgets
    • Devices
      • Device profile
        • Dashboard
        • Device Info & Metadata
        • Notifications & Events
        • Developer tools
          • General
          • Datastreams
          • Testing
          • Actions Log
      • Actions with devices
      • Segments
      • Filters
      • Notifications Settings
      • Device Sharing
    • Locations
      • Location Profile
      • Assigning Devices to the Locations
    • Organizations
      • Create a Sub-Organization
      • Working with Sub-Organizations
    • Users
      • User Profile
    • Device Templates
      • Working With Templates
      • Info
        • Offline Ignore Period
        • Manufacturer
        • Template ID
        • Categories
        • Hotspot Prefix
      • Datastreams
        • Datastream Settings
          • Name
          • Alias
          • Virtual Pin
          • Color
          • Data Type
          • Min Value
          • Max Value
          • Default Value
          • Save RAW Data
          • Invalidate Value
          • Wait for confirmation from device
          • Sync with latest server value every time device connects to the cloud
          • Expose to Voice Assistants
        • Virtual Pin
        • Location
        • Enumerable
      • Web Dashboard
        • Multiple Dashboard Tabs
      • Metadata
        • Metadata Tutorial
      • Connection Lifecycle
      • Events
        • Custom Events
          • Event Settings
          • How to Send/Log Events
          • Content Events
        • Notifications Settings
          • Custom Sounds and Critical Notifications
      • User Guides
      • Assets
    • Widgets (Console)
      • Switch
      • Slider
      • Number Input
      • Image Button
      • Web Page Image Button
      • LED
      • Label
      • Gauge
      • Chart
      • Map
      • Image Gallery
      • Custom Chart
      • Heatmap Chart
      • Video
      • Bitmask Table
      • Gradient Ramp
      • Terminal
      • Segmented Switch
      • Alarm & Sound Widget
      • Modules
    • Blynk.Air
      • Shipment Details
      • Shipment Management
        • New Shipping
      • Device shipment statuses
      • User-Controlled Shipments
    • Settings
      • Organization Settings
        • General
        • Users
        • Locations (Job Site or Facilities)
        • Tags
      • Roles and Permissions
      • Developers
        • OAuth2
        • Webhooks
        • Create New Webhook
      • Integrations
    • User Profile Menu
    • Limits
  • Blynk.Apps
    • Overview
    • Mobile Dashboard Editor
    • Device Header Constructor
      • Header Design
      • Header Mini Widgets
        • Connection Status Widget
        • Last Reported Widget
        • Tabs Widget
        • Datastream Value Widget
        • Image Widget
        • Battery Level Widget
        • Signal Level Widget
        • Tags Widget
      • Header Buttons
    • Pages
    • Widgets (app)
      • Common Widget Settings
      • List of Datastreams types supported by Widgets
    • Widgets Controllers
      • Button
      • Styled Button
      • Icon Button
      • Image Button
      • Slider
      • Vertical Slider
      • Step Slider
      • Vertical Step Slider
      • Joystick
      • zeRGBa
      • RGB Light Control
      • Step H
      • Step V
      • Slope Control
      • Switch
      • Level Slider
      • Level Slider with Switch
    • Widgets Displays
      • Value Display
      • Labeled Value
      • LED
      • Gauge
      • Radial Gauge
      • Enhanced Gauge
      • LCD
      • Simple Chart
      • SuperChart
      • Terminal
      • Video Stream
      • Level H
      • Level V
      • Image Gallery
      • Gradient Ramp
      • Icon
      • Image Animation
      • Lottie Animation
    • Widgets Interface
      • Tabs
      • Menu
      • Map
      • Text Input
      • Numeric Input
      • Time input
      • Segmented Switch
      • Icon Segmented Switch
      • Text
      • Formatted Text
      • Dynamic Spacer
    • Widgets Other
      • Music Player
      • WebPage Button
      • WebPage Image Button
      • Alias Name
    • Main Menu
      • My Profile
      • Organization
      • Settings
      • Help
      • About
      • Log Out
    • Devices
      • Add New Device
    • Automations
    • Notifications & Events
  • Blynk.Edgent
    • Blynk.Edgent overview
    • Blynk.Inject and Blynk.Air
    • OTA: Firmware Over-The-Air updates
  • Blynk.NCP
    • Blynk.NCP overview
    • Supported Connectivity Modules
    • OTA: Firmware Over-The-Air updates
  • Blynk Library - firmware API
    • Installation
      • Install Blynk Library in Arduino IDE
      • Install Blynk Library for Platformio.org
      • Install ESP8266 core for Arduino IDE
    • Configuration
    • Connection Management
    • Device Online/Offline Status
    • Digital/Analog Pins
    • Virtual Pins
    • Widget Properties
    • State Syncing
    • Timers
    • Time (RTC clock)
    • Timezone / Location
    • Log Event
    • Metadata
    • Debug
    • Reboot
    • Over-The-Air Firmware Updates (OTA)
    • Other
    • Limitations and Recommendations
    • Blynk Protocol
  • BLYNK.CLOUD MQTT API
    • Device MQTT API
      • Authentication
      • Topic Structure
      • Datastreams
      • Widget Properties
      • Events
      • Metadata
      • Timezone/Location
      • OTA
      • Miscelaneous
      • Code Examples
  • BLYNK.CLOUD HTTPS API
    • Device HTTPS API
      • Get Datastream Value
      • Get Multiple Datastream Values
      • Get Historical Data From Device
      • Update Datastream Value
      • Update Multiple Datastreams Simultaneously
      • Upload a Set of Timestamped Data
      • Update Widget/Datastream Property
      • Send/Log An Event
      • Get Device Metadata Value
      • Update Device Metadata Value
      • Is Device Connected
      • Upload a File
      • HTTPS API Troubleshooting
    • Platform API
      • Authentication
      • Ogranization API
        • Get Own Organization Info
        • Get Organization Info
        • Search Organizations
        • Create Organization
        • Get Static Tokens
        • Get Organization Tags
        • Get Organization Automations
      • Devices API
        • Get All Devices
        • Search Devices
        • Get Devices by Owner Email
        • Get Devices in user organization
        • Get Recently Activated Devices
        • Get Device Info
        • Get Connection Status
        • Create Device
        • Edit Device
        • Get Datastream Values
        • Update Datastream Value
        • Update Multiple Datastreams Values
        • Import Datastream Values
        • Update Datastream Property
        • Get Datastream Historical Data
        • Get Device Metadata
        • Update Device Metadata
        • Get Device Tags
        • Get Device Timeline Log
        • Log a Device Event
        • Get Actions Log
        • Erase All Data
        • Remove Device Owner
        • Transfer Device
        • Delete Device
      • Users API
        • Get All Users
        • Search Users
        • Create New User
        • Invite User
        • Get User Info
        • Update User Role
      • Templates API
        • Get All Templates
        • Get Template Info
        • Get Template Metadata
        • Get Template Datastreams
        • Get Template Events
    • Security
  • Downloads
    • Blynk Mobile Apps
    • Blynk Library
  • Troubleshooting
    • General Issues
    • Developer Mode
    • Changes from Blynk 0.1
      • Migrating to the new Blynk - Full Guide
    • Glossary
    • Links
  • Commercial Use
    • Deploying Products With Dynamic AuthTokens
    • Deploying Products With Static Tokens
    • Working With Clients
    • Supported topologies
    • Business Plan (White Label Solution)
      • App Publishing Process And Timeline
      • What's Needed To Publish Your Apps And Go Live
      • Branding Materials
      • Custom Email Address For Transactional Emails
      • Application Settings
        • General
        • Design
        • Mobile Apps
        • Sign Up
  • Add-Ons
    • Add-on list
    • Amazon Alexa
    • Google Assistant
    • Localization
    • Database Access
    • Marketing
Powered by GitBook
On this page
  • Blynk.Air for Dual-MCU
  • OTA package tagging
  • Firmware Update process
  • Resilent OTA upgrade
  • Dual-Bank (A/B) OTA Updates
  • NCP-assisted fail-safe OTA Updates

Was this helpful?

  1. Blynk.NCP

OTA: Firmware Over-The-Air updates

PreviousSupported Connectivity ModulesNextInstallation

Last updated 1 year ago

Was this helpful?

Over-The-Air (OTA) firmware updates are crucial to IoT devices because they allow for seamless software updates, security patches, and feature additions without the need for physical access to the device.

Blynk offers Blynk.Air for over-the-air updates of your devices' firmware. The setup and the process differs for various hardware configurations. This document refers to the specifics of the OTA updates for Dual-MCU configurations.

Blynk.Air for Dual-MCU

OTA package tagging

The Blynk Cloud identifies the firmware binary by looking for a special tag embedded in it. Firmware tag contains some metadata in a form of key-value pairs. You can include such a tag in your code:

#define BLYNK_PARAM_KV(k, v)    k "\0" v "\0"

volatile const char firmwareTag[] = "blnkinf\0"
    BLYNK_PARAM_KV("mcu"    , BLYNK_FIRMWARE_VERSION)       // Primary MCU: firmware version
    BLYNK_PARAM_KV("fw-type", BLYNK_FIRMWARE_TYPE)          // Firmware type (usually same as Template ID)
    BLYNK_PARAM_KV("build"  , __DATE__ " " __TIME__)        // Firmware build date and time
    BLYNK_PARAM_KV("blynk"  , BLYNK_RPC_LIB_VERSION)        // Version of the NCP driver library
    "\0";

Note: The information inside this tag MUST match the information provided by the Primary MCU in runtime using the rpc_blynk_setFirmwareInfo()

If your OTA process involves encrypting, compressing, re-packaging (or altering the raw firmware binary in any other way), you should add the equivalent tag to your final OTA package. Blynk provides a tool to automate this process.

Firmware Update process

  1. NCP invokes rpc_client_otaUpdateAvailable on the Primary MCU, indicating the filename, size, type, version of the new firmware

    • type, version could be empty strings, in case the firmware info was not detected by Blynk Cloud

  2. The Primary MCU should validate the received info (e.g., check if it is compatible with the current hardware and software) and return true if it accepts the update

  3. If the Primary MCU confirms the update (returns OK), it may perform any of the following steps (as needed):

    • Wait until the firmware update is appropriate, and finish any critical operations

    • Re-configure the NCP UART, i.e. change the baud rate

    • Reboot into bootloader mode or load a special firmware for handling the update process

    • Initialize the memory for receiving the new firmware (e.g., erase the target memory sector)

    • Ping NCP several times to ensure that the communication is working and the framing layer is synchronised

    • If the ping-pong process fails, the Primary MCU can attempt to reinitialize the communication (e.g., reconfigure the UART) and retry the process

    • etc.

  4. Primary MCU invokes rpc_blynk_otaUpdateStart function, indicating a suggested chunk size

    • The NCP should validate the proposed chunk size and ensure it is within acceptable limits

  5. NCP invokes rpc_client_otaUpdateWrite for each chunk sequentially; each request includes offset, data, CRC32

    • The actual chunk size can vary throughout the update, but it should never exceed the suggested chunk size

    • The Primary MCU returns false if it encounters a CRC mismatch or otherwise cannot process the packet

    • If the request fails or times out, NCP should resend the request up to 5 times before terminating the OTA process

    • If NCP faces issues downloading the update (i.e. due to the network failure), it invokes rpc_client_otaUpdateCancel

    • Primary MCU should also cancel the OTA if:

      • NCP stops sending new chunks of data (i.e. after 1 minute)

      • There is a power failure

  6. After the last packet is transfered, NCP invokes rpc_client_otaUpdateFinish

    • The Primary MCU can query additional info about the firmware, i.e. call CRC32, MD5 or SHA256 digest of the complete file

    • The Primary MCU should perform a final verification of the received firmware before confirming the completion of the update process

    • The Primary MCU returns True to the NCP to indicate that OTA will be applied.

    • NCP reboots at this stage and waits initialization from the Primary MCU (this step may be unneded/modified in future)

  7. The Primary MCU reboots and loads the new firmware

  8. As part of it's regular initialization procedure, the Primary MCU sends the new firmware type and version to the NCP

  9. The NCP provides the new firmware info to the cloud, at which point the upgrade is succesfully completed

Resilent OTA upgrade

The OTA update mechanism must be reliable, secure, and efficient to prevent the risk of bricking the device or leaving it open to security breaches. Below are some conditions that should be considered:

  • Insufficient Power: if the device is running on a battery, the MCU should check the battery level before calling rpc_blynk_otaUpdateStart. If there's not enough power to complete the update, it should delay the process until there's sufficient power.

  • Insufficient Flash Storage: MCU should also check if there's enough storage space to download and apply the update.

  • Corrupted Firmware File: MCU should validate the downloaded firmware, typically through checksums or cryptographic signatures, to ensure it hasn't been corrupted during the download. If corruption is detected, the MCU should discard the corrupted firmware and start a new download.

  • New Firmware Malfunction: the firmware update may be successful from an installation perspective, but the new firmware version may malfunction/crash due to various reasons such as programming errors, unhandled exceptions, or device-specific issues. To handle this, the MCU should include a post-update self-diagnostics phase. If this diagnostic test fails, the MCU should ideally rollback to the previous firmware version.

  • Generic Update Failure (Device Reset, Power Loss, Unstable Network, etc.): the MCU should be able to recover and either continue the update or roll back to the previous version on the next boot. Bricking of the device must be avoided.

It is recommended to emloy one of these OTA update strategies:

Dual-Bank (A/B) OTA Updates

In this (recommended) method, the flash memory of the MCU is divided into two separate sections (partitions, banks). One bank is used to run the existing firmware (Active), while the other is used to download and store the new firmware (Standby). After a successful update, the system reboots and switches to using the updated firmware. This method provides a fallback mechanism: if the update fails or the new firmware is faulty, the system can boot using the old, reliable firmware.

  • Pros: Provides high reliability, allows for immediate rollback if the update fails or new firmware is faulty.

  • Cons: Requires twice the memory to store two copies of the main firmware.

NCP-assisted fail-safe OTA Updates

In this alternative method, Blynk.NCP is used to assist the primary MCU during the update process. The primary MCU's bootloader fetches the firmware update from the NCP, verifies it, and applies it. If the update fails the bootloader can retry the update, mitigating the risk of bricking the device.

The internal filesystem of the NCP can typically store the complete MCU firmware binary. Before invoking rpc_blynk_otaUpdateStart, the MCU should call the rpc_blynk_otaUpdatePrefetch function. Firmware pre-fetching is recommended to eliminate the dependence on a stable network connection while the device is in bootloader mode.

  • Pros: Requires only one flash partition allocated for the main firmware. The bootloader can retry the update as many times as needed.

  • Cons: Rollback to a previous version of firmware is difficult to implement if the update fails or new firmware is faulty. The device cannot operate normally until the OTA update is completed successfully.


Irrespective of the method you choose, testing the OTA firmware updates under various conditions is crucial before deploying in a production environment. It will ensure that your IoT devices function as expected even after the firmware updates.

Here's the .

blynk_tag.py
reference implementation of this process