USB chipset-specific buffer overflow errors with USB6008

[BenW]

We are developing an application using the USB-6008 and DAQ8.5 software; it worked fine on our development system (a Dell laptop running XP), but once we deployed it on a brand new Dell desktop (also with XP) we got an error on connection suggesting it was plugged into a USB1.0 port (which it wasn't).  The application then consistently crashed with a buffer overflow, irrespective of buffer size.  We installed a PCI USB card into this machine and the application worked without any problems.  Unfortunately this board was full height and wouldn't fit into the half-height case with the lid closed, so we purchased a Belkin half-height board USB 2.0.  On trying this there is no error on connection, but the application again crashed.

Is there a problem with this device and specific USB driver chipsets?  The Belkin card that didn't work was an NEC chipset, the card that did work was a Via chipset.  We are getting quite desperate as we are close to having to deploy this application.

[DAQAroundTheClk]

The one thing you can check is that you have the most recent version of the USB drivers, especially USBEHCI.SYS, on the machine with the USB-6008 attached to it.  This file should be in c:\windows\system32\drivers.  Did you install the drivers that ship with each USB 2.0 card that you purchased?  In theory (which is of course wildly different than in practice), they should all conform to the EHCI specification and the Microsoft EHCI miniport driver should work fine.  I believe 5.1.2600.2180 is the most recent for XP with the latest service pack.

[BenW]

Thank you for your suggestion. We have checked the USB drivers and they are all up-to-date.  This seems to be a specific issue with the NI device and these chipsets as other USB devices plugged-into these ports work.  We have ordered a different low-profile PCI USB card and will try that when it arrives.  I wonder if anyone else has had difficulties with NI USB devices and these computers (Dell Dimension C521)? 

[hannahW]

Hi Ben.

I've been having a look at this issue, and it seems that there are a few people that have experienced issues with general USB devices and this computer (search on google for USB c521 problem - or take a look at the dell forums). Mostly these are from Linux users, but it seems to suggest that Dell have released some BIOS updates which may or may not fix this issue? Try contacting Dell for the latest version.

I've looked for other people having problems with this combination, and cannot find any information about this.

How did you get on with the low profile card in this machine? 

Make sure you have the latest version of the BIOS and let me know how you get on,

Regards
Hannah
NIUK & Ireland

[BenW]

Hannah,

Thank you for your reply.  Our PCs have the latest BIOS version (1.1.4).  We tried a second low profile card (from StarTech), but with the same result as the Belkin.  

We managed to prevent the application crashing by drastically increasing the buffer size, so we can now deploy it.   We still get the error message (USB 1.0 port) when connected to the built-in USB ports.  Fortunately, this is a nuisance rather than a show-stopper.

Ben

[hannahW]

Hi Ben,

Can you give me some more details about the crash.

You say crash but what do you mean by this - is there an error or does the system blue screen? Can you provide some more details.

If its an error then it may be something that would be expected as a result of the way you've configured the acquistion, USB data acquisition or generation can be tricky with these devices, as they do not have any kind of on-board buffering.

Can you send me the code - or a small piece of code that shows what you are doing - so I can take a look at it. (the code that gives the crash).

I honestly don't know what could be the cause of the issue with the built in ports - this could well be a dell issue - can you contact them and ask if they have any other reported problems. I can't see any data here that shows our USB devices having problems with USB chipsets.

If you can send me the code, I'll let you know what I think

Regards

Hannah
NIUK & Ireland

[BenW]

Hannah,

I don’t have the code to hand (I didn’t write it), but what we are doing is collecting single-channel data at 10 k samples/second into a buffer, and emptying the buffer whenever possible within a loop.  The crash was merely a buffer overflow, rather than a blue screen.  Increasing the buffer size (from 10k to 30k) solved the problem on the Dimension C521; 10k had worked fine on other machines.  We have tried this on several C521s with the same result, so it isn’t down to one rogue PC.

The other issue that remains is that when the DAQ is plugged into an on-board USB port, XP warns that it is plugged into a USB1.0 port.  No other USB devices cause this error.  This is an inconvenience rather than a major problem, and we can live with it.  I appreciate your help, but it is probably not worth you spending effort on this whilst it remains a one-off problem.  As you say, the answer may well lie in Dell’s hands.

Ben

[DAQAroundTheClk]

Hi Ben,

I am glad to hear that increasing the buffer size worked for that particular machine (strange as it is, having to do that on one particular class of machines).  Just one more quick question: In your application, do you modify the OverwriteMode property?  If so, do you set it to Overwrite Unread Samples or Do Not Overwrite Unread Samples?