MCU — Zephyr (Nordic / STM32)

Beta

OTA-Pulse MCU is in beta. The device SDK is distributed to customers directly rather than from a public package registry, and we onboard MCU fleets with an engineer alongside you. Talk to us to get access.

The Zephyr port of the OTA-Pulse device SDK targets Cortex-M parts running Zephyr or the Nordic Connect SDK, with MCUboot as the bootloader. It integrates with Zephyr’s own subsystems — flash_area for storage, the settings subsystem for credentials, and PSA Crypto or TinyCrypt for hashing.

Validated targets

Board	Transports supported
nRF54L15-DK	BLE SMP, with encrypted and compressed images
STM32 Nucleo-F439ZI	Ethernet/HTTPS, CAN
STM32 Nucleo-H753ZI	Ethernet/HTTPS, CAN and CAN-FD

Other Cortex-M targets are covered by the same port and the SDK’s documented porting layer, but we have not run full update cycles on them ourselves — talk to us about your board before committing to it.

Prerequisites

• Zephyr v3.7 or the matching nRF Connect SDK, with a working west build (we build and test against Zephyr v3.7.0 with Zephyr SDK 0.16.8)
• MCUboot enabled, with two application slots in your device tree
• An OTA-Pulse organization with the MCU add-on enabled
• A device provisioning (claim) key from the console

Integration

1. Add the SDK as a Zephyr module.

   Add it to your west.yml manifest and enable it in prj.conf. Transports are compile-time options — enable only the ones your product uses, so unused transport code is never linked in.

2. Configure storage and crypto.

   The port uses Zephyr’s settings subsystem for credentials and flash_area for the image bank. SHA-256 comes from PSA Crypto when CONFIG_NRF_SECURITY or CONFIG_MBEDTLS is enabled, and falls back to TinyCrypt otherwise — it is a Kconfig choice, not a function of which SDK version you are on.

3. Provision on first boot.

   The device exchanges its claim key for a per-device API key over HTTPS and registers itself. The key is persisted through the settings subsystem.

4. Call the SDK from your main loop.

   The SDK writes the incoming image into the inactive MCUboot slot, hashing as it goes, and resumes an interrupted transfer instead of starting over.

5. Confirm after boot.

   Once your application is satisfied the new image is healthy, it calls the SDK’s confirm function, which marks the MCUboot slot permanent. If it never confirms, MCUboot swaps back on the next reset.

Signing

Sign your images with imgtool as usual — Ed25519 or RSA-2048 — and upload them to the console. For an unencrypted image the server verifies the MCUboot signature before accepting the firmware version. An encrypted image is opaque to the server, so it can only confirm a signature TLV is present — actual verification happens on the device, where MCUboot decrypts and checks it at boot.

Tip

MCUboot remains the authoritative verifier. The SDK’s own signature check is defence in depth on top of it, and the mechanism that protects targets where the bootloader does not verify at all.

Encrypted images are supported: MCUboot decrypts and decompresses at swap time, so the SDK streams the payload opaque and never holds plaintext firmware.

What Zephyr devices do not get

Remote SSH and coredump collection are embedded-Linux features and do not apply here. See platform support for the full matrix.