Open maloo opened 5 years ago
I dug a bit deeper and think the error reported back from Windows could be a compatibility issue between usbser.sys host driver and Linux Gadget (2.4 in this case) device driver. Linux kernel src/docs indicate that driver will stall if RTS function is received. But my last conclusion still stands. It must be possible to skip sending RTS function when using the .Net SerialPort class w/o flow control enabled.
BTW, same C# code works fine on same machine using WSL Ubuntu 18.04 and .Net Core 3.0 which just added SerialPort support.
Do you want to propose a PR?
Any update on this issue? I'm still having this problem with the nuget System.IO.Ports 6.0.0.0.-rc.2.2.
I am getting A device attached to the system is not functioning
error for a barcode reader which using GigaDevice GD32 MCU.
Unix version of SerialStream is fixed by https://github.com/dotnet/runtime/pull/48577. @sleeuwen asked to change Windows version too but did not get a response. @sleeuwen, since you made the changes for Unix version, can you create another PR for Windows version? If you want me to create a PR with exact same changes please let me know
@danmoseley I can create a PR based on https://github.com/dotnet/runtime/pull/48577
Some USB serial port drivers does not support the EscapeCommFunction call made indirectly in SerialPort.Open at https://github.com/dotnet/corefx/blob/master/src/System.IO.Ports/src/System/IO/Ports/SerialStream.Windows.cs#L223. These drivers don't use/support RTS/DTR so SerialPort.DtsEnable should always be false. SerialPort.Open always sets DtrEnable. This will trigger a DCB change with DTR_CONTROL_DISABLE (which succeeds). But this call is always followed by the EscapeCommFunction(DtsEnable ? SETDTR : CLRDTR) call which fails and triggers an IOException with error code 0x1f. I propose that you don't call EscapeCommFunction when you already disabled this function using the DCB just above. Or at least allow this behavior to be overridden so SerialPort can be used with all USB serial port drivers. Using WSL cu, Win32 or other terminal programs works just fine with these drivers. It is only .Net SerialPort that can't handle this and throws an exception in this non fatal error case.