rp2040, rp2350: board stops responding after tinygo flash and ignores the 1200 bps reset #6036

Symptom

On the Pico 2 W, Pico 2 and Pico, a board sometimes stops working after tinygo flash. On the RP2350 boards it still enumerates as the TinyGo USB device, but it sends no serial output and ignores the 1200 bps reset, so the next tinygo flash fails with unable to locate any volume: [RP2350]. Holding BOOTSEL and replugging recovers it. On the RP2040 it once disappeared from USB completely, with no RPI-RP2 drive either.

This is on one Apple silicon MacBook, with two different USB-A to USB-C adapters. TinyGo is dev at a0798af built with LLVM 23. I have not tried another computer or a Linux host, so I do not know if TinyGo, macOS or the boards are at fault.

How to reproduce

Use qbs from #6037 on a Pico 2 W. It flashes four small programs in turn and checks their serial output. Run it in a loop until it stops finding the board:

while go run ./tools/qbs -target pico2-w; do :; done

Each time I tried, a board failed within 1 to 6 runs, on all three boards. An Arduino Uno R4 WiFi passed the one full run I did.

Probably ruled out

• The pico2-w target. Its image is byte identical to pico2.
• The two recent USB serial commits 83ce7e3 and fed7ac0. It still failed with both reverted.
• DTR and RTS on the host. Toggling them on a stuck board did nothing.
• Stale EP0 state after a bus reset. A change that clears it did not help.
• Idle time before the reset, and USB selective suspend. Cycles with gaps of 0.5 s and 10 s did not fail.
• How tinygo flash is called, and the host serial library. Python and Go hosts both failed, and so did runs that did and did not pass -port.
• The adapter and cable.

More than 150 flashes of images that only printed a banner never failed when tinygo flash found the port itself. I do not know what the test programs do differently.