Problem with the counter limit value using slwr to control the fifo data in

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
wexi_4711301
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

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 [0]  = (CyU3PDmaSocketId_t)CY_U3P_PIB_SOCKET_0;
dmaMultiConfig.prodSckId [1]  = (CyU3PDmaSocketId_t)CY_U3P_PIB_SOCKET_1;
dmaMultiConfig.consSckId [0]  = (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.

 

0 Likes
7 Replies
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi,

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.

Regards,  

Hemanth
0 Likes

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:

https://community.cypress.com/t5/USB-Superspeed-Peripherals/Not-able-to-get-continuous-data-using-tw...

"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.

@Rashi_Vatsa 

 

0 Likes
wexi_4711301
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

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?

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi,

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)

Regards,

Hemanth
0 Likes

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)

A: (0x0000:0xF0D140FF)

B: (0x4000:0xF0D130FF)

C: (0x8000:0xF0D160FF)

😧 (0XC000:0XF0D150FF)

The data are discontinous, the right order should be B, A, D, C. 

Any ideas?

0 Likes

Could the Cypress experts give me a hand on the above issue? What might cause this problem? the host program or the FX3 firmware?

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi,

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. 

Regards,

Hemanth
0 Likes