Issue with USB->Serial on Duet 3 Mini 5+
-
@RYANPDX Re my last point: It's actually a flaw in the Linux kernel that causes start-up messages to be echoed back to the Duet. In detail, the
cdc_acm
module enables TTY + echo modes by default for all ACM/serial devices and you have no way to disable this behaviour unless you recompile the Linux kernel (see here for further details).I have not had any issues with the USB console actually hanging up my system. Please confirm if the problem persists with RRF v3.4.4.
-
@dc42 said in Issue with USB->Serial on Duet 3 Mini 5+:
As all Duet boards using a genuine USB device interface (not a USB-to-serial converter as many older 3D printer control boards did), flow control is intrinsic to the channel and the virtual RTS/CTR/DSR/DTR signals serve no purpose.
Very good information, thank you!
@dc42 said in Issue with USB->Serial on Duet 3 Mini 5+:
Please also confirm that you have tried this with more than one Duet 3 Mini board, to rule out a hardware issue with a particular board.
I have confirmed this on three separate boards. I have not yet tested with my 6HC boards but will try and squeeze that in soon. (I don't expect there to be a problem on the 6HC, as we use them in this same configuration.)
@dc42 said in Issue with USB->Serial on Duet 3 Mini 5+:
against mains ground noise causing problems
Confirmed there are no ground loops or leakages.
@chrishamm said in Issue with USB->Serial on Duet 3 Mini 5+:
Please make sure your Duet is on the latest RepRapFirmware version 3.4.4.
I reproduced the issue on both 3.3 and 3.4.4.
@chrishamm said in Issue with USB->Serial on Duet 3 Mini 5+:
Setting the USB baud rate in config.g isn't needed. It is overridden by tio anyway when you launch it (and probably by potential Python scripts, too). If you want to use a different baud rate. use the -b option instead (defaults to 115200 in tio).
Took that out of my configuration, I think it was one of those desperation measures where I was throwing everything at the wall to see what stuck.
@chrishamm said in Issue with USB->Serial on Duet 3 Mini 5+:
To get proper line outputs in tio, use the INLCRNL mode: tio -e -m INLCRNL /dev/ttyACM0.
@chrishamm said in Issue with USB->Serial on Duet 3 Mini 5+:
you have no way to disable this behaviour unless you recompile the Linux kernel (see here for further details).
@chrishamm said in Issue with USB->Serial on Duet 3 Mini 5+:
Please confirm if the problem persists with RRF v3.4.4.
Confirmed in 3.4.4
-
@chrishamm said in Issue with USB->Serial on Duet 3 Mini 5+:
(see here for further details
Any idea if it would be possible to hack in the USB-IDs of a device with the DISABLE_ECHO flag already in it? Or should I start looking at recompiling with the hack in the driver side?
-
@RYANPDX The easiest way to work-around it would be to open the TTY and to discard all the stuff that's echoed back at first (possibly after the first NL). If you want to have this solved for good, you'll have to modify the cdc_acm driver for our USB IDs (VID 0x1d50, PIDs 0x60ec - 0x60ef) and submit a PR to the Linux kernel to exclude them from TTY mode (aka DISABLE_ECHO) by default. TBH I don't understand why the cdc_acm module doesn't offer any params for this anyway.
-
@RYANPDX Regarding the USB hang issue, I'd really like to reproduce and fix it, but I've been unable to provoke the same problem on a Raspberry Pi 4B. Can you tell me more about the machine running Debian 11?
PS: I just managed to reproduce it, I am looking into it.
-
@chrishamm I do not believe we have this same issue on the Duet 3 6HC boards, only the Mini 5+. Would it be useful to you for me to double-check that assumption?
-
@RYANPDX yes it woud be useful.
-
@RYANPDX I'm happy to report that I've got a fix for both problems ready. With my latest version no more messages are written to USB before the device is actually opened and the reboot problem is fixed, too.
The MB6HC does not seem to be affected from either problem.
-
@chrishamm said in Issue with USB->Serial on Duet 3 Mini 5+:
I'm happy to report that I've got a fix for both problems ready. With my latest version no more messages are written to USB before the device is actually opened and the reboot problem is fixed, too.
Amazing news! Sorry for the delay between responses as always, I'm very appreciative!
@chrishamm do you have an expected release date? Or is there any way I could get my hands on it a bit early?
-
@RYANPDX You can try out 3.5-b1 to get this fix. I don't know yet when we will release 3.4.6.