Jump to content

USB difficulties in VISA 4.0


Recommended Posts

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

Link to comment

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

Link to comment

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

Link to comment
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

Link to comment

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

Link to comment
  • 4 weeks later...
  • 4 weeks later...

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.