Hi, I am using two threads to stream in data via ping-pong operation and using slwr to control the data flow. If the slwr is always low during the data transmission, it works fine and no data missing when the counter limit value is set to 4095. However, if I flip-flop the slwr, it can work well only when I set the counter limit value to 4096. It is impossible for me to use two different values in one application since two cases are possible ( slwr always be low in one setting while flip-flop slwr in the other setting). How to deal with the counter value?
The data bus is 32 bits and the DMA configuration is as following,
//try creating a many to one dma channel CyU3PDmaMultiChannelConfig_t dmaMultiConfig; CyU3PMemSet ((uint8_t *)&dmaMultiConfig, 0, sizeof (dmaMultiConfig)); dmaMultiConfig.size = 16384; //GPIF counters set to 4095 32 bit words dmaMultiConfig.count = 4; dmaMultiConfig.validSckCount = 2; dmaMultiConfig.prodSckId  = (CyU3PDmaSocketId_t)CY_U3P_PIB_SOCKET_0; dmaMultiConfig.prodSckId  = (CyU3PDmaSocketId_t)CY_U3P_PIB_SOCKET_1; dmaMultiConfig.consSckId  = (CyU3PDmaSocketId_t)(CY_U3P_UIB_SOCKET_CONS_0); dmaMultiConfig.prodAvailCount = 0; dmaMultiConfig.prodHeader = 0; dmaMultiConfig.prodFooter = 0; dmaMultiConfig.consHeader = 0; dmaMultiConfig.dmaMode = CY_U3P_DMA_MODE_BYTE; dmaMultiConfig.cb = NULL; dmaMultiConfig.notification = 0; apiRetStatus = CyU3PDmaMultiChannelCreate (&glDmaChHandleMulti, CY_U3P_DMA_TYPE_AUTO_MANY_TO_ONE,&dmaMultiConfig);
The state machine configuration file is attached.
At what point (that is, after filling how much of 16K buffer of socket0/1) do you intend to change the SLWR state? counter value 4096 should not be used - because 0 to 4095 with 32 bit bus width will fill the 16K buffer.
Please provide more details on the issue faced when SLWR is being switched.
Thank Hemanth, the SLWR state changes periodically, like changes every 10 clks. For my case, I use another fifo at the FPGA side. I set SLWR to synchronize with the fifo_empty signal at FPGA, assign slwr = fifo_empty. When fifo is not empty, slwr is valid.
I use counter value 4096 as suggested in the following post:
"Please use the old state machine with 4095 as counter value and new state machine with 4096 counter value"
I have no idea why use different counter values for the old state machine and the new one.
I have another problem. I use 4 DMA buffers, assuming the proper order to read out the data is buffer0, buffer1,buffer2 and buffer3, sometimes (nearly 50%)the data readout order becomes buffer1,buffer0,buffer3,buffer2. The data is not continuous then. I use the streamer to receive the data at PC side. It seemed that the transfer loses sync with the DMA buffers. Any suggestion?
The order in which buffers are committed to USB is: Thread0Buffer0, Thread1Buffer0, Thread0Buffer1, Thread1Buffer1 so on..
The buffers will be committed when they are full (unless you use COMMIT action)
Thanks for your reply.
The received data should be like this. But sometimes I got the data not in that order. I have attached part of the data I received with the streamer on the host PC. The data are generated in the FPGA with 32 bits width Data=Data+1 , at address 0x4000, the data swithes from 0xF0D150FE to 0XF0D130FF which should be 0XF0DA50FF, however, 0XF0DA50FF appears at address 0xc000 . From the attached data, the received order seems as : Thread1Buffer0,Thread0Buffer0,Thread1Buffer1 ,Thread0Buffer1.
I list the first 4 buffers (16384 bytes, 0x4000) with addresses and the corresponding data:
( addr: data)
The data are discontinous, the right order should be B, A, D, C.
Could the Cypress experts give me a hand on the above issue? What might cause this problem? the host program or the FX3 firmware?
To debug the issue, please test the following:
After you start the test, send only one buffer worth data (that is, 16384 bytes) and read the data using control center.
If this successful, send 16384 bytes once more and check.