FlashBridge: Network-to-Silicon ESP32 Programming

FlashBridge turns a low cost Arduino Portenta into a remote ESP32 programmer that stages, resumes, flashes, and verifies firmware over Ethernet or WiFi, without a direct PC-to-ESP32 cable.

Comment

Inspiration

FlashBridge started from a very practical moment: seeing a coworker who genuinely needed a safer, easier way to program ESP32-based hardware remotely since the hardware could not be brought into their office. This was not an abstract idea or a trend-chasing project. It came from being close enough to real embedded workflows to recognize that moving firmware reliably from a developer’s machine, across a network, and into silicon is still much harder than it should be.

What made this project especially compelling was that we were in a position to understand both sides of the problem. We understood the day-to-day friction of embedded bring-up, and we were also early enough with AI-assisted development to see that a modern coding agent could help accelerate a solution. At first, we thought this might be a one-afternoon experiment wherein we decided to code only with AI Prompts. Instead, it became a three-weekend build that proved both the opportunity and the depth of the challenge.

What it Does

FlashBridge Network-to-Silicon ESP32 Programming turns a low cost Arduino Portenta H7 into a network-connected remote programmer for ESP32-family devices. It receives firmware artifacts over Ethernet or WiFi, stages them safely, then drives the target ESP32 into ROM bootloader mode and flashes it over UART using reset and boot control lines.

In practice, that means a developer or operator can push firmware across the network to a remote programming bridge instead of manually handling local serial tools at the point of hardware access. The system validates staged files, manages flash sequencing, and verifies what was actually written to the target device. The result is a more reliable path from build output to programmed silicon.

How we Built It

We built FlashBridge as a PlatformIO-based embedded system in VS Code, centered on the Arduino Portenta H7. The Portenta acts as the secure network-facing control plane, while the target ESP32 is managed through UART plus explicit reset and boot-strap control. Firmware images are uploaded in chunks, staged on the Portenta, validated, and then written to the ESP32 through its ROM bootloader flow.

A big part of the build process was intentionally experimenting with a prompt-first workflow. We challenged ourselves to create the project as a fully AI-prompted implementation, with human direction focused on architecture, priorities, testing, and correction rather than hand-writing any of the code. That forced us to become very explicit about requirements, sequencing, and hardware assumptions. In that sense, the project became both an embedded product build and a test of how far AI-assisted engineering can go when paired with someone who understands the real-world use case.

Improvements Made with Codex & GPT-5.6

FlashBridge existed before this collaboration, including its core product idea, hardware architecture, and physical Portenta-to-ESP32 programming workflow. We used Codex and GPT-5.4 to generate at all existing code. Then we used Codex & GPT-5.6 as an implementation partner to enhance that foundation with new features and focused on a more reliable, testable, recoverable and judge-ready system.

How we collaborated: We provided the goals, constraints, hardware knowledge, acceptance criteria, and repeated feedback from real-device testing. Before making changes, Codex inspected the existing C++ firmware, Python uploader, HTTP protocol, build configuration, and documentation. GPT-5.6 helped reason across those components, preserve protocol compatibility, identify failure modes, and translate our requests into implementation steps. Codex then made the repository changes directly, ran tests and end-to-end exercises, diagnosed failures, refined the implementation, synchronized the judge repository, and managed the requested Git workflow including creating the commit messages.

Where Codex accelerated the work:

  • Built a persistent PC-based Portenta simulator that reproduces the existing session, manifest, chunk-upload, resume, flash-progress, and verification protocol without simplifying the real uploader.
  • Created automated success and failure coverage for flashing, corrupted chunks, missing chunks, resume across restarts, invalid manifests, known-session recovery, and failed verification.
  • Strengthened the uploader with connection-loss detection, exact resume commands containing the real session ID, operation timing, completion states, and clear recovery output.
  • Added Windows detection of the Arduino Nano ESP32 COM port and monitoring of its expected disconnect and reappearance during programming.
  • Expanded the judge documentation with simulator instructions, timeout behavior, IP-address discovery, resume and full-erase scenarios, physical-hardware limitations, and reproducible demo commands.
  • Built and maintained export tooling that synchronizes the hardware master with the reduced public judges repository while excluding credentials, local models, caches, and oversized generated files.
  • Helped shape the project title, tagline, elevator pitch, use cases, and the distinction between implemented functionality and planned AES protection.
  • Drafted and refined the submission-video narration, generated synthetic voice assets, integrated timed narration cues into the uploader, and post-processed the final video with fast-forward sections and an opening architecture diagram.

Our key decisions: We selected the problem, boards, wiring, pin mapping, target behavior, network workflow, and requirement to keep the real HTTP protocol unchanged. We decided which recovery behavior judges should see, how resume and verification should be presented, which simulator operations must be clearly labeled, and how the project should be positioned. We also performed the physical wiring, Portenta and Nano ESP32 tests, observed USB behavior, reviewed the user-visible results, and requested refinements until the system behaved as intended.

Final result: Codex & GPT-5.6 contributed the cross-repository analysis, implementation, tests, debugging, documentation support, narration workflow, video processing, synchronization, and Git execution. We validated the result through 22 automated tests, simulator exercises, hash verification, interrupted-upload recovery, and a narrated physical-hardware demonstration.

  • Our review was outcome- and risk-focused rather than a line-by-line inspection of every generated implementation detail.
  • We estimate that we directly reviewed approximately 10% of the code.
    • This is similar to trusting a modern compiler without reviewing all generated assembly code: define the required behavior, test the outputs, investigate failures, and validate the result in its real operating environment.
    • The application code and supporting project files were produced and updated through iterative collaboration with Codex & GPT-5.6.
  • Codex performed all public-facing repository synchronization and Git operations, including creating the commits, writing the commit messages, and preparing the related repository comments.
  • Our only direct file editing was this root README.

Challenges (we ran into)

The hardest part was not generating code. It was managing reality. Embedded systems are full of details that are easy to get wrong: pin mappings, reset polarity, ROM bootloader behavior, target-specific flash layouts, and response formats that are only obvious after real hardware testing. AI can move quickly, but hardware punishes ambiguity.

We also ran into workflow friction on the tooling side. This was only our second serious use of PlatformIO inside VS Code, so part of the project involved learning the environment while building the system. Even basic development momentum took resilience: at one point a failed GitHub Desktop update broke the app entirely but Codex repaired before normal work could continue.

A deeper challenge was learning how to lead the agent well. The best results came when we supplied a clear TODO sequence, documented assumptions, and maintained README files that let the agent "see what we see." That taught us that successful AI-assisted engineering still depends heavily on human task decomposition and operational context.

Accomplishments (that we're proud of)

We are proud that FlashBridge grew from a real observed need into a working hardware-validated system. The desktop computer-to-ESP32 flashing path was not just mocked or simulated; it was brought up on actual hardware and pushed through the kinds of protocol and wiring issues that only show up in practice. Getting 460800 baud across standard wires was amazing.

We are also proud of the discipline behind the process. What began as "maybe this can be prompted in an afternoon" became a much more honest and valuable result: a multi-weekend engineering effort that combined embedded judgment, persistence, and AI leverage. The finished system reflects both practical problem selection and the ability to keep iterating until the silicon actually does what the software claims.

Lessons Learned

We learned that Codex can be an extraordinarily strong programming partner, especially when the work involves broad software knowledge, protocol handling, hashing, validation logic, and iterative refactoring. In many areas, it accelerated implementation far beyond what we could have done alone at the same speed.

We also learned where AI agents still need strong human guidance. Datasheet interpretation, hardware pinout reconciliation, and board-level assumptions still benefit heavily from a human who can cross-check physical reality. More broadly, we learned that AI works best when paired with founder-market fit: someone close to the problem, close to the users, and able to provide the judgment, ordering, and constraints that turn generated code into a dependable product.

The Arduino Nano ESP32 layout places power and ground pins directly opposite the UART pins. Strict adherence to pinout diagrams is required during wiring, as accidental reversal causes catastrophic thermal failure and melted components. The repo root readme shows a photo of a heat-damaged jumper connection discovered during hardware testing: a practical reminder that pinouts, voltage assumptions, and physical wiring must always be verified on the real hardware.

What's Next

The next step is to strengthen FlashBridge from a working prototype into a more production-ready secure programming platform. That includes expanding target support across more ESP32 variants, hardening the encrypted transport and operational safeguards, and improving session orchestration so remote programming jobs are easier to monitor, resume, and audit.

We also want to keep refining the human-plus-AI development workflow behind the project. One of the clearest lessons here is that the right future is not "AI replaces the builder", but "the right builder becomes dramatically more capable with AI." FlashBridge exists because the team understood the user, understood the embedded constraints, and kept steering the system through the messy parts until it worked.

Built With

Share this project:

Updates