Minimum BTPipeIn length

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.

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.

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.

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!

I recently switched from USB2 to USB3 modules and sure the difference in the Pipe transfer size multiple “is documented” but consider this my vote for a better error code than -15 “UnsupportedFeature” when the Pipe transfer length is not correct. How about -20 “InvalidParameter” or better yet a new error code -21 “Pipe Transfer must be a multiple of 2 bytes for USB2, 16 bytes for USB3, and 8 bytes for PCIe”.

1 Like