weird serial port hang, windows only

Status
Not open for further replies.
G

glasspusher

Active member
Hi Paul et. al.,

I'm having a maddening problem with a teensy 3 I'm using in a couple of custom, paid for projects I've made-

It seems like occasionally, on my own apps (written on a mac but running on windows, Cocotron) and on ones the client is using, written with LabView- and this is my guess- something, perhaps a bit of noise on the line from other parts of the widget- causes the teensy to hang in windows, requiring a complete unplug/replug. The device manager still recognizes it, but neither the LabView written app nor my Cocotron created app can access it again. I don't have many details from my client as far as the LabView VISA errors, but my app ends up giving a
Get*Overlapped*Result
error from the windows OS. I looked this up and find some information on it- this one seemed most helpful- but the fact that it's happening on different computers, different apps written with different stuff makes me wonder if either

a) both the app I wrote and the other one written with LabView are making the same boneheaded mistake
b) something with the teensy driver? I don't know, because I don't know what's behind it
c) windows sucks, because I can run the same app I wrote for windows, the mac version, on my mac, and it never, never loses contact with the teensy.

I spent the whole weekend shielding the USB cable, putting in ferrite beads, replacing the usb receptacle on the project chassis, and no love from windows. I have to assume they'll see the same problem when I ship it, and if it's a software issue, so be it, I'll work around it on the windows version, better error checking and so on, but I'd like to know if that sounds reasonable before I sink more time into this. I wanted to ship this down to them last week and I've blown the weekend. Ah, life. At least my Red Sox cheered me up ;)

Thanks in advance for any and all help. I'd be happy to post the windows serial port code, error messages and so on.
 
Please give 1.17-rc1 a try.

A bug with buffer memory was recently fixed. It may be completely unrelated, but installing 1.17-rc1 and then uploading to your Teensy3 is easy to try.

Edit: If that doesn't solve the problem, yeah, better post details. I don't have Labview. Is there any way I can reproduce the problem without it?
 
Hi Paul,
Thanks for getting back to me so quickly. I re-flashed the teensy with 1.17rc1 on my mac and updated the drivers on the windows box as well. Started up my app on the windows box and will let it run for a few hours. Stay tuned!
 
Not sure if this is happening on the LabView side of things, but if the program does not end correctly ie: loops don't stop, then the VISA end session does not happen, causing the serial port to stay open. When I first started using the teensy with labview this was happening to me and could not understand why, then realized if I stopped the program correctly, then it worked again. Since you say it is also happening with your code, I assume this is not the case.
 
Yup, that sounds like the bug in Microsoft's driver, where the device does not work when reconnected it if it disconnects while a program has the COM port open. After such a disconnect-with-port-open, when the device reappears, you can see it in the device manager, but Arduino and other programs can not actually open and use the COM port.

Phil Torrone of Adafruit recently found someone at Microsoft whose "team works on device connectivity in Windows". Three weeks ago we exchanged several emails about this bug. He seemed genuinely interested, so I made a video to demonstrate the exact steps to reproduce the problem, using an Arduino Uno (the bug impacts all boards using Microsoft's built-in driver, not just Teensy). That was only 3 weeks ago. I don't know if they'll ever fix this, but until 3 weeks ago, we had never even managed to talk with anyone at Microsoft who even wanted to know about the bug.
 
Hi Paul,
Didn't help. It only seems to show up if the USB line is in a noisy environment, but once comm is lost, it's lost. Below is the function where things hang. It hangs on a write, but this may only be because the write happens first. GetError returns Error 31, ERROR_GEN_FAILURE. Releasing, invalidating, quitting the app doesn't bring it back for use by any other app or re-launching the old one.

I don't know if it's possible for you to set up your driver to handle this condition. Right now I'm trying to brute force around it by making my USB cable as short as possible inside the chassis, shielding it, ferrite, yadda yadda.

The function is below, the spot where I get the error is at the end of it, commented. I didn't write this code, someone else gave it to me, I'm no expert on it but can follow it to an extent. I might be able to whip up a little hardware setup that reproduces this, if you're interested, after I get this widget out the door.

Thanks.

Dave


-(void)handleMonitorIndicatesSignaled:(NSHandleMonitor_win32 *)monitor
{
if(monitor == _readMonitor)
{
switch(_state)
{

case stateAfterWaitCommEvent:
if([self getOverlappedCommEvent])
{
int available=(_commEvent&EV_RXCHAR)?[self getAvailableSize]:0;

if(available==0)
[self waitForCommEvent];
else
{
[self readFileWithAvailable:available];
if(receiveData)
[receiveData appendBytes:_readBuffer length:_numberRead];
else
receiveData = [[NSMutableData dataWithBytes:_readBuffer length:_numberRead] retain];
}
}
break;

case stateAfterReadFile:
if([self getOverlappedReadFile])
{
int available=[self getAvailableSize];

if(available==0)
[self waitForCommEvent];
else
{
NSLog(@"sarf");
[self readFileWithAvailable:available];
}
}
break;

}
}
else if( monitor ==_writeMonitor)
{
DWORD numWritten=0;

if(!GetOverlappedResult(_handle,&_writeOverlap,&numWritten,TRUE)) // this is where I get the error
{
NSLog(@"GetOverlappedResult hmis error=%d",GetLastError());
}
[self enableWrites];
}
}
 
Last edited:
Hi guys,
Just read your new replies- I try to be sure to close ports and release objects before quitting a program, this happens before the program even quits. I'll follow any information you have about the MS guys trying to fix this bug with interest.

So, to clarify- this is something I'm seeing while a program is running, not an issue when an app quits unexpectedly or doesn't release the serial port. This is more like a bit of noise on the line causes something to go on the fritz, never to recover, but a mac connected to the exact same device never has trouble. I could try an Ubuntu box...

The folks I'm building this box for want it to be bulletproof, but also want to run it with windows. I hope the two aren't incompatible :/

Re-reading your post #5 up there, Paul, it seems that if a device disconnects while the com port is open, there's no way in software one can close and re-open it. Gotta be physical unplug/replug. Ugh.
 
Last edited:
Hey folks,

Just throwing it out there- if I need a bulletproof setup, would it be better to communicate with the computer using an ethernet module? I mean, damn...if we're getting lemons, maybe I should go with oranges (if they won't let me use Apples)
 
If you're using Windows and need "bulletproof", well, the closest you can probably get involves using HID protocol.

The sad truth is Windows has a lot of pretty poor quality code, but the HID stuff actually works pretty well. I'd highly recommend you use the RawHID USB Type (from Tools > USB Type) and custom software to talk to the board.
 
Hi again,
Shipped the widget, tried both HID and serial. Seems the problem is mostly on their side, it seemed that when they switched to powering the teensy directly rather than through USB, they had no trouble for 3 weeks, but now they're having communication dropouts again when the pumps and compressors of the device are turned on. Beats me. Ferrite bead between the ground line, separate power to the pumps and compressors. They say that if the teensy is used as a serial device, it'll just lose communication and keep running and adjusting things, but if it's set as a HID device, it'll brown out and whatever state the pumps and compressors are on will be frozen. This last bit of information strikes me as weird- is the HID stuff controlled by the CPU and not the USB interface chip, then?

I'm going to try to come up with a box where I can duplicate the comm dropouts they're seeing(like pounding enough electrical noise on the ground until I get a dropout). I'm considering ethernet or a slower serial connection out of the box to eliminate communication problems, but I don't want to go down this road if it's putting a band-aid on the wrong part of the device.

Any insight is much appreciated.
 
Last edited:
I am in a very similar position to the OP. Using a Teensy 3.1 to control some industrial hardware through a virtual serial port. It seems that at 'random' times windows decides that it does not want to communicate any more (usually when an actuator is switched, but not consistent). I have tried putting all sorts of filters, isolation, etc. however these seems to have no impact. My only solution is to either physically disconnect and re-connect the Teensy, or go into device manager then disable/re-enable the port.

Unfortunately there is no way for me to predict when the port might drop out, otherwise i could stop my program (VB.net) from using the serial port while the device manager cycles the connection.

I thought I was the only one experiencing these issues until I came across this thread. I think I would rather hear that my code was buggy, as opposed to Microsoft drivers. At least that way I can do something about it! I will have to try the HID alternative.
 
Hey there,

No, it's not just you. Paul mentioned this in above in this thread- seems windows serial port code is very old and buggy. To be fair, serial ports started long before they were able to be disconnected from the hardware, not like they are today.

If the serial port disconnects for whatever reason (voltage spike or loss), you're pretty hosed in windows. The OS can re-connect, but you can't re-establish a connection from user space.

I would highly recommend a mac or linux, in that order. It's been fascinating. I wrote an app using Qt, so I could run it natively on windows, linux or macs, and even using the same hardware for both linux and mac os x, os x was better than linux. Linux would lose the serial port but could re-connect from user space. os x wouldn't even lose the serial port.

My recommendation to you, with any OS, is to power anything other than the teensy and small, constant current loads from something other than USB. That'll help cut down on any comm dropouts from hardware. If you're using windows, I would also strongly encourage you to use the teensy as an HID device- the code for that in windows is more robust and allows for re-establishing a dropped connection.

Good luck and feel free to ping me. If I can save someone else the trouble, I'm happy to do so.
 
Last edited:
Status
Not open for further replies.
Back
Top