Problem with Block Throttled pipes

Hi everyone.

I am trying to use a block throttled pipe to control when data is ready.
Basically, the code is really simple: ep_ready signal is set/reset
every 256 cycles, and a counter supplies the data.
Block size is set to 128.

Unfortunately, no data is read by USB.
For some reason, USB fails to assert the ep_read signal (pipe_read).

I am attaching a picture of output of logic analyzer.
The logic analyzer is set to trigger on ep-read going high,
but it never goes high.

If I simply tie the ep_ready signal to ‘1’, there is no problem.
I can read all my data.

Can anyone help me with what the problem might be?

Thank you,
Best regards,

Explore Pavel Kolinko

Unfortunately, USB is asynchronous.
So setting EP_READY does not guarantee that USB will read it immediately.
And it look like the delay is quite significant (+ random as well).

Oh well, time to use a long buffer on the output.


In all cases, the USB host (PC) needs to initiate the transfer. Once you have initiated a transfer from the PC (ReadFromPipeOut), it’s up to the USB microcontroller on the XEM to provide the data.

At this point, it becomes a polling operation between the microcontroller and your HDL. As it polls, if EP_READY is asserted, it will start a read of your blocksize and EP_BLOCKSTROBE will be asserted to indicate that this block read has started.

The response time from EP_READY to EP_BLOCKSTROBE/EP_READ is a polling loop within the microcontroller, so it will have some distribution, but it is generally pretty quick.

I will make some tests for maximum polling time to see what size buffer is needed.


I have a question about microcontroller polling the EP-READY pin.

If an EP_READY = ‘1’, and Cypress uC firmware sees that EP_READY = ‘1’,
does that mean that it will eventually read?
Or does it have to check again for EP_READY = ‘1’ at some point later?


I’m not sure what you mean, exactly, by this question.

Basically, when you start a transfer with ReadFromBlockPipeOut(), the transfer is delayed whenever EP_READY is 0.

The issue is that sometimes firmware does not initiate a read
(indicated by asserting ep_read), even when it most likely has
detected an ep_ready high signal.

That’s why I am wondering if the firmware polls
for an ep_ready on multiple occasions before finally “approving” a read.

Keep in mind that the firmware does not initiate a read. The PC initiates a read and the firmware waits until EP_READY is asserted before initiating a block transfer.

But the firmware isn’t as subversive as you’re suggesting. In other words, it doesn’t make some arbitrary choice about whether to recognize that EP_READY is asserted or not. If it’s asserted when it checks, the firmware will initiate a block transfer.

You said: “even when it most likely has detected an ep_ready high signal”. What makes you think it has detected this and is simply ignoring it?

Thank you for your help.
There was a delay between function calls in C++ that I forgot about
when trying to make measurements. :rolleyes:

I measured the maximum response delay between ep_ready and ep_read to be about 20usec. And minimum delay to be about 8usec.

Based on the 20usec, I can now estimate how large my buffers need to be.

Thank you,