rs232 lib + multi-thread = Blue Screen of Death

[ElectroLund]

I've got a nearly repeatable critical issue on my project.

I'm using the standard RS-232 Library for a very straight-forward application with an SRS RGA (gas analyzer).  That half of this effort works very well, very ordered and non-mysterious.

But then I tip-toed into the multi-thread world using the CMT to facilitate the instrument's rather slow retrieval of histogram and analog scans.

I opted for thread-safe queues, as they seemed to have the lowest cost-to-entry and smallest setup.  I'm doing nothing fancy here, merely creating a queue each time a histogram is needed, filling it with data and elsewhere reading the data from queue and plotting.

Yet, under certain circumstance, I get very often get BSODs:

I did some research on "ser2pl64.sys" and see that it's my serial-to-USB cable.  I swapped this out, no affect.

I've done many projects now with the RS-232 Library and never, ever seen such hard errors like this.  I really feel that I've done some poor housekeeping with the CMT, as this is my first project to use that lib.  Yet, as far as I can tell, I'm flushing and discarding it when done.

[ebalci]

Hi,

That's really weird.
We have released several RS232 library + TSQ (and/or TSV i.e. thread-safe variables) projects here in our department and never encountered such a situation.
We have used as hardware, USB serial converters of standart speeds and also 1.5+ MBaud cards from FastCom without problems.

But we never create/destroy queues in the middle of the operation. We create them during initialization (probably even before first panel is loaded) and use them exclusively during the execution and destroy them during program exit.
That's the only comment I can provide so far based on your description.

Good luck,

[RobertoBozzolo]

I second ebalci comment: we are extensively using serial communications to handle our devices with multithreading and TSQs. I have never got BSDs like yours and we are very often using usb-to-serial and ethernet-to-serial devices to connect to external hardware; it's true on my side also that I never discard a TSQ during the program: I collect data from the queue mostly with a TSQ callback and discard it at program end.

[ebalci]

I have an experience having a bsod for a driver issue on Windows 10 at my personal home laptop.

The laptop is a little oldish but has Win10 on it (free upgrade for for Win7 users ). It turned out that, the onboard wi-fi drivers were incompatible with Win10, and could not be upgraded for Win10. It used to fail intermittently and cause bsod.

Since then I am using a usb wi-fi dongle with recent drivers and never had that issue again.

Could that be the problem for you? Which make/brand of usb-serial do you use? Did you make sure you have compatible drivers for your OS?

[ElectroLund]

Thanks for the replies, everyone.

I will attempt to uninstall and reinstall my USB-serial cable drivers.  This cable has been in play across many test fixtures running CVI applications for some time now.  All Windows 7.  But it's worth a try.

As to the thought about creating a TSQ once and destroying it only at program exit... I structured my app to create/destroy each time because my queue size is variable depending on the type of scan.

For instance, histograms on this instrument might be any size up to 100 AMU, with one data point per AMU.  

But for analog scans, there are variable steps per AMU, so for a 1-100 AMU scan and a 10-step/AMU, you would have 991 total data points.

Sure, I could create two TSQs, but I was trying to keep the function hierarchy generic.

[RobertoBozzolo]

You could define a structure like for example

typedef struct {
    int     type;
    double   amu;
} measure

Have the TSQ defined for one element of size sizeof (measure), pass the first element with e.g. type = 0 and amu= number-of-points-to-pass, followed by number-of-points-to-pass elements with type = 1 and amu = actual measure.

This will permit you to have a variable number of elements in the TSQ depending on the operation you are performing.

[ebalci]

Besides, TSQs can have dynamic re-sizing. Although I have never tried it because of its out-of-control feeling, it may be useful.

[Andr3s_Br3n3s]

Did you try to change the cable? any update?

[ElectroLund]

So, I did change my cable and I also uninstalled the driver and reinstalled.  I haven't seen a crash since.  That was 2 days ago, and I've been actively debugging ever since.

Also, I kept my existing TSQ structure where I create and destroy with each new scan start.

So far, fingers crossed!

[Andr3s_Br3n3s]

keep us update