A board whose callback floods the REPL leaves exec and ls waiting with no explanation #193

On an ESP32-S3 that only has its native USB for serial (LilyGO T-Embed), a periodic machine.Timer whose callback prints on every tick, with no way to stop itself, leaves mpftp exec and mpftp ls waiting. In our run exec was still going after 77 s, hard-reset hung, and a plain serial read still showed the board's output scrolling, which looks like a working port. Ctrl-C, Ctrl-D and a WebREPL session could not get a line through, and the host cannot reset a native-USB S3 (DTR/RTS reach nothing), so the board needed its RESET button.

Steps

# on the board
import machine
t = machine.Timer(3)
t.init(period=3, callback=lambda t: print("tick tick tick tick tick tick tick"))

Then mpftp ls -d COM5 / and mpftp exec -d COM5 "print(1)".

What we saw

• A flood that ends by itself (the callback deinits the timer after a few thousand ticks) is handled: ls and exec finish in about 4 s.
• A flood that never ends is not. Reading the port works, so the board looks alive; the REPL never answers. mpftp neither returns the "board is stuck in a callback" advice that it gives for an unopenable port nor times out in a bounded time.

What would help

Give the connect path an overall deadline that applies even while bytes keep arriving (mpremote's timeout is between bytes, so continuous output defeats it), and when it expires say the board is printing continuously and does not answer, and that a native-USB board needs its RESET button.