I’m trying to simulate a system that’ll be feeding me three NMEA GPS feeds on three separate serial ports in advance of a field trial in a couple of weeks time. I grabbed three of the NEO-6Ms and three of the PL2303HXAs to do a cheap-and-dirty local sim of what the real system will be giving me.
Unfortunately, while I’ve managed to get the PL2303 drivers installed and working on both WIn10 and Win7 machines following the instructions on the product page, when I plug the NEO-6M’s in, I get blue-screen crashes on both machines. On the Win10 machine it seems to work OK for about 3 mintues (enough time for me to launch putty and get a brief log that verifies I’m getting NMEA strings out of the NEO). On the Win7 machine, it doesn’t even get to the login prompt before the machine blue-screens and resets. Just to make things really fun, if I plug the adaptor into my Win10 machine after boot, it hijacks my mouse, jumping it around the screen and clicking, which is just freaking strange as hell.
Anyone got a suggestion that can help me get these up and running? I figure the PL2303 drivers are the probable cause here, but even on Win7, an OS they notionally support, they cause hard fails. I have already tried the alternative driver package from the Prolific website, but with those drivers the 2303’s don’t even come up as com ports.
Quick edit - Just to clarify, the craziness and blue-screen crashes only come when the GPSs are plugged into the 2303s. Just having the USB-UARTs plugged in doesn’t cause any issues, I can connect to them in Python and PuTTY just fine and they come up as expected. The issue only comes when there’s a GPS on the other end sending NMEA strings upstream to the PC.
Cheers in advance,
Sounds like a very frustrating issue! Can you just confirm which Windows 7 Build you are running on your test machine? (Win+R
Welcome to the forum!
That is some super odd behavior from the adapter!
Just to double-check, have you configured the drivers for the Win10 machine using the steps in the product page?
Just note that the NEO-6M module is a 3.3V board so you will have to use the 3.3V jumper from the UART adapter.
If you have an Arduino or another USB to UART adapter handy connect the GPS module to verify that it isn’t an issue with the USB adapter (be sure to use 3.3V output pin to power the module).
It sounds like the bluescreen is caused by the UART signal not being handled as expected.
I have indeed configured the drivers on the Win10 machine as instructed, and I’m using the 3V3 rail from the adapter.
I agree it’s probably an issue with the USB UART. Unfortunately I don’t have another one in the office to check against other than the Prologics (If I had one here, I wouldn’t have needed to grab them along with the GPSs). The 2-3 minutes I get from the UART under Win10 is enough for me to confirm that the GPS is operating as expected, and pumping out the NMEA strings.
The only other test I can think of is to put a loopback jumper from TX to RX on the UART, and then write a python script that spams the serial port at the same rate as the GPS to see if I can reproduce the issue.
Either way, if I can’t get this working pretty soon then we really need to look into getting a replacement on it’s way to me before the express post cutoff this-afternoon. How can we go about getting a credit and RMA number for the prologics so we can switch to a hopefully more reliable model?
Does it do this only with Putty, or any serial monitor software? How about the Arduino IDE serial monitor?
We might have to grab some stock and check it out!
It doesn’t require any serial monitor to be running. If it’s plugged in before power-on the Win7 machine crashes on boot before I even get the login prompt, and if I plug it in after logon, the machine blue-screens within about 30 seconds before I have a chance to launch any sort of monitor. On the Win10 machine it’s completely independent of whether or not a monitor is running, the machine does the windows 10 blue-screen thing about 5 minutes after it’s plugged in.
What’s the error on the bluescreen?
I’ll try and reproduce in a bit when I can afford to crash the test machines again… I’m currently running a little loopback test on my desktop, two of the UARTs plugged in, TX of one to RX on the other. Python’s sending “Hello World” 4 times a second from one to the other, and I’m seeing the result from the other in a PuTTY session. Giving it a bit of a soak under that test to see if smaller packets can cause the crash.
So here’s the test:
Here’s the hardware:
And here’s the result:
The error text is Stop Code: MULTIPLE_IRP_COMPLETE_REQUESTS
It repeatably runs for about 3 minutes and then crashes, I generated 3 crashes accidentally just trying to test the python code and get the screen grab of the app with all the windows up… It originally crashed from just sending Hello World over and over and over again, but I wanted to test against the NMEA strings I grabbed from the GPS for completeness.
Does it do it with only one connected?
Here are some clues I found from the goggle box:
If you read the initial post, the first time I found the crash was with the USB-UART connecting to a GPS that was throwing NMEA strings at me. If there’s no traffic on the serial connection, then it’ll happily sit there all day, but as soon as you start running data it doesn’t matter whether a serial terminal is open or not, on win 10 it takes about 3 minutes to crash on the NMEA data, or less time if I’m using the loopback rig and python to spam the port. I’m guessing there’s some sort of overflow/underflow happening in the driver, but that’s obviously beyond my ken to debug.
I think we’ll need to find a different USB-UART, so I’ll just chase up the Core chat team on that front.
– Dave W
We’ve been working on this with Dave and have been able to isolate the issue to an interaction specifically between PuTTy and the PL2303 serial driver, specifically when reading from the PL2303HXA.
We’ve been unable to get the crash to occur using any other serial monitor:
- Windows Powershell
- Arduino Serial Monitor
So it appears it may be a bug in PuTTy!
If you want to test out Powershell, Hit Win+R and type
cmd to bring up a command prompt.
powershell to start power shell, then:
$port= new-Object System.IO.Ports.SerialPort COM3,9600,None,8,one
$port2= new-Object System.IO.Ports.SerialPort COM4,9600,None,8,one
Adjust your COM port numbers as appropriate. To break the loop in Powershell, hit Ctrl+C
Don’t forget to:
When you’re done!