Ctrl+A followed by Ctrl+C gets serial input stuck since 1.17
OS: Ubuntu 20.04
Device: RPi Pico
main.py:
from machine import Pin
from time import sleep
led = Pin(25, Pin.OUT)
n = 0
while True:
led.toggle()
print("13 x {} = {}".format(n, 13*n)) # print the thirteen-times table
n = n+1
sleep(0.5)
With MicroPython 1.17, when I plug this device in, connect with tio and press Ctrl+C, then it successfully interrupts and gives me normal prompt. When I, instead, first press Ctrl+A and then Ctrl+C, then nothing happens and the input kind of gets stuck (if I do it via pyserial, then the write method blocks). Same happens when I press Ctrl+D and then Ctrl+C.
Sometimes I get out of this situation by hard-resetting Pico, but sometimes even this doesn't help and I need to either restart my computer or reset USB.
When I go back to 1.16, then this problem disappears.
This issue is relevant for Thonny IDE, because upon connecting a device, it sends Ctrl+A to probe whether the device is already idle at prompt or a process is running.
stm32: Repeated ctrl-c sequence hard crashes pyboard
came up during development of #1713 but seems to be an independant issue.
The following let the pyboard hard-crash after app. 100 tries (ca.10sec) on the current master.
#!/usr/bin/env python
import time
import serial
write_test_script = """
import pyb
while (1):
pyb.LED(3).toggle()
"""
def drain_input(ser):
time.sleep(0.1)
while ser.inWaiting() > 0:
print('drain:', ser.read(ser.inWaiting())[:20])
port = """/dev/cu.usbmodem1452"""
def main():
dev = serial.Serial(port, baudrate=4000000)
print("starting")
for i in range(0,10000):
print("try {}".format(i))
dev.write(b'\x03\x03\x01\x04') # break, break, raw-repl, soft-reboot
drain_input(dev)
dev.write(bytes(write_test_script.encode('ascii')))
dev.write(b'\x04') # eof
dev.flush()
if __name__ == "__main__":
main()
@dhylands proposed in #1713 that it could be caused if
..if an interrupt to process Control-C happens between gc_init and pyb_usb_dev_init0 the interrupt
handler will be referencing uninitialized data (most likely previously initialized data). However, since that
early initialization always happens in the same order it seems likely that the exception object will get
allocated at the same location each time (having the object get trampled by something else is usually
what causes the serious issues).
I'm not sure if a simple flag can be used to signal if a reset/startup is pending. So the ctrl-c sequence is only executed if the pyboard has finished booting up.