search

Fazecast / jSerialComm

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

USB enumeration issue? #393

Closed michieltjampens closed 2 years ago

michieltjampens commented 2 years ago

Since 2.8.0 (tested it with 2.7.0, 2.8.x), when I run 

StringJoiner response = new StringJoiner(eol);
for( SerialPort p : SerialPort.getCommPorts())
      response.add(p.getSystemPortName()); // this line causes it

Multiple times in a row at a random interval it messes up the usb devices... the usb serial disappears, windows makes a lot of noises of disconnected/connected usb devices and even usb keyboard seems to act up (well that might also be just the effect on my program).

Only an issue on windows 10, working fine on Busybox with kernel 5.4.129

hedgecrw commented 2 years ago

That particular line can't be the actual underlying issue since it doesn't do anything other than return a pre-defined string, so I'm assuming the problem is actually happening during enumeration of SerialPort.getCommPorts(). There was a similar Linux-based issue that I just fixed yesterday for all OSs, so maybe it's the same thing you are running into.

Could you please test the following beta release and see if you still are encountering this issue:

https://www.dropbox.com/t/9wgo19QSwSRuk78y

Thanks!

michieltjampens commented 2 years ago

That particular line can't be the actual underlying issue since it doesn't do anything other than return a pre-defined string, so I'm assuming the problem is actually happening during enumeration of SerialPort.getCommPorts(). There was a similar Linux-based issue that I just fixed yesterday for all OSs, so maybe it's the same thing you are running into.

Could you please test the following beta release and see if you still are encountering this issue:

https://www.dropbox.com/t/9wgo19QSwSRuk78y

Thanks!

Ah,k. So the compiler probably removes the empty for loop.

Not sure how to use a local lib in a maven project... so replaced the 2.8.2 in local repo with that one. (and verified if it's actually referring to 2.8.3) Issue persists.

hedgecrw commented 2 years ago

Hmm...this is unusual. I've never had a bug report with similar symptoms. Just to clarify the issue:

Thanks!

michieltjampens commented 2 years ago
hedgecrw commented 2 years ago

Interesting. I went back and checked and there was only one difference between 2.7.0 and the current version regarding handling of FTDI devices. I just implemented two changes (beta 1 = remove the new change completely, beta 2 = implement a fix for the new change) that may or may not address this issue. When you get a chance, could you try both of these beta versions and let me know the results:

Beta 1: https://www.dropbox.com/t/50HjeTnCOGisNaad Beta 2: https://www.dropbox.com/t/8Oj0gAZ5FzI1z4hN

Thanks!

michieltjampens commented 2 years ago

Beta 1 doesn't have the issue, beta 2 does.

hedgecrw commented 2 years ago

Great! That actually just means there's something very wrong with the FTDI drivers being used by your one device. The error occurs when the FTDI-specific function FT_SetLatencyTimer() function is called which should have no bearing on anything other than to the device it's called on. This isn't entirely surprising since FTDI's drivers are notoriously terrible, but I do think I have a workaround that allows for setting the latency without using that function. Let me work on getting it implemented and I'll get you another test JAR ASAP.

michieltjampens commented 2 years ago

Hm, according to windows, the same driver is used for both. But maybe the chip does something bad in response...

hedgecrw commented 2 years ago

That could be as well. Whatever the case, that function is interacting with other USB devices that it shouldn't have any knowledge of. Unfortunately, my FTDI testing setup is no longer functional, so I'm ordering a new converter to get this up and running. I should have the fix completed by Thursday.

hedgecrw commented 2 years ago

Alright, I was able to get this new workaround implemented. Please test the following and make sure it works for you:

https://www.dropbox.com/t/Lj11QA2NjQOyB6Ca

Note, the very first time you use it (or the first time you use a completely new FTDI device), Windows may prompt you for elevated privileges which are necessary to correctly set the latency without use of the FTDI driver.

michieltjampens commented 2 years ago

I get a UAC control asking permission to alter registry about 4 times every time i run the command...

hedgecrw commented 2 years ago

Alright, please try this:

https://www.dropbox.com/t/tAf0pQWBsdH2Cj7y

michieltjampens commented 2 years ago

That seemed to have mostly fixed it, the issue still occurs but much less frequent. When at first it was always within about 6 attempts, now it takes at least 25+. Have the impression it occurs quicker on a restart of the program but that might just be random. So issue still present but maybe at a sufficiently low occurrence rate.

chucky88 commented 2 years ago

hi, I don't know if this is caused by the same issue, but I also have an problem with device enumeration in the latest 2.8.x versions. I have a MangOH board (with Sierra WP7702 modem) connected via USB that adds 3 serial devices (COM 3-5: Modem, DM, NMEA). I need to work with COM3/Modem device and all version until 2.8.x correctly enumerated all aforementioned devices. With 2.8.0-4 i get only COM 4 and 5 when I call SerialPort.getCommPorts(), COM3 is missing. I'm using Windows 10 21H2, JDK 8u322, 64bit.

hedgecrw commented 2 years ago

@michieltjampens, it's still annoying that it's happening at all. I've made one additional change whereby the port is never opened using the FTDI-direct drivers any more. Please test and see if this completely resolves the issue.

@chucky88, your issue is completely unrelated to the above, but luckily, I think it's an easy fix. In previous versions of the library, I manually traversed the entire registry tree which was obviously not ideal, so in these recent versions I've switched to using Windows built-in methods for enumerating serial devices. It seems like maybe it is treating serial modem devices separately from all other serial devices, so I've updated the library to search for modems as well. Please test the following and see if you get the expected results:

https://www.dropbox.com/t/2KcGVlNOP7IMtIuN

michieltjampens commented 2 years ago

Can't replicate it anymore, tried the line about 150 times no issues. Thanks for looking into, and fixing, it.

chucky88 commented 2 years ago

@hedgecrw Thanks! 2.8.5-beta6 can see the modem/COM3 and also seems to be working fine. Looking forward to the final release. I also wonder if there are any other device types that can get the same treatment from windows. Just as a thought, maybe it makes sense to make a property that enables the old traversal mechanism or do you think modems is the only group?

hedgecrw commented 2 years ago

Fantastic! Closing this issue as resolved with today's release of v2.8.5.

hedgecrw commented 2 years ago

@chucky88, to answer your question, from what I can gather, it's just modems that are treated differently for some reason. If someone else discovers another device type with this problem, I'd rather have them open a bug report so that I can fix it properly with the new methodology. Thanks!