Re: [libusb] Issue with raspberry pi and libusb_bulk_transfer if buffer size is too big

[David L. <dav...@le...>]

The things that bugs me is that a buffer size of 0x4400 (so an even multiple of 512) will not work on the raspberry. And the device is sending data slowly (less than 1kb/sec) so we have time to read the buffer.

lsusb -v return this if it can give any useful information:

      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0

And on the endpoint 1, I dont have any issue with another buffer of the same size(but the endpoint 1 doesnt stream any data, it just answers to requests).

Thanks again for your time


-----Message d'origine-----
De : Tim Roberts <ti...@pr...> 
Envoyé : 25 juillet 2019 17:04
À : lib...@li...
Objet : Re: [libusb] Issue with raspberry pi and libusb_bulk_transfer if buffer size is too big

David Levy wrote:
>
> Thanks for the answer. Two more questions:
>
>   * I dont have the issue on x86/x64 windows/linux, Is there a
>     difference with the ARM/Raspberry pi ?
>   * A buffer size of 0x3FFF (or anything below 0x4000) works on the
>     rasapberry even if its not a multiple of 512. Does the library
>     only use the highest multiple of 512 ?
>
It "works" in the sense that you haven't seen it crash yet.  The library does not do anything with the buffer sizes (which is why my attempt to blame your problem on the buffer sizes is a bit lame).  The problem happens deeper down.  Let's say the device fills up most of the buffer so that there's only 100 bytes left in the buffer.  The host controller will only schedule enough time in the frame for 100 bytes.  If the device should decide to transfer 512 bytes, which it is allowed to do, it will step on the packets that were scheduled immediately after. That's a bus protocol violation called "babble".  If your packet should happen to be scheduled at the very end of the frame, so that your device overwrites the frame boundary, it can actually cause the USB hub to shut down.

--
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.