V1.3 dual-MCU board

The PC only ever talks to the ESP32. Anything for ports C or D is proxied over the SPI link, and results come back tagged with the port letter so a host does not need to know which MCU owns a port. The field-control engine for C/D runs on the RP2350 itself; the ESP32 forwards the engage/state commands and polls status.

Legacy ports use IO47 (ENABLE/DISABLE) and IO48 (DRIVER/AUT), shared across all four RJ11s, with the same polarity as revision 1.1. The RP2350's QSPI_SS/BOOTSEL and USB pins are unconnected, so its USB mass-storage bootloader is unreachable: SWD from the ESP32 is the only programming path.

Open the V1.3 flasher in Chrome or Edge, connect the board over USB, and run the two steps in order.

1. ESP32-S3. esptool-js writes the merged image (bootloader + partition table + app) at 0x0, exactly as on the standard flasher. The board reboots into the new firmware and answers get_info with a bu_hello event. About 30 seconds.
2. RP2350. The browser never touches SWD: it streams the image to the ESP32 as base64 JSON commands over the live serial link, and the ESP32 does the programming. The flasher releases RUN, probes SWD, erases, writes 384-byte chunks (each acknowledged before the next is sent), then reboots the RP2350 into the new image. About 10 seconds for a 53 KB image.

Afterwards, SPI ping on the flasher (or the RP2350 panel of the bring-up console) should report the RP2350 answering. Ports C and D do nothing until it does.

Step 2 is only enabled once the connected board has identified itself with bu_hello. A board still running production firmware ignores the rp2350_* commands, which is why the ESP32 must be flashed first.

The same sequence is available as a Python tool in the repository (needs pyserial). Build both images with PlatformIO first.

cd esp32  && pio run -t upload          # ESP32-S3 over the CH340
cd ../rp2350 && pio run                  # produces .pio/build/rpipico2/firmware.bin
cd ..
py tools/bringup_cli.py --port COM3 flash-rp2350 rp2350/.pio/build/rpipico2/firmware.bin
py tools/bringup_cli.py --port COM3 cmd '{"cmd":"rp2350_spi","op":"ping"}'

tools/publish_firmware.py merges the ESP32 image, copies the RP2350 image into public/firmware/ and prints the v13_releases manifest entry the web flasher reads.

Four bring-up commands carry the RP2350 image. All replies are bu_flash_status events with a stage field; wait for each reply before sending the next command.

On failure ok is false and fail names the stage that failed (e.g. halt, reset_halt, no_session, bad_b64). The ESP32 bit-bangs SWD, staying under the ~250 kHz ceiling that applies while a blank RP2350 waits in its bootrom.

send({cmd:'rp2350_ctrl', run:true});            // out of reset
await reply('bu_swd_probe');                    // expect ok:true
send({cmd:'rp2350_flash_begin', size: image.length});
await reply('bu_flash_status', 'begin');
for (let off = 0; off < image.length; off += 384) {
  send({cmd:'rp2350_flash_data', b64: base64(image.subarray(off, off + 384))});
  await reply('bu_flash_status', 'data');       // ok:true, received
}
send({cmd:'rp2350_flash_end'});
await reply('bu_flash_status', 'end');          // ok:true, received === image.length

Fixed 37-byte frames in both directions (4-byte header, 32-byte payload, 8-bit sum checksum), 1 MHz, SPI mode 1 (CPOL=0, CPHA=1). The ESP32 is always master; because the slave cannot push a reply, every command is followed by a GET_RESULT poll, repeated while the status byte is PENDING (the RP2350_IRQ line rising means a result is ready).

Commands over the link: PING, RS485_RAW (send bytes / passive listen on C or D), LINKTEST (Smart-port handshake), FIELD_SET and FIELD_STATUS (engage/state and per-port link/ack counters). From the PC these are reached through {"cmd":"rp2350_spi","op":…}; the field-control commands fan out to A/B on the ESP32 and C/D on the RP2350 automatically.