USB difficulties in VISA 4.0

[Matt Fitzgibbons]

I've got a USB device with custom firmware. It's pretty generic bulk transfer. I've been using the device with VISA 3.1 in RAW mode with no problems... until my boss decides it's time to update to VISA 4.0.

I used the tutorial here to create a new INF. The device is even showing up in the Device Manager with the new driver. But neither MAX nor VISAIC list the device.

Help!

I'm using two separate WinXPsp2 machines, both with VISA 4.0; one has LV 7.1, the other LV 8.20. I've tried many permutations on reinstalling, uninstalling, and restarting. I've sucessfully downgraded to 3.1, so I know the device is not at fault.

Any suggestions on what to try next?

I'll gladly post any more information that might help.

-Matt

[Tom Limerkens]

Strange,

I had just the opposite problem, an HID raw (composite) device didn't work in VISA before 3.4.

Apparently the VISA USB implementation did undergo a thourough revision in version 3.4,

and things worked as expected after this change.

Tom

[Matt Fitzgibbons]

Since my first post, I tried VISA 3.6 and I got the same thing. I wonder if it's an upgrade issue? (Although the box with 8.2 and VISA 4.0 had a new install but the same problem... so probably not).

Also, a previous programmer on the project was working on a WDM driver that seems to have vestigal remains on both the boxes, and I've read about driver precedence breaking VISA drivers. It seems like this would break 3.1 as well as 3.6 and 4.0, though. The Device Manager also definately shows the correct driver in all cases.

Finally, re: the 3.4 revision--are there any points of the spec on which the newer VISA is particularaly picky? I inherited the USB standard requests from the aforementioned previous programmer, and have found a couple cases where it wasn't handling a standard request that VISA was expecting it to handle (one of the EP status requests, IIRC). Any suggestions on where to look first?

Still stumped.

-Matt

[Tom Limerkens]

The effect we had, was that, if on a USB device, a bulk transfer was started,

a single frame of information was sent, and then the the USB host was closing

the connection.

We could not exactly figure it out what the problem was, because when we

used another (opensource) USB Raw communication framework, it worked fine.

A college pointed me to VISA changes at the NI site,

and in VISA 3.4, a lot of USB stuff was changed :

NI-VISA 3.4 Improvements and Bug Fixes

For USB RAW sessions, communication with non-zero control endpoints is now supported with the use of VI_ATTR_USB_CTRL_PIPE.

For USB RAW sessions, the default setting for VI_ATTR_USB_END_IN has been changed from VI_USB_END_SHORT to VI_USB_END_SHORT_OR_COUNT.

For USB RAW sessions, viReadAsync would fail if the transfer size was over 8KB and not a multiple of the maximum packet size of the endpoint. This is fixed.

For USB RAW sessions, changing the USB Alternate Setting on a USB Interface number other than 0 would fail. This is fixed.

For USB RAW sessions, viOpen leaked a handle for each invocation. This is fixed.

I don't know too much of the USB protocol itself.

We found out about the problem using the USB monitor.

I assume you are using one as well.

If you can find out at which part in the

protocol something goes wrong, it will make it easier to track down.

Maybe the 3.1 version was more tolerant ...

Tom

[Matt Fitzgibbons]

The effect we had, was that, if on a USB device, a bulk transfer was started,

a single frame of information was sent, and then the the USB host was closing

the connection.

If by frame you mean transfer in USB-speak, I actually had a very similar problem. I believe it was a synchro issue and was fortunately able to restructure my messages to make the synchro explicit.

We could not exactly figure it out what the problem was, because when we

used another (opensource) USB Raw communication framework, it worked fine.

Which one? We're always looking for alternatives.

A college pointed me to VISA changes at the NI site,

and in VISA 3.4, a lot of USB stuff was changed :

None of these look very suspicious to me (nor do the changes for the other versions). It seems the problem is not with the communication between the device and the host, but VISA failing to recognize that the device is attached to the system.

I don't know too much of the USB protocol itself.

We found out about the problem using the USB monitor.

I assume you are using one as well.

If you can find out at which part in the

protocol something goes wrong, it will make it easier to track down.

The enumeration is as expected. But VISA doesn't send any messages to the device. The VIs I have written just give me an 0xBFFF0011 (insufficient location information) error, as if the device were not attached to the system. In 3.1 the communication is correct.

Maybe the 3.1 version was more tolerant ...

Tom

My thought as well. Thanks for your help.

-Matt

[Tom Limerkens]

Matt,

just one more thought, could it be that the WDM devellopment installed a different USB stack that VISA is not compatible with?

did you try to install just the VISA runtime on a non contaminated PC, and then install VISA as a driver for your device, using the INF file created

on the devellopment PC?

Success,

Tom

[Matt Fitzgibbons]

I haven't actually tried an uncontaminated box, as I don't have one available (sigh...). I definately need to, though. I'll talk to our IT guy and see if I can make it happen.

Thanks,

Matt

[Matt Fitzgibbons]

As it turns out, it was the string descriptors that MAX didn't like. I turned those off, and now the device works. More debugging to do, but at least I know why....

[Tom Limerkens]

Hi Matt,

Now that is an interesting finding.

Were there special strings, patterns or characters in the descriptors ?

If you can share them with us, maybe we can avoid such strings in the

future. Or at least know when the problems arise.

Tom

[Matt Fitzgibbons]

Sorry it's taken me so long; I've been working on other projects. The descriptors in question had the incorrect length. The bLength field should be the number of bytes in the string, not in the entire descriptor. A handy program from Microsoft called USBView.exe exposed the bug. Apparently your original hypothesis that 3.1 was more lenient was correct.

-Matt