DMA channel callback not be called, and Data losses

[Nifor]

hello.

i'm working on fx3 firmware project with CYUSB3KIT-003 configured with auto dma channel (P to U) to bulk in endpoint.

based on fx3 sdk's predefined models (synchronous slave fifo interface & BulkLedSample)

external clock based on FPGA (80Mhz), data bus 32bit.
dma buffer size: 16 * 1024 byte.
dma buffer count: 4.

independent gpif model different from predefined gpif state (FPGA sends data when ctrl pin flagged)
without any other work.

the data transmission with fpga -> fx3 -> pc 's  bandwidth worked as expected (2.1Gbit/s) 

but each packet had a loss ( the desired data does not come from the end of the packet. there's a missing part).
so I tried to debug the dma channel's callback but I realized that the callback function not be called.

there was a long introduction.

Question 1. 

 I want the action required for callback function to be called in fx3 firmware.
to commit data, I changed the dma channel to manual mod, but it not works.
that's why I didn't put in the code I needed.

Question 2.

Are there any suspicious clue for missing data?
I cannot find a clue because the flow of data cannot be debugged.
However, if there is a case that I couldn't refer to in the previous post, I would appreciate it if you could provide it...

I can send you the project file by personal email.

Best Regards,
Nifor

[Rashi_Vatsa]

Hello,

Please find my comments below:

Question 1. 

 I want the action required for callback function to be called in fx3 firmware.
to commit data, I changed the dma channel to manual mod, but it not works.
that's why I didn't put in the code I needed.

>> If the data from FPGA is not 16KB or if the DMA buffer is not completely filled the data will not be committed or the DMA callback will not be triggered. To commit the partially filled data "COMMIT" action needs to be called from GPIF state machine. Please note to commit partially filled buffer COMMIT + IN_DATA both need to be called in the state or CyU3PDmaSocketSetWrapUp API can be used in the firmware to wrap up the socket.

Question 2.

Are there any suspicious clue for missing data?
I cannot find a clue because the flow of data cannot be debugged.
However, if there is a case that I couldn't refer to in the previous post, I would appreciate it if you could provide it...

>> Please track the producer and consumer events in the DMA callback to understand the amount of data received by FX3.  If you are using AUTO channel then please change it to AUTO_SIGNAL to get the trigger when the producer and consumer events occur

[Nifor]

hello rashi,

Thank you for responding to me.

The data transfer scenarios are as follows:
1. PC Application (C# with CyUSB.dll) sends a vendor command that controls the gpio(MODE) output pin of fx3.
2. Then the fpga that checked the gpio(MODE) output sends an interrupt signal to gpio input, and fx3 asserts SLRD output to handshake it.
3. The fpga that checked the SLRD value transmits 32 bit data * 1024 times simultaneously with the signal PLAGA (set to send increasing values sequentially for data verification)

As I mentioned above, the bandwidth was successful in obtaining 2.1Gbit/s from the streamer app, a self-made data transfer app using XferData() with Thread.

but Periodically, an average of 54 bytes of data is missing. 

I would like to ask you if there is a project that you can refer to in order to avoid missing data from the project I sent you by email, or if I have proceeded with the dma config that does not fit the scenario. 

data jumps when: example
dmacfg.size = 1024 * 4
dmacfg.count = 4 

Regards,
Nifor

[Rashi_Vatsa · Accepted solution]

Hello,

Please refer to the firmware with AN65974 (application notes section) https://www.infineon.com/cms/en/product/universal-serial-bus-usb-power-delivery-controller/periphera... . The firmware has flow control that will avoid data loss. 

[Nifor]

Thank you, Rashi.

I applied flow control (handshake to fpga) at project and received perfect data.

Regards,
Nifor

[Rashi_Vatsa]

Hello,

Glad to hear that the issue was resolved!