- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello
I’m using the FX3 for transferring data from a FPGA to PC, and having a problem emptying the last partly filled buffer after the acquisition has finished.
On the FPGA side the design is based on the Slave FIFO interface described in AN65974.
The software on the PC is based on Streamer application modified to store the received data to a file. Like in the streamer I use the API methods for asynchronous IO (BeginDataXfer, WaitForXfer, and FinishDataXfer) and a circular FIFO of buffers (queue).
During steady state the FIFO mechanism works great with the data transferred as expected.
The acquisition stops when the FPGA stops sending data and WaitForXfer reaches timeout. At this point there is one partly filled buffer in the memory which I am having difficulties emptying.
I would like to determine how much data was written to this last buffer. If I understand the API correctly, running the FinishDataXfer method on the buffer, i.e. FinishDataXfer(buf_fpga, cur_len,…), should set the actual number of bytes transferred in the cur_len field. But in practice calling FinishDataXfer always sets cur_len to 0.
What am I missing here?
What exactly is the right behavior I should expect from FinishDataXfer?
Is there a way to determine the number of bytes transferred without calling FinishDataXfer?
Attached below is the relevant section of my code.
Thanks for the help,
Oren
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
If the last packet from the device is a multiple of 1024 bytes but less than what is requested in BeginDataXfer, and if timeout occurs, then the partially received data (which is a multiple of 1024 bytes) cannot be retrieved in the application. The way to retrieve the same is to send a ZLP from the device indicating that the transfer has ended.
Let me know if this is the case with you.
Regards,
Hemanth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
If the last packet from the device is a multiple of 1024 bytes but less than what is requested in BeginDataXfer, and if timeout occurs, then the partially received data (which is a multiple of 1024 bytes) cannot be retrieved in the application. The way to retrieve the same is to send a ZLP from the device indicating that the transfer has ended.
Let me know if this is the case with you.
Regards,
Hemanth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Hemanth
This is indeed our case. The overall data size sent by our FPGA is a multiple of 16KB and we are not sending a ZLP at the end.
I will ask the FPGA designer to implement ZLP, and hopefully this will resolve the issue.
Thanks for the prompt reply,
Oren
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Oren,
How much of data is requested in one BeginDataXfer()?
Regards,
Hemanth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
Each BeginDataXfer buffer size is 256 * 16KB = 4194304 bytes
Oren
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Oren,
Okay. So in the last transfer where the failure is seen I think the FPGA sends data multiple of 16KB but less than 256*16KB.
If this is the case, then, yes, sending a ZLP at the end would solve your problem.
Regards,
Hemanth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, this is exactly the case.
I will update the FPGA firmware to send a ZLP and report back within a week.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi again
Glad to report that sending the ZLP indeed resolved the problem.
Thanks Hemanth, appreciate your help.
Oren
.