When trying to send anything to an opened serial port from a simple .NET/C# application, on most Windows PCs I get the error
Unhandled Exception: System.IO.IOException: The semaphore timeout period has expired.
at System.IO.Ports.InternalResources.WinIOError(Int32 errorCode, String str)
at System.IO.Ports.SerialStream.EndWrite(IAsyncResult asyncResult)
at System.IO.Ports.SerialStream.Write(Byte array, Int32 offset, Int32 count, Int32 timeout)
at System.IO.Ports.SerialPort.Write(String text)
at System.IO.Ports.SerialPort.WriteLine(String text)
at TestSerial.Executer.Go(UInt32 COMPort, UInt32 BaudRate, List`1 Operations)
at TestSerial.Program.Main(String args)
This is using the standard SDK example lpcxpresso54628_dev_composite_cdc_vcom_cdc_vcom_bm with the following single code change in usb_device_config.h:
/*! @brief LPC USB IP3511 FS instance count */
#define USB_DEVICE_CONFIG_LPCIP3511FS (0U)
/*! @brief LPC USB IP3511 HS instance count */
#define USB_DEVICE_CONFIG_LPCIP3511HS (1U)
So instead of the FS port I use the HS port, everything else is 100% the SDK code.
This problem does not happen with native C++ applications or with Python/pyserial which also uses native programming underneath, it only happens with .NET applications using System.IO like my test or Termie from codeproject.
It also doesn't happen with all PCs, but from 4 I tried it happened on 3 of them even though they all use the same standard class USB virtual serial port driver usbser.sys version 10.0.19041.906 from Windows 10.
This doesn't happen with other non-NXP VCOM interfaces like FTDI ones so it must be something specific to the NXP-provided implementation.
Using an LPCXpresso54628 eval board.
Looking around, I found many problems reported using System.IO.Ports.SerialPort class, and in the following post explain the unreliability of this class. Since it works using shells (TeraTerm or putty) and native C++ applications or with Python/pyserial. I think this is only a problem with this .NET implementation.
Thank you for your reply. The issue, on the same PCs using the same code, only shows with the NXP VCOMs, not any other implementations like FTDI or Prolific. In the code, I am not using any of the unreliable methods that the article mentions, only open the port and send a few bytes. The error also shows in this little tool:
So it should be easy to reproduce, just connect to an NXP VCOM (built for HS USB, not FS) and try to send something. As I said three from four PCs showed the problem.