Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
I have modified the SyncSlaveFifo sample to achieve four AUTO channel among PC,FX3 and FPGA, they are:
channel 0 is PC --->FPGA, thread 0, FLAGA is configured to DMA_THREAD0_READY ,polarity is low
channel 1 is PC --->FPGA, thread 1, FLAGB is configured to DMA_THREAD1_READY ,polarity is low
channel 2 is FPGA --->PC, thread 2, FLAGC is configured to DMA_THREAD2_READY ,polarity is low
channel 3 is FPGA --->PC, thread 3, FLAGD is configured to DMA_THREAD3_READY ,polarity is low
Data from channel 0 will loopback to channel 2, so do channel 1 and 3, I call channel 0 and 2 the PairA, 1 and 3 are PairB
Now I'm doing the stress test , when PC pours packets within 2k bytes(more or less) into channel 0, FPGA can loopback these packets to PC through channel 2, so do the PairB. The question is, when PC pours packets into PairA and PairB simultaneously, the PairA works well but PairsB is blocked, whether I pour PairA first or PairB, it's strange.
FPGA tells me when PairB is blocked, the FLAGD is always low, which means the buffer is full, so FPGA can not write in any packets. Then I change the PairB to DMA_CHANNEL_AUTO_SIG. When the PairB is blocked again, I got a CY_U3P_DMA_ERROR notification, which means the DMA encountered a hardware error. I'm not sure why this error occured and how to solve it. Reset the channel in the callback maybe a way but I think it will affect the data rate heavily.
There are three weird things: first is the problem always happend on PairB, not PairA, though they have the same config; second is PairB works well when I pour packets into it independently; third is When PairA is being poured packets, there's no problem if PC send packets in a slow rate to PairB instead of pouring them.