Description
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.