The REPL advertises raw-paste mode and then aborts partway through the transfer. Plain raw REPL with the same payload works every time, so this is specific to the paste path.
Reproduction
- Send
\x01. Board answers raw REPL; CTRL-B to exit\r\n>.
- Send
b"\x05A\x01" (raw-paste request).
- Board answers
b"R\x01" followed by a 2-byte little-endian window size of 128, i.e. it accepts raw-paste.
- Drive the standard mpremote window/credit loop: send up to the credit, then block for
\x01 credit bytes.
- Partway through a ~460 byte payload the board sends
\x04, aborting the transfer.
The same payload over plain raw REPL (\x01, 32-byte chunks, \x04, wait for OK) succeeds every time. Same link, same payload, same session.
Why it matters more than it looks
The failure does not present as a transfer error. The truncated text reaches the parser and surfaces as a SyntaxError on a plausible line number, which reads like a bug in the code being sent. This cost real debugging time before the cause was identified.
tools/ble-test/repl.py in this repo also truncates long pastes at its own documented-as-reliable 24 byte / 120 ms chunking, producing the same misleading SyntaxError. A raw-REPL runner was written to work around it.
Not yet captured
The byte offset at which the abort lands. The diagnostic exists but every run after it was added used the plain-REPL fallback, so it never printed. One non-destructive REPL session would get it, and it would say whether the abort is at a fixed offset, at a window boundary, or dependent on payload content.
Environment
silabs_siwx917_dk2605a, CircuitPython 10.3.0-alpha.4-71-gfebc5115c1, REPL over the J-Link VCOM at 115200. Not known whether this is board-specific or affects the zephyr-cp port generally; nobody has tried another board.
The REPL advertises raw-paste mode and then aborts partway through the transfer. Plain raw REPL with the same payload works every time, so this is specific to the paste path.
Reproduction
\x01. Board answersraw REPL; CTRL-B to exit\r\n>.b"\x05A\x01"(raw-paste request).b"R\x01"followed by a 2-byte little-endian window size of 128, i.e. it accepts raw-paste.\x01credit bytes.\x04, aborting the transfer.The same payload over plain raw REPL (
\x01, 32-byte chunks,\x04, wait forOK) succeeds every time. Same link, same payload, same session.Why it matters more than it looks
The failure does not present as a transfer error. The truncated text reaches the parser and surfaces as a
SyntaxErroron a plausible line number, which reads like a bug in the code being sent. This cost real debugging time before the cause was identified.tools/ble-test/repl.pyin this repo also truncates long pastes at its own documented-as-reliable 24 byte / 120 ms chunking, producing the same misleadingSyntaxError. A raw-REPL runner was written to work around it.Not yet captured
The byte offset at which the abort lands. The diagnostic exists but every run after it was added used the plain-REPL fallback, so it never printed. One non-destructive REPL session would get it, and it would say whether the abort is at a fixed offset, at a window boundary, or dependent on payload content.
Environment
silabs_siwx917_dk2605a, CircuitPython 10.3.0-alpha.4-71-gfebc5115c1, REPL over the J-Link VCOM at 115200. Not known whether this is board-specific or affects the zephyr-cp port generally; nobody has tried another board.