A-active devices receive slot B; B-active devices receive slot A.
Validation
Evidence before applause.
The final story is backed by board-level tests, negative security tests, reset persistence, fallback recovery, and a release tool that makes the process repeatable.
Bad manifest fails at check; bad payload fails during install.
Final signed OTA remains active after software reboot and hardware reset.
The GUI generates, signs, uploads, and verifies release output.
Version: V1.0.26
Evidence: Full OTA video shows install, reboot, and hardware RST persistence.
Why it matters: Proves the final release path works beyond hand-built manifests.
0.01First hardware contact
UART visibility, ToF bring-up, and the first usable distance logs made the board observable.
0.05Sensor signal cleanup
Range status, zero readings, and 8190 mm failures became filtered sensor semantics.
0.10RTOS foundation
FreeRTOS, CPU/GDB inspection, boot-chain visibility, and task-level debugging came online.
0.15Dual ToF platform
XSHUT sequencing and I2C address control turned two same-address sensors into a usable platform.
0.20Display bring-up
HX8357D moved from white/black screens and bus timing failures into real UI graphics.
0.25Touch recovery
Dead ADC values became mapped touch input through bench tests, voltage checks, and coordinate modeling.
0.30Interactive prototype
The screen became an input surface with drawing, palette tests, erase behavior, and UI feedback.
0.40Product definition
The project became a door-side reminder device with weather context, presence sensing, and hook LEDs.
0.50Layered architecture
Drivers, screens, services, managers, storage, and UI boundaries replaced one-off demo wiring.
0.60Connected product
Wi-Fi, Node-RED time/weather/reminders, location, and NVM3 memory formed the connected path.
0.70Power and UX polish
Sleep/wake, brightness, distance behavior, settings, and recovery from display artifacts improved the product feel.
0.80Release discipline
Build, flash, GDB, serial, testbed, backup, and artifact workflows became repeatable.
0.85First OTA reality
V1.0.6 and V1.0.12 exposed manifest paths, upload directories, reboot timing, and release-state problems.
0.90Local A/B fallback
Recovery moved from cloud-side old packages toward real local A/B trial and confirmed-slot behavior.
0.95Slot-aware OTA
Active-slot detection, target inactive slot selection, and reboot persistence became the central reliability story.
0.97Failure defense
Fallback and bad-package tests proved that the system had to reject failure, not only celebrate success.
0.99Signed release chain
Ed25519 signed manifests and payload SHA-256 binding added a real release security boundary.
V1.0.0Official showcase story
The public story became one complete embedded product: sensing, UI, LEDs, OTA, fallback, security, and tooling.
V1.0.16Clean OTA baseline
A stable A-slot baseline combined stack, Wi-Fi, presence, and touch-reboot fixes for OTA validation.
V1.0.17A to B upgrade
The board validated inactive-slot installation from A into slot B after the reboot-touch path was fixed.
V1.0.18B to A upgrade
The second direction proved the release path was not hardcoded to one slot or one version pair.
V1.0.19Fallback and bad package
Dedicated negative releases demonstrated local fallback and bad-package refusal on real hardware.
V1.0.20Signed manifest OTA
A valid signed release installed and survived reset; a bad-signature manifest failed during check.
V1.0.21Payload hash binding
Firmware verified the staged payload SHA-256 against the signed manifest, then passed a positive board test.
V1.0.22Tampered payload rejection
A validly signed manifest with modified payload bytes passed check but failed install with checksum error.
V1.0.23Release tool integration
The GUI/tool flow joined A/B package generation, signing, upload, and endpoint verification.
V1.0.24LED and OTA coexistence
The install path paused hook LED I2S refresh during flash operations, keeping LED-on without destabilizing OTA.
V1.0.25Frozen signed baseline
The final stable engineering baseline froze LED-on behavior, A/B OTA, fallback, signed manifests, and release tooling.
V1.0.26Tool-generated proof
The release tool generated and uploaded A/B artifacts, and the device stayed on the signed OTA after RST.
V1.0.27Final negative evidence
Fallback, bad package, bad signature, and LED behavior were recorded as presentation-ready validation media.
Protocol
A release has to pass the whole chain.
The validation story is deliberately staged. A bad manifest should never reach install; a bad payload should never become a trial image; a bad trial should recover.
PhaseAcceptsRejectsArtifact
CheckSigned manifest with canonical fields and a known key id.Edited JSON, stale signature, unknown signature fields.Observed result: check failed for bad-signature manifest.
DownloadRPS URL selected for the inactive slot by Node-RED.Wrong slot policy, missing file, mismatched remote release target.Release tool validates slot A and slot B fw/check responses.
InstallPayload bytes whose SHA256 matches the signed manifest.Modified or truncated payload before it becomes a trial image.Bad package video shows check success followed by install failure.
ConfirmNew firmware reaches runtime health and survives reset.Trial image that cannot confirm within the safety window.Fallback test returned to the confirmed firmware.
Evidence board
Every critical release path has a witness.
The validation set covers the normal OTA path, policy rejection, payload rejection, fallback recovery, release-tool output, and the LED behavior that had to survive the final install path.
V1.0.26
Successful signed OTA
Installed and survived RSTThis is the hero proof slot for the final baseline: tool-generated signed release, confirmed after reboot and RST.
Local check, install screen, full OTA video, and hardware RST persistence.
1027 negative test
Bad release rejection
Signature path refusedKeeps the security story visible: bad release metadata is not treated as a normal upgrade.
The device shows the negative signed-release path instead of accepting unsafe update policy.
1027 negative test
Bad payload rejection
Install failedProves the signed SHA256 field binds the manifest to exact RPS bytes and stops a bad package before trial boot.
Bad-package video showing check success followed by automatic install refusal.
1027 fallback
Fallback recovery
Returned to confirmed slotDemonstrates that a bad trial image does not brick the device and that confirmed firmware remains recoverable.
Full fallback video returning from trial V1.0.27 to confirmed V1.0.26.
V1.0.26
Release tool output
A/B packages and signed manifestsConnects the polished product story to the repeatable developer workflow.
Generate, upload, and WinSCP remote file proof for both A and B release artifacts.
1024-1025
LED behavior retained
Hook LEDs work after OTA fixHighlights the final engineering fix: OTA install pauses I2S LED refresh, then resumes product behavior.
OTA install pauses I2S LED refresh during flash operations, then resumes the product LED behavior.