TI E2E Community
usb_dev_bulk cannot Bulk IN exactly maximum packet size?
Does this problem have to do with libusb-1.0's zero length packet (ZLP) issue? (How) can I work around this in firmware? The library code for libusb is LGPL, so I don't have much flexibility to modify it...
libusb_bulk_transfer( handle, bulk_in_endpoint, buffer, 64, // maximum bytes to read IN &bytesTransferred, timeout);
This no longer times out! But bulk IN(65 or more bytes) will now require the host to request additional bulk IN transfers, and host/device code must be coordinated appropriately...but at least my libusb-1.0-based code no longer hangs
After perusing the libusb-1.0 mailing lists a bit, I'm pretty convinced that the workaround above is just that, a workaround, and that the StarterWare usb_dev_bulk example firmware does not fully comply with the USB 2.0 specification, section 5.8.3
In particular, for bulk IN transfers that are exact multiples of wMaxPacketSize (the FIFO size), StarterWare is not following up with a packet of zero length
I've tried some simple patches (try to schedule a transmission of 0 length in RxHandler or TxHandler) to no avail. Any thoughts or suggestions, or corrections? I'd love to be wrong about this..
The problem was reproduced using native WinUSB, so it is definitely not endemic to libusb-1.0 (original post edited).
This post assumes wMaxPacketSize == 64.
The biggest piece of circumstantial evidence is that a virtual loopback device [DSF loopback device from the Windows Driver Kit described here.] does not require the bulk IN workaround posted above; instead, a bulk OUT workaround seems to work:
libusb_bulk_transfer(handle, endpointOut, buffer, numBytesOut, &actualBytes, timeout);if (numBytesOut % 64 == 0) libusb_bulk_transfer(handle, endpointOut, buffer, 0, &actualBytes, timeout);lib_bulk_transfer(handle, endpointIn, buffer, 1000, &actualBytes, timeout);
The extra transfer sends an extra zero-length packet ("ZLP") to terminate the bulk OUT. Is this necessary? In any case, the bulk IN no longer times out for the virtual loopback device. This workaround, however, does not work for my EVM running StarterWare's usb_dev_bulk...
Is this the "correct" host code for communicating with a generic bulk device, or is the DSF loopback virtual device "incorrectly" parroting back an extraneous ZLP? ("Correctness" being measured against the USB 2.0 specification)
On a side note, debug output shows my EVM receives the 64 bytes and transmits it back...
Basically the question now is, on the PC host side, should I:
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.