Minimum BTPipeIn length


#1

I am testing an XEM6310MT board with software written in C# on a 64bit Windows 7 machine.
I have tried to send different lengths of data through the BTPipeIn interface using:
m_dev.WriteToBlockPipeIn(PIPE_IN_ADDRESS, blocksize, length, testArray);
In firmware the ready signal is tied to ‘1’ and the data bus and write signal are connected to Chipscope.

What I have found is that certain values for blocksize and length will not work.
I am triggering on the write signal out of the BTPipeIn entity.
blocksize–length
1024--------1024 (works)
512----------102 (works)
16-----------64 (works)
8-------------64 (Doesn’t work)
4-------------64 (Doesn’t work)

Should I expect this behaviour?
The documentation shows block lengths down to 4 bytes i.e. 1x32bit word.


#2

Ok, so I’ve found that the BTPipeIn interface can only do multiples of 16 bytes for USB3.0.
I guess I’ll have to mop up the remainder of transfers with WireIn interfaces.


#3

These limits are described in the API documentation.

I may be easiest to pad your data to the next block size rather than use wires to “mop up the rest” as you say.


#4

Thank you!

What I’ve decided to do is use one pipeIn for the main bulk of data.
A second pipeIn is used for the remaining data. The first 4 bytes define the number of valid bytes to follow. The first 4 bytes also hold flags to be written along with the last valid data.

The data buses from of the two pipIns are then multiplexed into a FIFO.
I am assuming that the first pipeIn will be complete before the second starts!