Flashing
A box already running Medius updates over the control port with UPDATE. This page is for a first install, and for a chip that can't update that way: one without the two-slot layout, or one whose app won't boot.
While firmware runs, no button is needed. REBOOT restarts a chip into ROM download mode (a built-in serial loader), and a flashing tool writes the image.
Write the bootloader, partition table, app and a blank otadata together, or the factory image (all four in one).
An app image alone keeps the chip's existing layout. A one-slot chip replies NOSLOT to UPDATE. The two slots are a partition-table change, so each chip needs one flash from this page, once in the box's life.
Two chips Flash each separately
The REBOOT target byte picks the chip.
| Chip | Reboot | Flashed over |
|---|---|---|
| Device chip | target = 0 | The same CH343 serial link, with esptool. |
| Host chip | target = 1 | USB3. The device chip relays the reboot over the inter-chip link. |
Version scheme major.minor.patch
Both chips carry the same firmware version, stamped into their app descriptors from one source. Binary and tag can't drift.
The protocol version is a separate byte that a host checks for compatibility. The firmware version identifies the build. QUERY(VERSION) returns both.
Notes
A run reboot (target = 2 or 3) is the only software cold-reboot. DTR/RTS aren't wired to reset on this board.
After a download reboot the port stays in the ROM bootloader (plain ASCII the frame decoder ignores) until flashing finishes or the box is power-cycled. Persisted per-box data survives an app reflash.
REBOOT needs working firmware to receive the frame. For a chip with no firmware or a bad image, hold its BOOT button while resetting or powering on the box.
From Rust, the crate's firmware update calls write both chips over the open connection.