Firmware Update over RDM

Every KLSTR.nano device can be flashed over SWD/SWIM. But in the field the device is often tucked inside a fixture with only DMX/RDM as a communication option - that's why KLSTR.nano also supports Firmware Updates over RDM.

This page explains the protocol, MCU-agnostically. The reference implementation is the KLSTR.nano (STM32F103); a second runs on the ESP32-S3 (KLSTR.fixture).

The idea in one picture

The controller streams the firmware as a sequence of small chunks, each carried in one RDM SET. The device writes each chunk to its inactive flash slot, accumulates a checksum, and - once the image lands and verifies - flips a boot flag and reboots into it.

Two properties make this practical on a daisy chain: cut-through forwarding (every device re-emits RDM bytes port-to-port, so a broadcast chunk reaches all 32 devices deep) and manufacturer broadcast (one SET to a manufacturer's broadcast UID flashes every device of that manufacturer at once, leaving others untouched).

The protocol: a manufacturer-specific PID set

The transfer is driven by six manufacturer-specific RDM parameters (PIDs) in the 0xc8xx range - not standard E1.20/E1.37-2 PIDs, since RDM has none for firmware. Both ends must speak the same PID numbers.

How a transfer runs

1. Arm - file_setup (unicast). The controller names each target once, with flags bit 0 set so it will accept the broadcast chunks that follow.
2. Stream - file_chunk. The image is sliced into fixed 128-byte chunks, numbered from zero. Chunk 0 is a header, not data - it carries where in flash the image belongs, where its control block lives, and (if encrypted) the decryption seed; the device uses it to pick the inactive partition and reset its stream state. Real data starts at chunk 1, and the flash offset is computed as start + 128 × chunk_nb - sequence-addressed, not offset-addressed.
3. Confirm - file_report (must be unicast - it's a GET). Returns status == 0 if the on-device CRC32 matched, plus the crc itself so the controller can cross-check against its own. A mismatch means a chunk was dropped.
4. Reboot - control{reset_device}. The device replies first, then reboots, so the ACK is never lost. On the way up, the trampoline independently re-validates the image before jumping into it (see Fail-safe A/B boot).

Delivery: broadcast fast-path vs. unicast

Each device family advertises its own RDM manufacturer ID, giving it a naturally isolated broadcast group - one family's stream can never touch another's devices, and each family keeps its own broadcast fast-path.

The load-bearing constraint: flash writes vs. the RDM deadline

An RDM responder must answer within a few milliseconds, but a flash erase takes tens of milliseconds. You cannot both write flash and answer RDM on time.

Fail-safe A/B boot

The transfer is brick-safe by construction:

1. Write the other slot. The running firmware writes into the inactive partition only, so a failure mid-transfer leaves the running image intact.
2. Bump the boot priority of the new slot to one above the running slot, emulating an in-place overwrite without the risk.
3. Trampoline validates, then boots. On reset, a small trampoline picks the highest-priority valid partition - independently re-checking the image and control-block CRCs before jumping. A half-written slot fails validation and is skipped; the device falls back to the previous good image.

Integrity & security

RDM is unauthenticated and unencrypted - any controller on the cable can SET, and a firmware push is the highest-privilege operation there is. The reference implementation mitigates this two ways:

• Integrity (CRC32) - accumulated on the fly, returned in file_report, and re-checked independently by the trampoline before boot. Catches corruption, not tampering.
• Confidentiality (encrypted images) - release images ship obfuscated/encrypted and are decrypted on-device in the chunk handler; the seed lives in the chunk-0 header.

File format

A release file (.nano on the reference platform) is a ZIP of the two slot images - one linked for partition A, one for B - each encrypted. The controller picks the image matching the slot the device will write, reads the embedded control block (size, CRCs, SHA-1) for its own pre-flight check, and streams it.

Throughput: is it practical?

Expect minutes, not seconds - RDM flashing is a deliberate recovery / no-network fallback, not a replacement for the faster network path. Vendorcast doesn't scale with fixture count (the whole rig flashes in one pass); unicast does. Present it to the operator as the fallback it is.

Next steps