samd: REPL disconnect problems after tinyusb PR #1342
Comments
|
FYI - I am seeing a similar (I think) disconnect on a SAMD21 (CPX) with 4.0.0-alpha.3 dmesg log on Ubuntu 18.04 |
|
same behavior seen on feather_m0_express -- also with 4.0.0-alpha.3 |
notro
changed the title
|
ditto seeing this too - will try to get some beagle traces - im on win 10 |
|
USB trace attached, see packets 43978, thats where it 'hangs', and then 44064 is when it resets and reappears - MSD is back but CDC connection is gone
|
|
FYI, I'm waiting for this PR: hathach/tinyusb#11 Once its in, I'll update CircuitPython to it. |
|
Please try with #1353. I believe it will fix it. |
|
Running many unittest tests through the repl is working again. The script I use to upload, use os.stat() to check if files need uploading. When I rerun the script after it has uploaded it all files, I get into trouble. It consistently fails when stat'ing these files: (I've had 2-3 times out of over a hundred times that one of these succeeded) Fails as in raw repl not responding with It looks like it's starting to write the tuple judging by the opening parentheses. This is how a successful one looks: However if I catch the exception and retry the command through the regular repl mode, it succeeds and the script can continue. I have tried to retry the command through raw repl, and I even tried microcontroller.reset() and serial reconnect without success. I tried changing the contents of the failing files (copy content of another one) and it succeeded. If I try raw repl directly using screen, the failing command succeeds. I've spent hours trying to make something that can easily reproduce this, but I haven't been successful at that. Reverting to before tinyusb makes it work. |
|
There is a ring buffer on the CDC output that could be filling up. Is that all allocated as one string and printed? |
|
That string was a combination of read and write (ie. the session): |
|
@notro Is this still an issue? |
|
I still have the above mentioned problem. Additionally I have this: Test script: import serial
import sys
import time
port = sys.argv[1]
print('port:', port)
version = sys.argv[2]
cmd = b'__import__("os").uname()\r\n'
print('cmd:', repr(cmd))
print()
CHAR_CTRL_A = b'\x01'
CHAR_CTRL_B = b'\x02'
CHAR_CTRL_C = b'\x03'
CHAR_CTRL_D = b'\x04'
with serial.Serial(port, baudrate=115200) as ser:
# Reset REPL
ser.write(CHAR_CTRL_C)
ser.write(CHAR_CTRL_C)
time.sleep(0.5)
ser.write(CHAR_CTRL_B)
time.sleep(0.5)
discard = ser.read(ser.inWaiting())
#print('discard', discard)
# Enter Raw REPL
ser.write(CHAR_CTRL_A)
ser.write(b'res = ' + cmd + b'\r\n')
if int(version) == 1:
ser.write(b'print(res)\r\n')
else:
ser.write(b"print('BEGINMARKER>' + repr(res) + '<ENDMARKER')\r\n")
# Execute the code that has been entered
ser.write(CHAR_CTRL_D)
time.sleep(2) # The real code spins looking for the 0x04 byte separator
out = ser.read(ser.inWaiting())
print('out:', out)
_, res = out.split(b'OK')
print('res:', res)
output, error, prompt = res.split(b'\x04')
print('output:', output)
I use markers to know what result I should return from a remote function call. The reason for doing this is so I can use print statements in the function. This is the output without the markers: This is the failing output with the markers: I don't get the full output. Maybe there's a buffer that's not flushed... It's fine in the ordinary REPL: |
|
That uname example is working now, turned out I had a 14 days old checkout. I still have this problem: #1342 (comment) |
|
@notro Thank you for the update! Because its hard to reproduce and likely timing related I'd like to punt this to future versions. I think it'll be a large task now. Any related bugs/behavior make it easier to debug. |
|
I'm sure you've seen the notifications but this is worth a re-test after the fix hathach/tinyusb#260 for #1639 is picked up by CircuitPython. |
|
I haven't seen any issues recently. I suspect it's been fixed. |
PR #1321 has caused problems with uploading files over the serial REPL.
Using latest master:
I'm unable to put a 460k file using ampy:
Kernel log:
Nothing special on the LEDs. With another tool I use for upload that checks the file timestamp before uploading, I sometimes get a new device name ttyACM2 after the usb reset:
Zero size file (since it's not closed I suppose):
Working commit
Checkout commit beofre tinyusb PR:
Did this 3 times without failure:
ampy get(doesn't support binary files?) didn't work so I couldn't check that the files are equal, but at least the size matches:The text was updated successfully, but these errors were encountered: