Has anyone had trouble with USB transfers of 512 bytes or less?
The first time we do this, it works fine. Following this, though, we’re unable to download a new FPGA bitfile until we disconnect the USB power and then reapply it.
We’re using a xem3001v2 and Linux. We’ve tried buffered and unbuffered PipeIns, but have had the problem with both. Any help greatly appreciated!
Tim
Hi Tim-
We have an in-house application that transfers small packets (2-128 bytes typically) repeatedly without any problems. This application works on both Linux and Windows.
What firmware and FrontPanel versions are you using?
A buffered pipe is just a regular pipe with an adjoined FIFO, so the presentation to the host interface is identical.
Hi,
That’s encouraging news! Are you able to reconfigure too?
Here’s the information written back by the board:
Board model 2
Device list model 2
Device list serial cSBBQqLCUg
Device major version 2
Device minor version 3
Device serial number cSBBQqLCUg
Device ID Opal Kelly XEM3001
We’re using FrontPanelFC3-v1.3.1, which we downloaded from the website. We’re mainly using CPP, although we have tried Python too, with the same results.
I’ve attached some CPP which we’ve been using to try to track down the problem - the VHDL we use is very simple, it just counts the words it receives and adds them up to make a checksum.
Many thanks!
Tim
main.txt (1485 Bytes)
Tim-
What is failing in your code? It doesn’t appear to make another reconfiguration call at all.
If you’re just running the program again, I notice that you don’t call “delete xem” to free up the memory and deallocate resources.
Oops - well spotted.
You’re right - I am just running the program again and again. However, even with the destructor, it only works correctly the first time…
Any other thoughts?
Tim
Tim-
I know it sounds like a cop-out, but have you tried another machine. We’ve had pretty poor consistency among Linux machines and USB support. And not just with our device.
Hi,
We’ve now done a few more tests, and got the following results:
1 packet 512 bytes, FC1 - OK
1 packet > 512 bytes, FC3 - OK
1 packet > 512 bytes, winXP - OK
2 packets 512 bytes, FC1 - OK
2 packets > 512 bytes, FC3 - OK
We’ve also discovered a way to make it work again once it has failed, by typing:
rmmod ehci_hcd
modprobe ehci_hcd
Can anyone make any sense of these observations?!
Tim
I’m working with Tim on this project.
On our end, we have seen the same sort of problem with both a Debian Etch and Sid system and it does not occur on any windows machine I have tried. This was seen with both the 3001v2 and the 3010 and using different bitfiles from Tim.
I’m reasonably sure it has something to do with the linux drivers and not the board. It’s not that the board needs to be powered down but the usb interface needs to be remounted, which is why reloading ehci_hcd fixes the problem. Of course in practice this is not a solution because you need root access and it will affect all USB devices.
You never said if you have tried to run Tim’s test code, and whether you see the same results. I’m curious what system, and more importantly, what version of libusb you are running if it works without problems.
Thanks,
We’ll look into this shortly and get back to you. As you know, our Linux port is currently based on libusb. We’re looking into moving past that dependency and writing a straight IOCTL implementation.
Tim-
I tried this on our Linux machine here (FC3) and it works fine. In fact, our regression tests include tests for short pipe transfers, but I wanted to make sure your code worked verbatim.
The machine is an unmodified FC3 installation.
Your .h file should be revision 235. Your .a files should be 112,652 bytes. Are these the same as yours?
Hi,
Thanks for trying that. Yep, those version numbers agree with ours.
We’ve now tried FC4 and had the same problems. We’ve also found a few more Linux failure modes, as follows:
Open, Configure, Write 512B (FAIL), Write > 512B - OK
Finally, I got the following information by using the ldd command:
linux-gate.so.1 => (0x0088d000)
libusb-0.1.so.4 => /usr/lib/libusb-0.1.so.4 (0x008d8000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0074b000)
libm.so.6 => /lib/libm.so.6 (0x004ee000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0073f000)
libc.so.6 => /lib/libc.so.6 (0x003c3000)
/lib/ld-linux.so.2 (0x003a5000)
Perhaps you could check the version numbers of your drivers?
Many thanks!
Tim
Tim-
The version numbers are the same. We have not updated the FC3 installation, so it should be a clean, stock FC3 install with all the original stuff in there.
Perhaps this is a driver issue with the particular USB controller on your motherboard conflicting somehow with libusb. ?
— Begin quote from Opal Kelly Support
Perhaps this is a driver issue with the particular USB controller on your motherboard conflicting somehow with libusb. ?
— End quote
This is unlikely seeing we have seen this problem on at least of 3 different machines each with different chipsets and drivers.
This may be a stupid point but it looks like the Main.cpp file that Tim attached is setup to write 514 bytes, which is supposed to work. Did you change this when you tried running the code?
The only other thought I have is a problem with the bit files we are using. Maybe Tim could attach the one he is using and you guys could try it with that?