search

Fazecast / jSerialComm

Platform-independent serial port access for Java
GNU Lesser General Public License v3.0
1.34k stars 287 forks source link

Getting LISTENING_EVENT_DATA_WRITTEN sometime after having writeBytes() returning 0 #536

Closed EmbGangsta closed 8 months ago

EmbGangsta commented 11 months ago

I am using the latest 2.10.4 driver version under Windows with JVM 1.8.0_231

I did different experiments to send data to a device using a virtual com port over USB.

1) Case with TX BLOCKING mode with write timeout set to 3s:

In this case I can use the serial listener event but I notice that at some moment I get the SerialPort.LISTENING_EVENT_DATA_WRITTEN event whereas the writeBytes() function reported a return of 0 ... BTW, I dont see in the event listener for the SerialPort.LISTENING_EVENT_DATA_WRITTEN the way to know the amount of written bytes ... Anyway I can notice a discrepancy between the fact that we have writeBytes() function returning 0 but with the presence of LISTENING_EVENT_DATA_WRITTEN .... And I can see then that I have the famous last error code 121 which is the TX SEMAPHORE TIMEOUT issue

So if I use the writeBytes() return or the LISTENING_EVENT_DATA_WRITTEN event I end up with this error ...

However it's strange because I was able to take a Wireshark trace on USB and I can see that data is really sent !! So I don't understand why the driver is messed...

2) Case with no TX timeout set, no blocking mode at all

In this case, I have never the LISTENING_EVENT_DATA_WRITTEN occuring when serial port seems to no longer able to send requested data payload.

I did a wireshark capture and I DO SEE THE PAYLOAD DATA SENT OVER USB !! However it seems something serial connection is messed some seconds after, but no error reported at all ...

hedgecrw commented 11 months ago

I have a feeling this is an issue with either the underlying device driver or the device/converter itself.

What you are seeing in Case 1 (using write timeouts) is essentially: We are making a request to the serial driver to write some amount of data, and at some point (before the timeout occurs), the driver is reporting that it has successfully written 0 bytes (which is why you are also receiving a LISTENING_EVENT_DATA_WRITTEN callback...the driver thinks it has successfully written something, but it is considering writing 0 bytes a success for some reason).

Since it sounds like you are seeing the same behavior using JSSC (from Issue #530), I think this is an OS or driver problem that we can't address in a user library.

EmbGangsta commented 11 months ago

Thanks. And this behavior is strange due to the fact the data can be seen in the PCAP trace I did with wireshark and USBNPCAP tool....

For your remark in other #530 ticket, indeed it seems that this error is never occuring (or maybe very rarely, I didnt make statistics...) if I send more little packets than bigger ones. I will try to split the data in more little packets and see the behavior.

hedgecrw commented 11 months ago

Good idea, and if this truly is a driver problem (and you can't switch whatever USB-to-serial converter you are using), it might even be necessary to implement some sort flow control or ACK functionality at the application level (i.e., send X bytes, then wait for an ACK response before sending more).

hedgecrw commented 8 months ago

Closing as "nothing to fix/underlying driver problem"