IMPSPRGM · Interprocessor OTA

This page builds on IMPSPRGM · Interprocessor OS →. The three logical buses and the Translator described there are the transport for everything below.

The problem — updating two chips in the field

A dual-chip telemetry node has two firmware images that must always agree: the radio-side application running inside the modem, and the real-time logic on the MCU. In a conventional design each is updated by its own path — the modem app through the vendor's flash tooling, the MCU through a wired programmer on a service bench. That means a technician has to physically reach a device that may be inside a wall, a pit or a sealed enclosure; the two images can drift out of step; and a half-finished write on an 8-bit MCU with no second bank can brick the unit permanently.

Interprocessor OTA removes the programmer and the site visit. A single signed bundle arrives over the air, and the two cores update themselves in a coordinated, reversible sequence — using resources that are already on the board.

One bundle, two cores

The modem is the only part of the node with a wide-area link, megabytes of flash and a TCP stack, so it acts as the update host. The MCU is the update target that cannot reach the network on its own. IMPSPRGM lets the host flash the target across the same three-bus link used at runtime.

• Fetch. The SIM800C pulls a signed bundle over an already-open TCP socket into its on-module flash file system (EAT FS). Nothing touches the MCU yet.
• Verify. The bundle's signature is checked before a single byte is written to the target — the same keyed hash the node already uses to sign telemetry.
• Stage. The MCU image is carried across the Procedures bus page-by-page into the target's spare region; the modem's own new image is staged in a second EAT slot.
• Commit. Both cores switch to the new images at a single agreed point. If either side fails to come back healthy, both roll back.

Architecture at a glance

Because the update rides the existing buses, no extra pins, no debug header and no second radio are required. The MCU is written through its own on-chip mechanisms — the built-in UART bootloader for a full re-flash, or in-application programming (IAP) for a running update — both driven remotely by the modem.

Bus 1 · Commands — control the update

Short opcodes move the target between states: OTA_BEGIN, ENTER_BOOTLOADER, ERASE_PAGE(n), OTA_COMMIT, OTA_ABORT. Each side serves only the opcodes it can, so the same sequence works whether the MCU is updated via its bootloader or via IAP.

Bus 2 · Procedures — move and verify the image

The bulk of the work is a stream of remote procedure calls: write_page(addr, bytes) → ack and read_crc(addr, len) → crc16. Every page written to the target is read back and checksummed over the same call, so a corrupted transfer is caught immediately and re-sent, not discovered after reboot.

Bus 3 · Interrupts — progress and abort

Asynchronous tokens report progress (page k/N done), power events (a brown-out during flashing), and operator aborts. A low-battery interrupt can pause an update before an unsafe write and resume it after the next uplink.

Update sequence

1. Server publishes a new bundle; the node learns of it on its next scheduled uplink (or via an SMS wake).
2. Modem downloads the bundle into EAT flash over the open socket, resuming across dropped connections.
3. Signature verified on the modem; the delta for each core is unpacked.
4. Modem sends OTA_BEGIN, then streams write_page / read_crc pairs to the MCU while staging its own image.
5. Both cores arm the new images and OTA_COMMIT at one point; a post-boot health handshake confirms success — otherwise both revert.

Security of the update path

• Signed bundles only. The image is authenticated with the node's keyed hash before any write — the modem's core does the verification, so the 8-bit MCU never has to.
• Anti-rollback. A monotonic version counter refuses bundles older than the running image, so a captured old-but-valid package cannot be replayed to downgrade a device.
• No open programming port. The MCU's bootloader is entered only on command from the authenticated host over the internal bus — there is no externally exposed flashing interface on the enclosure.

Data & power cost

Only the changed regions travel: the bundle carries per-core deltas, not whole images, which keeps a routine update within a handful of kilobytes on the cellular link. The transfer reuses the socket that is already open for telemetry, and the MCU is only woken for the short windows in which it is actually being written — consistent with the anti-phase power strategy of the Interprocessor OS.

Where Interprocessor OTA fits

• Utility meters (water, gas, electricity) already installed behind walls or in pits, where a service call costs more than the meter.
• Geographically dispersed fleets that need a security or protocol fix pushed to every unit at once.
• Battery-powered nodes where a full re-flash would drain the cell — delta updates keep the airtime and the wake window small.
• Any dual-chip product that today ships with a debug header exposed only so a technician can update the MCU by hand.

References

• SIMCom — SIM800 Series Embedded AT Application Note, v1.03 (multi-threaded user tasks, SOCKET API, flash file system and flash writer).
• SIMCom — SIM800C Hardware Design, v1.02, 2015 (UART, DTR/RI wake lines).
• STMicroelectronics — STM8 bootloader (UM0560) — built-in UART/SPI bootloader for field re-flash.
• STMicroelectronics — STM8S Reference Manual (RM0016) — in-application programming (IAP) and flash block operations.
• Companion article — IMPSPRGM · Interprocessor OS (three-bus runtime and Translator this update path rides on).

Licensing & Intellectual Property

Commercial licensing model

IMPSPRGM™ is proprietary technology of LLC IMPSPRGM (Tashkent, Republic of Uzbekistan). The technology — including the reference firmware, the translator mechanism, the three-bus protocol, the over-the-air update path, the hardware integration library and the supporting design files — is distributed exclusively under a written Licence Agreement between LLC IMPSPRGM and the Licensee.

The licence is granted on a per-unit (per-device) basis. The Licence Agreement specifies the exact number of end devices in which IMPSPRGM may be embedded, and any additional units above that number require either a licence extension or a new agreement.

• Unit-based royalty model — a fixed production quantity is stated in the contract.
• Named, non-exclusive, non-transferable licence — sublicensing is prohibited.
• Source code, architectural diagrams, the translator mechanism and the update protocol remain the sole property of LLC IMPSPRGM.
• Reverse engineering, decompilation, re-distribution and derivative works are not permitted without prior written consent.

Commercial inquiries and per-unit quotations: impsprgm@umail.uz

Copyright & PCT protection

The IMPSPRGM technology is protected under the international Patent Cooperation Treaty (PCT). The application was filed electronically via ePCT-Filing and acknowledged by the Receiving Office.

← Interprocessor OS   Back to home