EZ USB FX1 Cannot Open VISA session

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

We've got a bunch of devices that interface using a Cypress EZ-USB FX1 via a Win10 64-bit driver based off of cyusb3.

Most of our fixtures connect fine, and show up in NI-MAX as a VISA device that communicates on some COM port. Yay.

But some of the fixtures don't connect to NI-MAX. We get the following error: "VISA returned this device when finding resources, and MAX was able to use VISA to parse the resource name. MAX was not able to successfully open a VISA session to the device."

Obviously, if this was an NI-MAX issue then I'd be in the wrong place. But I think that MAX is just the messenger, because the COM device associated with the EZ USB FX1 also gets a yellow caution sign in the Windows Device Manager, too.

I'd appreciate any hints or direction to get this working for every device. Thanks!

0 Likes
1 Solution
Sananya_14
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello,

From your description, I assume that FX1 enumerates as a COM port on the host PC. In that case, it needs to be bound to CDC class device driver such as Windows usbser.sys. Could you please explain your complete implementation and also attach a screenshot of the device manager when the connection is not proper?

Best Regards,

Sananya

View solution in original post

6 Replies
Anonymous
Not applicable

More details:

The "bad" one worked with the old Cypress drivers, including usbser.sys (not sure if that was a Windows driver or Cypress).

It is possible, though I think unlikely, that the "bad" unit has a counterfeit part, so if there is a simple method to validate the chip then I'd love to hear it.

The "good" and "bad" chips were flashed with the same .iic file, so I don't think that is at issue.

I'm open to suggestions that would help gather more info.

0 Likes
Sananya_14
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello,

From your description, I assume that FX1 enumerates as a COM port on the host PC. In that case, it needs to be bound to CDC class device driver such as Windows usbser.sys. Could you please explain your complete implementation and also attach a screenshot of the device manager when the connection is not proper?

Best Regards,

Sananya

Anonymous
Not applicable

Sananya, thanks for responding. I'm getting to the bottom of this as I go so I'll answer your questions and provide more info too.

Yes, the FX1 enumerates as a COM port. I'm using the latest Win10/x64 cyusb3 drivers, customized to match our VID and PID, then signed. When the device works it appears in the USB Controllers section of the Device Manager, and the corresponding COM port appears in NI-MAX. However, NI-MAX can't talk to it, complaining of error 0xBFFF0000.

But when I talk to the same COM device directly, I see that it is responsive, but the attributes are all messed up, so that the VI_ATTR_TERMCHAR is unset, which in turn causes VI_ERROR_TMO (timeout) since the IDN response (or whatever is called during handshake) terminates with "\n". When I manually set the attribute value to 0x0A ("\n") then things seem to work as expected (though some other attributes might be messed up without my knowledge).

But as soon as I close the session, the termchar resets to 0 so that the next session can't communicate. So I can't just set the attribute value with my LabView VI.

I've done some searching and found that Windows 10 power management settings may be responsible for this. I haven't explored that yet. But I'd certainly love to hear why my device attributes get lost. It makes sense to me that when USB power disappears, any volatile memory would be lost, so perhaps that's where the attributes get crushed. If so, maybe I can request RENUMERATION or a firmware load or whatever to get those attributes set. It may also be possible that our Firmware doesn't properly set the attribute. It also may be possible that the firmware property is controlled entirely by NI-MAX, but I don't see how since it can't communicate with the FX1 at all until the attributes are set right.

0 Likes
Anonymous
Not applicable

I've done some more testing and things get even more weird. Some devices work fine using this driver with NI-MAX. Other devices running the same firmware and the same hardware won't work, no matter what I do. The devices that don't work show VISA timeouts and therefore cannot do a VISA handshake/open under NI-MAX, but when I query them directly they seem to work fine. What throws me off is that I expected the TERMCHAR to be set on the working device and not set on the non-working device, but that attribute isn't set on either. So the working one is somehow communicating right even though the attribute isn't set.

0 Likes
Anonymous
Not applicable

sanm, you were right, I sometimes need to bind to a CDC class driver, too. At that time I didn't understand that the USB driver wasn't a CDC driver so I mistook what you were saying.

When the CDC driver is bound to the COM device (in addition to the USB driver), then everything seems to work for every physical device we have. But without that CDC driver, half of our devices still work, and I don't know why.

0 Likes
Sananya_14
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello,

Could you please clarify if your device has both vendor and CDC class interfaces and thus show up under COM port as well as USB Controllers? I am a little confused as to how the device is enumerating before you open it in NI-VISA. Please attach a screenshot of the device manager when you get the error. If it doesnt enumerate properly as a COM port device or doesnt bind to the CDC driver and you need to open the same in your application, it is likely to show the mentioned error you are facing.

Best Regards,

Sananya

0 Likes