I hope that you have gone through AN87216.
How did you confirm that the buffer is being filled?
Please share the screen shot of timing error that you have seen.
Which book you have referred here? Super speed design by example?
When you set the GPIF in Master Mode, FX3 can drive the clock.
What is your expectation of best manner to drive?
It would be good if one community thread addresses one issue: Reading issues in one thread and Writing issues in another thread. Please create another thread to address writing issues. We shall continue reading issues in this thread.
Thanks for your answer, I will separate the issues, and continue with the reading issues here only.
I've read AN87216 too,
With the Signal Tap Logic Analyzer I'm monitoring the DMA flags for the socket (Thread 0) I'm using and I can check that the buffer gets filled, here is the screenshot of the logic analyzer
The data I'm reading is not relevant now, it's just a counter, the RD signal is for the Slave FIFO, OE for driving the bi-directional data bus, DMA_WM_0 the partial flag for Thread and socket 0 with watermark 8 and DMA_RDY_0 the full flag for the same thread and socket..... I keep RD high until DMA_WM_0 is asserted, then read the last words from the FPGA and fill the buffer in the FX3, apparently the buffer gets filled but when I try to get the data with a Bulk-in transfer from the host-pc I get this error
Please use DMA Manual Channel and check for producer event in the DMA Call. You can set a flag in the Producer Event and print the debug print in the main loop (if the flag is set). This will confirm that the buffer is full from the DMA Perspective.
The error 997 is timeout error. This comes if the request is not served within the time.
Hi, I changed the DMA Channel configuration from AUTO to MANUAL,
I think It will be good to say that I'm using the SlaveFIFO firmware from the AN65974... I just changed the GPIF State Machine header file with the one I made (with the FX3 as a master) and change the DMA watermark values for the partial flag for the threads, in theory this should works since the only difference is how the GPIF interacts with the FPGA right?
So using debug print to find where was the error, I've got this message
Everything seems to be fine with the endpoints, creating the DMA Manual Channels and setting them active, after starting the transference from the FPGA to GPIF is when I get this number Error:19 , which is printted by this next part of the code from AN65974
Thanks again for your help!
It looks like you are facing the overrun error. This error comes when the dma buffer is over flow. Mainly, when the flow control mechanism is not proper.
Please share the modified GPIF State machine and firmware.
Please let me know what is the size of data you read from FPGA. Is this fixed size or varies? Based on this, we can move the flow control mechanism to FPGA itself. Hence, we can get rid of water marks flags in the design.
For now I'm trying with a fixed size of 1024 bytes, but the intention is to make it variable later, I'd like to have all the flow control on the FX3 side. If the size of transfer is fixed, I could you use a counting mechanism in the FX3 right? Maybe using the state repeat count option in the GPIF II Designer?
I'm using as a reference the GPIF State Machines in the SuperSpeed Device Design by Example, more specifically the GPIF_Example8, I changed the watermark configurations based on it. Here they are the modified files, GPIF State Machine and firmware.
Using a Manual DMA Channel, and Debug Print I could find the error, I was unproperly configuring the P-Port (GPIF) clock, the error was CYU3P_PIB_ERR_THR0_ADAP_OVERRUN and the problem was that the DMA controller couldn't keep up with the incoming data rate because my GPIF clock (that was driven to the FPGA too) was configured to 200 MHz when the max frequency is supposed to be 100 MHz.
Hope, this can be useful for someone else!