Fx3 Streaming dropped packets?

[Anonymous]

We are working on a project that requires constant streaming of data from the GPIFII port. We are trying to read a byte of data at precisely 10MHz (provided by an external crystal signal to the pclk pin) and store the data on the pc for processing later. We hope to record for at least a few minutes where timing and sampling must be guaranteed (i.e, no dropped samples). However, what we are noticing is that every 8192 bytes the fx3 device seems to ‘skip’ a few samples and thus data is lost.

For this code we are using a slave fifo and are using the thread ping-pong structure.

It seems to me that the fx3 is waiting until all the buffers are filled then sending it via USB to the computer(?) if that is the case is there a way around this?

Any tips would be greatly appreciated

Thanks!

[Anonymous]

Additional information:

Ive hooked the device up to a pattern generator where i am toggling the pclk at 1Mhz and incrementing a counter on DIO[0:7] at 100kHz. Plotting the data i get this:

The 'skips' are at the 4kB boundary, i.e 4096, 8192.... etc.

Thoughts?

[abhinavg_21]

Hi,

It is because of the thread switching delay. When DMA buffer associated with one THREAD gets exhausted then switching of thread occurs which took time. You can check by increasing buffer size associated with each thread.

Thanks & Regards

Abhinav

[Anonymous]

Hi,

It is curious because this effect even presents itself should i increment at a very low rate (10s of Hz).

My goal was to use socket switching which has zero latency, which i believe I was using in this case (I have mapped two different threads to two unique sockets here). If i am in fact using thread switching rather than socket switching, how do i ensure that i am using socket switching?

Jason Y.

[KandlaguntaR_36 · Accepted solution]

You have set Counter Limit to 4094 and data bus to 8bit bus.

And the  DMA buffer size is set to 8KB = 8192 Bytes.

As per the GPIF state machine, the socket will be switched after every 4095 bytes of data. This means that the socket 4095 bytes out 8192 bytes of a buffer is filled.

Next it goes to another socket, then fills 4095 bytes then switch back to first socket, then it starts filling the rest of the buffer (4095 + 4095 = 8190 bytes) then goes to second socket.

1. Increase the counter limit to 8191 and test.

It is expected that the socket switch happens once the first buffer of socket 1 is full(8192 bytes are received). Then it starts filling the second socket.