RP2040 and Mu Editor cause Ctrl-C hang-ups

[Kriechi]

CircuitPython version

Adafruit CircuitPython 7.3.3 on 2022-08-29; Raspberry Pi Pico with rp2040
Board ID:raspberry_pi_pico

Code/REPL

import time
print("Hello World!")

while True:
    print("foobar" * 50)
    time.sleep(1)

Behavior

Code runs and prints messages once per second as expected.

• open the Mu Editor
• set it to CircuitPython Mode
• open the Serial panel
• wait a few seconds for a few messages to appear
• click around between the Serial panel and the code editor above
• try to interrupt code execution by pressing Ctrl-C multiple times
• observe that nothing happens
• after pressing 5+ times, the macOS kernel task will eat up 100% CPU.

Interrupting the code execution is not possible in this state. I have to reset the board to bring it back. Even a soft-reload via auto-reload on USB file saving does not fix the input problem: it does reload and restart executing, but Ctrl-C is still not recognized.

Description

It is 100% reproducible for me with the Mu Editor only.

Mu Editor logs:

Starting Mu 1.1.1
2022-11-09 11:02:10,230 - root:270(run) INFO: uname_result(system='Darwin', node='147ddaa50b43.ant.amazon.com', release='21.6.0', version='Darwin Kernel Version 21.6.0: Thu Sep 29 20:12:57 PDT 2022; root:xnu-8020.240.7~1/RELEASE_X86_64', machine='x86_64', processor='i386')
2022-11-09 11:02:10,252 - root:271(run) INFO: Platform: macOS-10.16-x86_64-i386-64bit
...
2022-11-09 11:02:12,690 - mu.logic:1549(change_mode) INFO: Workspace directory: /Volumes/CIRCUITPY
2022-11-09 11:02:12,785 - mu.logic:962(restore_session) INFO: Starting with blank file.
2022-11-09 11:02:13,561 - mu.logic:747(check_usb) INFO: circuitpython device connected on port: /dev/cu.usbmodem14301(VID: 0x239A, PID: 0x80F4, manufacturer: 'Raspberry Pi')
2022-11-09 11:02:19,350 - mu.modes.base:112(open) INFO: Connecting to REPL on port: /dev/cu.usbmodem14301
2022-11-09 11:02:19,362 - mu.modes.base:130(open) INFO: Connected to REPL on port: /dev/cu.usbmodem14301
2022-11-09 11:02:19,373 - mu.modes.base:503(add_repl) INFO: Started REPL on port: /dev/cu.usbmodem14301
2022-11-09 11:02:19,374 - mu.modes.base:474(toggle_repl) INFO: Toggle REPL on.
2022-11-09 11:03:25,183 - mu.modes.base:136(close) INFO: Closing connection to REPL on port: /dev/cu.usbmodem14301
2022-11-09 11:03:25,189 - mu.modes.base:471(toggle_repl) INFO: Toggle REPL off.

related bug reports that keep getting closed or pointed to some other component:
mu-editor/mu#1505

and other similar ones:
mu-editor/mu#842
https://forums.adafruit.com/viewtopic.php?f=60&t=151826
micropython#7867
micropython#7996
micropython@5873390

Additional information

No response

[dhalbert]

This might be due to escape-code handling. @Neradoc notes here: mu-editor/mu#1505 (comment) that

serial_port = "/dev/cu.usbmodem144443131"
import serial
VT100_RIGHT = b"\x1B[C"
channel = serial.Serial(serial_port)
channel.write(VT100_RIGHT*50)
channel.close()

causes the issue.

[jepler]

I don't think it has to do with escape codes. After pasting "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" to my terminal program, ctrl-c doesn't work either. I suspect an internal serial buffer fills and that prevents ctrl-c from being received..

[jepler]

@hathach can you comment here? We are using tud_cdc_set_wanted_char(CHAR_CTRL_C); and depending that we'll see a call from tud_cdc_rx_wanted_cb. However, when a lot of characters have gone un-read, the wanted CB is no longer called. Is this a TinyUSB bug or do we need to change what we do in CircuitPython (for instance, to do something to drain the un-read characters even if the Python code isn't reading anything)?

[jepler]

@tannewt @dhalbert and I discussed this and we feel that there's no way we can make ctrl-c work -- if we potentially throw away characters from the buffer, it will break things that rely on reliable buffers like file uploads in mu and thonny. But if we don't throw away characters, the "ctrl-c" method can't work, because the ctrl-c character never leaves the host computer.

We might be able to add an alternative out of band interrupt signal such as using DTR or BREAK, which would then have to be added to advanced editors.
TinyUSB seems to have a "send break" callback. I'm interested, know how to send break from tio so I'll look into it.

[jepler]

as another alternative, maybe we could discard any pending characters when USB CDC disconnects.

[tannewt]

Here are the TinyUSB callback APIs: https://github.com/hathach/tinyusb/blob/73896a3b71c525a3ee4cefa7e35ce3b3a93786ef/src/class/cdc/cdc_device.h#L141-L148

[hathach]

@jepler I am late for the party, from what I could understand, Ctrl-C isn't sent to tinyusb since the rx buffer is already full !! If it is the case then indeed, we couldn't resolve this without dropping characters unless as you mentioned we use an additional channel such as modem/control signal. Let me know which modem signal that you plan to use and isn't supported yet by tinyusb, BREAK seems to be a great choice.

[dhalbert]

Break now needs to be implemented in Mu and other REPL terminals.

[Kriechi]

@dhalbert I assume you are referring to this PR?

While this sounds like an improvement - the "unexpected behaviour" for users still is not fixed - until everybody learns about this new break control signal and all terminals implement it.

What would happen if the input buffer gets flushed, or discards just enough data to at least receive one Ctrl-C signal / 0x03 character from the user? Do we have such fine-grained control over the buffer? and would discarding data, i.e., prioritising the well-known Ctrl-C input over any other user (ascii) input from the input buffer be more or less surprising to the user?