Running embOS Inside a Bootloader: Secure OTA on STM32 and nRF52 for Indian Automotive and IoT

Every Indian Tier-2 and Tier-3 supplier writing firmware for a two-wheeler ECU, a commercial-vehicle body controller, a smart-meter, or a battery-management system is now being asked the same question by procurement: “Does your ECU support over-the-air firmware update?” Five years ago the answer “we reflash over UDS at the service centre” was acceptable. In 2026 it is not. OTA is a line item on the RFQ.

The trap most Indian firmware teams fall into is assuming that OTA is “just” a download loop added to their existing bare-metal bootloader. It never is. The moment you introduce TLS (because procurement also asked for a secure channel), a progress indicator (because UX asked for a spinner), a USB fallback (because field-service asked for it), and a retry/resume path (because the device is a two-wheeler cluster on a rural 2G/3G link), the bare-metal bootloader becomes a tangled state machine nobody wants to own. The clean answer is to run a full RTOS kernel inside the bootloader stage itself.

SEGGER documents this pattern in Application Note AN01005, Using embOS for Cortex-M in a bootloader. This post is the Indian engineering-context version of that note, aimed at teams building OTA-capable ECUs, meters and IoT nodes in Bengaluru, Pune, Chennai, Hyderabad, Delhi NCR, and Mumbai on STM32 and Nordic nRF52 silicon.

GSAS Micro Systems is the authorized Indian partner for SEGGER Microcontroller GmbH and licences embOS, emNet, emSSL, emFile, and emSecure royalty-free per product to Indian OEMs. The combination below is the one we recommend and support locally.

Why hand-rolled bare-metal bootloaders break

The honest reason Indian teams end up with fragile bootloaders is that the OTA code path is fundamentally a concurrent workload, and concurrency on a bare-metal state machine gets ugly fast. Concretely, all of the following happen at the same time:

• A TLS record is being decrypted (CPU-bound, not cancellable mid-record).
• A TCP ACK timer is counting down (must fire on time or the download stalls).
• External flash programming is in progress (stalls the CPU if the flash driver is polling-mode).
• A watchdog needs to be kicked every 500 ms.
• A progress bar on a small OLED needs to repaint every 100 ms so the user does not think the device has bricked.
• The user might press a “cancel” button at any time.

On bare metal, you end up with nested polling loops, flag variables, timer-driven state transitions, and a prayer that no single operation takes long enough to miss the watchdog. An RTOS kernel gives you the native concurrency primitives this workload actually wants: the TLS state machine runs in one task, the progress UI runs in another, the USB fallback listener runs in a third, and the kernel’s scheduler makes sure none of them starve the watchdog.

What “embOS in the bootloader” actually looks like

embOS is small enough to fit inside the bootloader image budget on essentially every modern Cortex-M. On STM32F4 and STM32H7 the kernel plus task control blocks fit easily inside the 64 KB typically allocated to a bootloader partition. On nRF52840, the same is true, even with the SoftDevice preserved in its own region.

The mechanical steps AN01005 documents:

• Separate vector table via VTOR. The bootloader has its own vector table at the reset address. When the bootloader decides to hand off to the application, it writes VTOR to point at the application’s vector table and then jumps to the application reset handler via the address stored in the first word of that table. This is standard Cortex-M practice.
• Separate stack setup. The bootloader runs on its own MSP, configured from its own vector table’s first word. embOS’s own task stacks are allocated out of the bootloader’s RAM region, not the application’s. Before handing off to the application, the bootloader tears down its task stacks and re-initializes MSP from the application’s vector table.
• Clean kernel shutdown before handoff. embOS provides OS_Stop() (or equivalent in recent versions, check your licensed version’s API reference) to stop the scheduler cleanly before the jump. Interrupts are disabled, SysTick is stopped, and the jump to the application happens in a well-defined CPU state.

None of these steps are STM32- or Nordic-specific; they are generic Cortex-M. The resulting bootloader is vendor-portable in a way that most hand-rolled ones are not.

Wiring emNet + emSSL into the bootloader for HTTPS OTA

The network stack inside the bootloader is exactly the same emNet and emSSL stack Indian teams already use in the application. The point of running it inside the bootloader is that the bootloader is self-sufficient, it does not have to trust the currently-installed application to hand it a validated image.

Typical Indian deployment topology:

• HTTPS OTA endpoint hosted on AWS IoT Core in the Mumbai region (ap-south-1) or Azure IoT Central India Central. The certificate chain rooted at AWS’s Starfield or Azure’s Baltimore CA is baked into the bootloader’s trust store at build time.
• DNS resolution via the cellular modem’s PDN context or the device’s Ethernet connection.
• TLS 1.2 with ECDHE-ECDSA-AES128-GCM-SHA256 as the mandated cipher suite for the download. emSSL’s cipher-suite selection list is trimmed at build time to exactly what the server expects, this is critical on a bootloader because every unused cipher suite is ROM space you do not need to burn.
• Resumable HTTP GET with Range: headers so that a downloader that loses the modem mid-update can resume from where it left off. This is the difference between “OTA works on a bench” and “OTA works in a two-wheeler riding through a rural Maharashtra cellular dead-zone”.

We walked through the broader emNet/emSSL-on-AWS-IoT-Mumbai story in our Indian OTA TLS post; this post is specifically about running that stack inside the bootloader rather than inside the application.

Staging the image in external flash with emFile

Committing a downloaded image directly over the live application partition is how Indian teams brick units in the field. The correct pattern is to download into a staging area first, verify the full image end-to-end, and only then commit it.

emFile handles this cleanly. Wire emFile against your external QSPI or SPI NOR flash (MX25L, W25Q, or equivalent, the parts Indian contract manufacturers stock as standard) and format a dedicated partition as the OTA staging area. The download task writes into a file; the verification task reads the file back out to compute its hash; the commit task copies the file contents into the primary application partition.

Two Indian-specific practical notes:

• Most Indian OEMs use W25Q-class SPI NOR parts because they are available from local distributors in Mumbai and Chennai at short lead times. emFile’s generic SPI NOR driver supports these out of the box; you do not need a vendor-specific driver.
• On automotive programs, the staging partition must survive a brown-out mid-write. Use emFile’s power-fail-safe journaling configuration, it is a one-line configuration flag, and the partition will self-recover on the next boot if the vehicle’s 12 V rail dropped below the brown-out threshold.

The trampoline pattern for bootloader self-updates

The last frontier every Indian OTA program eventually has to cross is “how do we update the bootloader itself without bricking the unit if the update fails half-way?” The answer is the trampoline pattern, and it works the same with or without embOS.

The flash layout carries two bootloader slots plus a tiny immutable trampoline:

• Immutable trampoline (a few hundred bytes at the reset vector), picks between bootloader slot A and slot B based on a persistent flag.
• Bootloader slot A: active bootloader.
• Bootloader slot B: staging area for the next bootloader image.
• Application partition: where the main firmware lives.

When a bootloader update arrives, the active bootloader downloads the new bootloader image into slot B, verifies its signature with emSecure, and flips the trampoline flag to point at slot B on the next reset. If the new bootloader fails to come up cleanly, the trampoline flips back to slot A. The trampoline itself is tiny and never changes, so it cannot brick the unit.

Signing and verifying the image with emSecure

emSecure gives Indian teams a standards-based signing and verification flow: RSA-2048 or ECDSA-P256 signatures, SHA-256 hashes, and a small verifier that runs inside the bootloader in a few KB of ROM.

The production flow Indian teams converge on:

1. Build server produces the application image.
2. Build server hashes it with SHA-256.
3. An HSM (Yubico YubiHSM, AWS KMS in Mumbai region, or Azure Key Vault India Central, pick per procurement policy) signs the hash with the per-product private key.
4. Signature is appended to the image.
5. Image is published to the OTA endpoint.
6. Bootloader downloads the image, recomputes the hash, verifies the signature against the public key baked into bootloader ROM, and only then commits it to the application partition.

No Indian automotive or medical OEM should be shipping OTA without something equivalent to this chain. emSecure gives you the in-device half of it, and it is compact enough to fit in the same bootloader binary that already contains embOS, emNet, emSSL, and emFile.

Field debugging the bootloader itself

The moment a bootloader update misbehaves in the field, somebody has to physically attach a debug probe to a unit and capture what went wrong. This is exactly the workflow J-Link and Ozone are built for.

At an Indian customer site, a two-wheeler assembly line in Pune, an industrial gateway at a cement plant outside Hyderabad, a smart-meter panel in a Chennai substation, the field engineer connects a J-Link to the SWD header, opens Ozone with the bootloader’s ELF file, and gets full source-level debug of the bootloader with all its embOS tasks visible in the thread window. SystemView captures a timeline of the TLS handshake, the flash write, and the verification task so the root cause of the failure is obvious in one session.

Why Indian two-wheeler and commercial-vehicle Tier-2 suppliers should care

OTA is no longer an optional differentiator on Indian vehicle programs. OEMs in Chennai and Pune are writing it into their RFQ checklists. Tier-2 suppliers who show up without a defensible OTA story lose the seat. The SEGGER stack, embOS + emNet + emSSL + emFile + emSecure, is the fastest defensible path for an Indian supplier to put OTA on their product pitch without taking a 12-month hit on a from-scratch implementation.

It is also the defensible story on safety programs. The embOS safety variant we covered for Indian automotive Tier-1s extends the same kernel into ISO 26262 territory, so the bootloader you ship this year is not a dead end for the safety-certified program you will bid for next year.

Further reading

• SEGGER AN01005, Using embOS for Cortex-M in a bootloader
• GSAS, SEGGER partner page
• GSAS, embOS product page
• GSAS, emNet product page
• GSAS, emSSL product page
• GSAS, emFile product page
• GSAS, emSecure product page
• GSAS blog, emNet + emSSL TLS to AWS IoT Mumbai and Azure India
• GSAS blog, embOS on Indian automotive Tier-1 ISO 26262 programs
• GSAS blog, embOS tickless mode for battery-powered IoT in India

To scope an OTA-capable bootloader for your STM32, nRF52, or other Cortex-M product, contact GSAS Micro Systems in Bengaluru, Chennai, Hyderabad, Pune, Mumbai, or Delhi NCR and our engineering team will work with you on the embOS licensing, the emNet/emSSL stack sizing, and the emSecure signing key management for your production line.