Firmware updates

Early prototypes use the normal CH32 programming/debug interface. Programming tools, exposed connector, and toolchain remain TBD. Remote updates are a future capability.

The intended Base Board could distribute one common hex image over the board communication link. Sequential updates reduce simultaneous disruption but do not by themselves make updates recoverable.

Requirements to investigate

A protected bootloader, application validation, firmware version, image checksum, retry behavior, and recovery from an interrupted write are desired. A checksum detects corruption; image authorization/authenticity is a separate unresolved requirement.

The CH32V003 has a small memory budget. Flash partitioning, bootloader protection, available write mechanisms, memory for buffering, and recovery entry need verification before promising IAP. No dual-image rollback scheme is assumed.

The protocol's candidate ENTER_BOOTLOADER command is only a placeholder. Enumeration after a failed update, address retention, compatibility checks, and how the game behaves while sensing is unavailable all need definition.

See hex-main protocol and Smart Hex software.