Re: [libusb] Zero Length Packet Issue

[Chermak, D. <dal...@ph...>]

Thanks for the reply Tim!

It's not impossible, as witnessed by the solution you found.  I'm not sure what you were expecting, but the PKTEND pin is exactly the mechanism you use tell the FX2 slave interface that you need a short/ZLP packet at this point.  You do have to set the ZEROLENIN bit in EP6FIFOCFG.

I guess I was hoping there was a way for the FPGA to put the last piece of data into the FX2 *AND* assert the PKTEND pin so that a short ZLP would not have to be sent at all. The ZEROLENIN bit is set in EP6FIFOCFG by the FX2 firmware we are using:

EP6FIFOCFG = 0x4d; SYNCDELAY; // INFM1 = 1, AUTOIN=1, ZEROLENIN=1, WORDWIDE=1

No, you'd expect 4 transfers of 16kB followed by 1 transfer of 1.5kB.  0x10600 = 67,072, which is 16384+16384+16384+16384+1536.

Whoops. Screwed that math up. Serves me right for composing the post across multiple meetings and phone calls.

The 1.5kB of "something" is the missing final piece of your 0x10600-byte transfer.

Right. Which makes the 3KB sitting in what would have been (assuming FIFO ordering on the transfer queue) the next transfer buffer in the queue puzzling. Furthermore, the 1.5KB is in the transfer buffer that received the first 16KB, which (once again, assuming FIFO ordering on the transfer queue) should be another 4 transfers behind the one containing the 3KB.

You need to use a USB analyzer to see whether the device actually sent a ZLP.  That's the only way to determine whether the problem is in the FX2 or in the driver stack.

I'll get that hooked up this afternoon, though I suspect I will see the ZLP being sent.

I ran some additional tests this morning with continuous streaming turned on, though throttled back to limit the streaming to 20 data chunks a second. When the data chunk size is a multiple of 0x200, and the ZEROLENIN bit is set on EP6 the flow of data stops after the first data chunk. I was expecting the data chunks to keep coming, but they don't. However, when the ZEROLENIN bit is *NOT* set on the EP6 the flow of data continues. Mind you, the last 1.5KB of the first data chunk doesn't show up until the first 14.5KB of the second data chunk comes along ~50ms later, but it shows up, and data keeps flowing. Somehow, turning ZLP on is gumming up the works somewhere.

Regards,

Dale

From: Tim Roberts [mailto:ti...@pr...]
Sent: Friday, March 21, 2014 10:23 AM
To: Libusb Mailing List
Subject: Re: [libusb] Zero Length Packet Issue

Chermak, Dale wrote:
Greetings.

I have a 100% reproducible issue I am looking for help with, here are the details:

OS: Linux v3.8 (TI AM335x SDK 06.00)
USB Host: TI AM335x EVM
USB Device: Cypress FX2 based Bulk I/O with a FPGA on the other side of the FX2's Slave FIFO interface.
Endpoints
    0x00/0x80 - Control In/Out

For what it's worth, the default control endpoint is always endpoint 00, and control endpoints are bidirectional.



Everything works fine (I have run the application over weekends with 50Mbits/sec of data streaming over Wi-Fi) except in certain rare USB device configuration scenarios that result in a data chunk size that is a multiple of the FX2 EP6 FIFO buffer size of 0x200. Skipping the long discussion the FPGA designer and I had, it is apparently 'impossible' (so I am told) to fill an FX2 Auto In FIFO buffer *AND* tell the FX2 this is the last piece of data for this data chunk. Therefore, EP6 of the USB device is configured to send a Zero Length Packet (ZLP) when the 'packet end' signal is asserted by the FPGA and no 'new' data has been placed in the current (and empty) FX2 EP6 FIFO buffer.

It's not impossible, as witnessed by the solution you found.  I'm not sure what you were expecting, but the PKTEND pin is exactly the mechanism you use tell the FX2 slave interface that you need a short/ZLP packet at this point.  You do have to set the ZEROLENIN bit in EP6FIFOCFG.



Unfortunately, something is going wrong in the Linux application when a ZLP is sent by the USB device on EP6. In the log that follows the data chunk size is 0x10600, which of course is a multiple of the FX2 EP6 FIFO buffer size of 0x200. In this run, I configured the Linux application to queue up 8 libusb transfers with 16KB buffers to EP6. Note, the EP6 libusb transfers do *NOT* have a timeout, they just wait around for data to arrive. I also configured the USB device for 'triggered mode' instead of 'streaming mode', which means it only sends 1 data chunk and then waits to be asked to send another.  This is fine in this scenario as the entire first data chunk isn't even making it into the Linux application libusb transfer buffers anyway.

What I would expect to get in my EP6 callback would be 4 libusb transfers of 16KB followed by 1 libusb transfer of 3KB.

No, you'd expect 4 transfers of 16kB followed by 1 transfer of 1.5kB.  0x10600 = 67,072, which is 16384+16384+16384+16384+1536.



The EP6 callback gets the 4 libusb transfers of 16KB but *NOT* the 1 libusb transfer of 3KB. ... Even more strange, in this case, there is another 1.5KB of 'something' sitting in the 'next' libusb transfer in line. I say 'in this case', because I have also captured logs where there is 2KB and 1KB in these 'next' libusb transfers, which at least makes some sense, since only 3KB should be coming in. I have no idea where the 1.5KB of 'something' came from as my FPGA designer insists the FPGA did not write it to EP6 via the Slave FIFO interface.

The 1.5kB of "something" is the missing final piece of your 0x10600-byte transfer.

You need to use a USB analyzer to see whether the device actually sent a ZLP.  That's the only way to determine whether the problem is in the FX2 or in the driver stack.


--

Tim Roberts, ti...@pr...<mailto:ti...@pr...>

Providenza & Boekelheide, Inc.

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.