NeuronRobotics / nrjavaserial

A Java Serial Port system. This is a fork of the RXTX project that uses in jar loading of the native code.
Other
345 stars 143 forks source link

Error 0x1 at src/windows/termios.c(512 or 2725): Fonction incorrecte. #75

Closed pseudo555 closed 4 years ago

pseudo555 commented 8 years ago

Hello,

I'm using version 3.11.0 to create a java program which talk through a serial port. When my computer goes to sleep with an open connection, i have a lot of times the same errors in the console: Error 0x1 at src/windows/termios.c(512): Fonction incorrecte. Error 0x1 at src/windows/termios.c(2725): Fonction incorrecte.

which seems to be something like that one : http://marc.info/?l=rxtx&m=125310032820956&w=2

I use the following code to get all present serial port: public List getAllAvailablePorts() { final List res = new ArrayList<>(); final Enumeration portEnum = CommPortIdentifier.getPortIdentifiers(); while (portEnum.hasMoreElements()) { final CommPortIdentifier portIdentifier = portEnum.nextElement(); if (portIdentifier.getPortType() == CommPortIdentifier.PORT_SERIAL) { res.add(portIdentifier); } } return res; }

And this code for the connection: final CommPort commPort = selectedPortIdentifier.open("TrBusValidationPanel", TIMEOUT); // 50 ms //the CommPort object can be casted to a SerialPort object serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(38400, 8, 1, 0); // 8 data bit, 1 stop, no parity @ 38400

After I just wait for my computer to go to sleep and I wake it up from standby.

madhephaestus commented 8 years ago

This error is an issue in the driver for your USB to serial device. On hibernate and resume, it seems to be re-registering itself with the kernel, invalidating the file handles that had been created before the hibernate. Generally speaking, hibernate disconnects hardware, and the serial port you are trying to talk to is hardware, so it will not be there when you resume.

pseudo555 commented 8 years ago

Thank's for your fast diagnostic.

I have a real serial port on my computer (dell precision t1650) but i don't know if it is managed as usb one or not by windows (7 64bit): http://i.dell.com/sites/doccontent/shared-content/data-sheets/en/Documents/Dell_Precision_T1650_Spec_Sheet.pdf

So is there a workaround at least to know when the connection is lost ?

madhephaestus commented 8 years ago

is an exception being raised at any point? I have an exception-disconnect-reconnect loop in my user code to deal with hardware losses, but since its is not behavior that can be considered standard, there cant really be a library level strategy for "dealing with it" because one person might need it to disconnect, and another might need reconnect features, and there is not "correct".

pseudo555 commented 8 years ago

No, nothing except these lines: Error 0x1 at src/windows/termios.c(512): Fonction incorrecte. Error 0x1 at src/windows/termios.c(2725): Fonction incorrecte.

I wonder if a listener exists and can be used as notifier to let the developper deals with such case.

madhephaestus commented 8 years ago

in that email thread you linked they were talking about adding something like hat, but i do not think it ever got implemented. I'd gladly take a pr with it added if you feel like diving in and fixing the issue.

EdGruberman commented 6 years ago

I'm using Windows 10 x64 and I have a similar problem in that when a USB device is physically disconnected while I am connected to the port I get the following spam in my console: Error 0x16 at src/windows/termios.c(512): The device does not recognize the com Error 0x16 at src/windows/termios.c(2725): The device does not recognize the co

I don't really understand the native library code, but it seems like there should be some way to send up any error to the SerialEventListener as an exception. notifyOnError?

We need some way to react to an unknown error appropriately.

I suppose this comment is simply my encouragement for something to be done here.

madhephaestus commented 4 years ago

assuming fixed in 3.19.0

mvalla commented 4 years ago

Same here. I use serialEvent(...). I'm using Windows 10 x64. When a USB device is physically disconnected while I am connected to the port I get the following spam repeated continuously in my console:

Error 0x5 at src/windows/termios.c(2725): Access is denied.
Error 0x5 at src/windows/termios.c(512): Access is denied.

Apparently I do not receive any other event or exception. This happens using 3.15.0, 3.19.0, 3.21.0 or 4.2.0

madhephaestus commented 4 years ago

Normally i wrap the access to the input stream in a try catch, and disconnect when an exception is raised by the read. This disconnects the device and closes the connection thread. Can you try that and see if it resolves this issue?

mvalla commented 4 years ago

I receive asynch messages from a USB stick, so my code looks like:

@Override
    public void serialEvent(SerialPortEvent event) {
        if (event.getEventType() == SerialPortEvent.DATA_AVAILABLE) {
            try {
                [...]
                       chint = inputStream.read();
            } catch (IOException e) {
                logger.debug("Unable to read: {}", e.getMessage());
                System.exit(-1);
            [...]

but if I disconnect the USB sitck, i start receiving the garbage on console and no debug line is printed and the application keeps running. So since I perform the read() only after a DATA_AVAILABLE event, if I am not reading at the same time when the USB gets disconnected, then I have no way understand it was disconnected. Any other hint/idea?

mvalla commented 4 years ago

my problem seems related to this: https://github.com/NeuronRobotics/nrjavaserial/issues/143#issuecomment-511378663

madhephaestus commented 4 years ago

Well this got me curious as to why the monitor thread stays around when the device is removed. I looked into it and oh-dear-god that C code still has "goto"s all throughout it...

I added a check for the hardware existence into the monitor thread and it should bail out when the hardware is disconnected. This has been a bug since i took over the library in 2009.

I created a new branch to test this fix, since it has the potential to be destabilizing.

madhephaestus commented 4 years ago

I put some pre-release jars up here: https://github.com/NeuronRobotics/nrjavaserial/releases/tag/5.0.3-prerelease can you use them to test the fix?

madhephaestus commented 4 years ago

Use the https://github.com/NeuronRobotics/nrjavaserial/releases/tag/5.0.3-prerelease nrjavaserial-5.0.3-pre.jar and this code example:

https://github.com/NeuronRobotics/nrjavaserial/blob/issue75-serialEventExitsOnHardwareLoss/test/src/test/ReadTest.java#L39

to detect when the hardware is disconnected.

mvalla commented 4 years ago

I put some pre-release jars up here: https://github.com/NeuronRobotics/nrjavaserial/releases/tag/5.0.3-prerelease can you use them to test the fix?

It works: no garbage output anymore and the new event is detected correctly. I have not tested extensively.

What is the difference between major releases 5.x, 4.x and 3.x btw ? I searched for a description or rel notes but could not find them.

Is it possible to port this bugfix to the 3.x branch?

madhephaestus commented 4 years ago

4.x was a java 11 compiled branch, 5.x merges the changes of the java11 branch into the mainline and compiles it against java 8 for backwards compatibility.

I am kinda excited, this is the first new feature added to RXTX in 11 years! it also happens to fix a 15 year old bug, present in the library since USB to serial adapters were invented. The original developers never imagined the event of removing hardware, because back then Serial ports were built into the processor and could never be removed or added.

This feature will now add a user level event when the hardware is removed. The user can then perform a shutdown procedure, since a connection will be needed after the hardware is removed.

This also causes the Monitor thread that used to become a zombie to die properly.

172 will be merged in and the native libraries will all need to be recompiled against the new C source.