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.
1 of 1 people found this helpful
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?
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.
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.
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.
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.