SEGGER emLoad: Dual-Image A/B OTA Firmware Updates for Indian Programs

For any Indian embedded programme shipping in volume, the hardest engineering question is not “how do we build the first firmware?”, it is “how do we safely update the firmware a year later, in a field we cannot physically reach?” SEGGER emLoad is the commercial bootloader from SEGGER Microcontroller GmbH that answers this question with a dual-image A/B update flow, integrated signature verification, and a power-fail-safe atomic swap. At GSAS, as the authorised SEGGER engineering partner for India, we integrate emLoad on customer silicon across smart metering, electric vehicle charging, solar inverter telemetry, and automotive Tier-1 ECUs. This post is a deep, India-localised walk through why A/B dual-image is the right pattern, what emLoad gives you out of the box, and how it fits onto the Cortex-M parts Indian OEMs actually ship.

Why single-image “update-in-place” breaks for Indian field programmes

The naïve pattern, erase the active flash bank, write the new image, reboot, is simple and it works on the bench. It collapses in the field the first time any of these happen: power is interrupted mid-write (common on rural feeders), the download is truncated by a flaky 4G link, the new image has a latent bug that only shows up on production traffic, or an attacker injects a malformed image. In every one of those cases the device is bricked and someone has to physically visit it with a J-Link and a laptop. For a 2-million-node smart meter rollout across several Indian discoms, that outcome is not acceptable: the per-truck-roll cost exceeds the price of the meter itself.

Dual-image A/B is the industry answer. The flash is partitioned into two application slots. At any moment, one slot is “active” and running; the other is “staging”. An update is downloaded into the staging slot while the active image continues to serve the device. Only after the staging image has been fully written, integrity-verified, signature-checked, and marked valid does the bootloader flip a small commit flag and reboot into it. If the new image fails to boot, fails a self-test, or fails to heartbeat back to the Device Concentrator Unit within a timeout, the bootloader automatically rolls back to the last-known-good slot. The device is never unbootable. This is the guarantee Indian programme owners mean when they say “brick-proof”.

What SEGGER emLoad actually gives you

emLoad is not a reference example, it is a production bootloader delivered as source, with an MISRA-clean coding style, a small footprint, and drivers for the storage and communication back-ends Indian programmes actually use. Out of the box it handles the bootloader state machine (current slot, staging slot, commit flag, roll-back counter), image header parsing, integrity check, optional decompression via emCompress, and signature verification via emSecure-RSA or emSecure-ECDSA. The signature check is the load-bearing security control: on every boot, emLoad recomputes the hash of the candidate image and verifies the RSA or ECDSA signature against a public key that lives in one-time-programmable memory, read-only flash, or a secure element. No signature, no boot. A tampered image, even one byte off, fails verification and is rejected.

The signature verification is the reason emLoad is used on programmes where the regulatory auditor will ask “show me that an attacker who owns your OTA back-end still cannot push malicious firmware to a meter”. The private signing key lives in an HSM at the OEM’s secure build server, usually a Thales or Utimaco appliance behind a programme-specific KMS, and the public key is burned into the device at production. emLoad does not need network access to verify; the check is entirely local, deterministic, and runs before the new image is allowed to become active.

For compressed payloads, emLoad couples with emCompress to decompress during the programming step. On a constrained Cortex-M part where flash is the tightest resource, shipping a compressed image across the network and expanding it in the bootloader saves both bandwidth and storage, the staging slot still needs to hold the expanded image, but the over-the-air payload is materially smaller.

The A/B flow in practice, step by step

A typical update cycle on an Indian deployment looks like this. The device’s application, running under embOS, the SEGGER real-time kernel, receives a “new firmware available” message from its back-end. On a BIS IS 15959 smart meter that message comes from the Head-End System via the Data Concentrator Unit over RF mesh or cellular. On an OCPP 1.6J or 2.0.1 charge point it comes from the Central System Management Software via the UpdateFirmware request. On an automotive Tier-1 ECU it comes over the vehicle bus using UDS services 0x34 (RequestDownload), 0x36 (TransferData) and 0x37 (RequestTransferExit), at the application level, while at the storage layer the data actually lands in the inactive slot managed by emLoad.

The application downloads the image chunk by chunk, verifies each block, and writes it to the staging slot. Because emLoad’s flash driver understands the sector geometry of the target part, writes are aligned and sector-erase is explicit. When the last chunk is written, the application asks emLoad to mark the image as “candidate” and triggers a reset. On reset, the bootloader computes the hash, runs the signature verification, and, if it passes, atomically updates a small commit record. That commit record is the only thing that distinguishes “A is active” from “B is active”. Because the commit is a single, small, well-defined write, it is atomic with respect to power loss: either the new commit lands or the old one is unchanged. There is no half-committed state.

On first boot of the new image, emLoad sets a “pending confirmation” flag. The application must, within a programme-defined window, call back into emLoad to confirm the update is healthy. If the confirmation call does not arrive, because the new image crashed, hung, watchdogged, or failed a self-test, the next reset lands in the bootloader, which sees the unconfirmed flag and rolls back to the previous slot. The device is back on known-good firmware with zero human intervention. This is the “auto-rollback” guarantee that makes dual-image A/B the default choice for Indian field programmes.

Power-fail safety and the role of emLoad’s flash driver

India has more than its share of grid events, voltage dips, sags, and hard outages. A bootloader that cannot survive a power cut during a flash write is a bootloader that will brick devices in the field. emLoad’s design splits the problem into two independent concerns: the staging area and the commit.

While writing the staging slot, a power cut is cheap: on reboot the commit record still points at the old active slot, and the unfinished staging write is simply retried on the next update attempt. The staging slot can be in any state, blank, partially written, corrupted, and the device still boots because nothing has told the bootloader to use it yet. The atomic commit is the only single-point decision, and because it is small, aligned, and written in a defined order, it survives a power cut cleanly. For NOR flash parts the commit lives in a dedicated erase block that is written with a specific bit-pattern protocol; for parts where the commit sits in an emFile journal the Journaling add-on provides torn-write safety at the filesystem layer.

Indian use cases: where emLoad earns its keep

Smart meters under BIS IS 15959. The Indian smart-metering programme sends firmware updates from the Head-End System down through the Data Concentrator Unit to the meter. The meter must accept the update while continuing to bill accurately, verify the signature against a utility-owned public key, and roll back automatically if the new firmware fails to reconnect to the DCU within a regulatory window. emLoad’s dual-image layout plus emSecure-ECDSA signature check is exactly the shape of that problem.

EV charging stations running OCPP 1.6J and OCPP 2.0.1. Indian charging networks routinely push firmware updates for metering algorithm fixes, new tariff logic, and OCPP message-handling patches. A charge point that bricks on an update takes revenue offline. emLoad plus emNet plus emSSL handle the secure download; the A/B flow handles the safe apply; and the confirmation-window rollback handles the “new firmware won’t start a session” failure mode. Both 1.6J and 2.0.1 are in live use across Indian networks, so the bootloader must support being called from either OCPP version’s UpdateFirmware workflow.

Solar inverter string monitors. Rooftop and utility-scale solar installations across India ship telemetry to cloud back-ends over cellular. Firmware updates are pushed when MPPT algorithms improve, when new anti-islanding rules are issued, or when security patches are cut. These devices are bolted to a junction box on a roof, physically reaching them is expensive. emLoad’s guarantee of “never unbootable” is the difference between a fleet-wide software-only recovery and a crew with a ladder.

Automotive Tier-1 ECUs using UDS. For UDS-based programming, the transport and session management are handled by the application-level bootloader using UDS services 0x34, 0x36 and 0x37. What emLoad contributes is the storage layer underneath: the dual-bank layout, the signature verification, and the safe commit. The UDS flow writes the transferred blocks into the staging slot; only once TransferExit succeeds and the signature is verified does emLoad flip the commit. This cleanly separates the diagnostic/protocol layer from the security-critical storage-and-verify layer, and it is the pattern we recommend on every Indian automotive programme we support.

Target silicon: which variant for which Indian-market part

emLoad is portable across Cortex-M families. On the parts Indian OEMs actually ship, three targets dominate.

STMicroelectronics STM32H7 is the workhorse for high-end metering, industrial gateways, and EV charge controllers. Dual-bank flash is native, two 1 MB banks on most variants, which maps one-to-one onto emLoad’s A/B model. The cache and the I/D-TCMs need careful handling during bank swap, and emLoad’s STM32H7 port already gets this right.

NXP i.MX RT1170 is the go-to crossover MCU for high-performance industrial HMIs and premium charge points. External XIP QSPI flash is standard on these parts; emLoad’s flash driver understands the XIP remap so the bootloader can switch which image is mapped at the execute address on the fly. The dual 1 GHz Cortex-M7 and Cortex-M4 cores also open the door to asymmetric boot flows where the -M4 stays alive during an -M7 reflash.

Renesas RA6M and RA8 parts, built on Cortex-M33 and Cortex-M85, are increasingly common in Indian smart metering and industrial control. The Arm TrustZone-M isolation on RA6M4 and the Ethos-U55-paired RA8 parts both pair well with emLoad’s signature verification because the public key can be locked into a secure partition outside the reach of normal-world code.

Other parts we see regularly in Indian programmes, STM32F4/F7/U5 for cost-sensitive designs, Nordic nRF52840 and nRF5340 for Bluetooth Low Energy asset tags, and GD32F4/E5 for domestic replacements, are all supported by emLoad’s driver set. The core logic of the bootloader does not change across targets; what changes is the flash sector driver and the commit-write strategy.

Further reading

External, canonical SEGGER references:

• SEGGER emLoad product page (segger.com)
• SEGGER emSecure-RSA and emSecure-ECDSA (segger.com)

GSAS internal cross-links:

• SEGGER partner page, full catalogue and India engineering support
• emSecure, digital signature libraries for update verification
• emCrypt, cryptographic primitives used by emSecure
• embOS, the RTOS most Indian emLoad customers run above
• SEGGER Flasher for secure encrypted firmware in Indian EMS production
• SEGGER emNet + emSSL TLS to AWS IoT in Mumbai and Azure India
• Automotive solutions, Tier-1 ECU programmes we support

A/B dual-image OTA is one of those architectural decisions where the cost of being wrong is measured in field truck-rolls and recalled hardware. SEGGER emLoad is the commercial bootloader we recommend across Indian programmes because it is production-tested, MISRA-clean, power-fail safe, and pre-integrated with emSecure for signature verification. If you are planning an OTA programme and want to review the flash layout, the signing flow, or the integration into your UDS or OCPP stack, the GSAS engineering team works with SEGGER customers across Bengaluru, Chennai, Hyderabad, Delhi NCR, Mumbai and Pune: reach out and we will walk the architecture with your firmware lead.