Reading 1024 bytes from mass storage device using 3 frames gives USB_ERR_STALLED
Aman Sawrup
aman.sawrup at bluecoat.com
Sat Feb 9 00:16:24 UTC 2013
Hi Hans,
Thanks very much for your help. This mass storage device does indeed
have wMaxPacketSize of 512.
(gdb) p *xfer->endpoint->edesc
$6 = {
bLength = 0x7,
bDescriptorType = 0x5,
bEndpointAddress = 0x81,
bmAttributes = 0x2,
wMaxPacketSize = "",
bInterval = 0xff
}
(gdb) x /xh xfer->endpoint->edesc.wMaxPacketSize
0x6dba0616: 0x0200
Thanks again,
Aman
On 13-02-08 06:01 PM, Hans Petter Selasky wrote:
> On Friday 08 February 2013 22:48:02 aman.sawrup wrote:
>> Hello,
>>
>> We have ported the FreeBSD USB stack to my employers proprietary RTOS. The
>> code was taken from the MAIN branch a little while after RELENG_8_BP tag
>> was created.
>>
>> I'm trying to read data from the following mass storage device umass0:
>>
>> ehci0: [FILTER+ITHREAD]
>> usbus0: EHCI version 1.0
>> usbus0: 480Mbps High Speed USB v2.0
>> ugen0.1: <Intel EHCI root HUB> at usbus0
>> uhub0: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
>> uhub0: 2 ports with 2 removable, self powered
>> ugen0.2: <vendor 0x8087 product 0x0024> at usbus0
>> uhub1: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2> on
>> usbus0
>> uhub1: 8 ports with 8 removable, self powered
>> ugen0.3: <ATP Electronics ATP IG eUSB> at usbus0
>> umass0: <ATP Electronics ATP IG eUSB, class 0/0, rev 2.00/11.00, addr 3> on
>> usbus0
>> umass0: SCSI over Bulk-Only; quirks = 0x4800
>>
>> Reading data one frame per transfer works. For example, if I want to read
>> 512 bytes that is physically contiguous and is placed in a single frame,
>> that works fine.
>>
>> However, when attempting to read 1024 bytes, that is not physically
>> contiguous, using 3 frames for the same transfer, I get USB_ERR_STALLED. I
>> have the frames setup as follows:
>> frame[0] = 200 bytes
>> frame[1] = 512 bytes
>> frame[2] = 312 bytes
> Hi,
>
> The frame lengths must be a multiple of the wMaxPacketSize (typically 64 or
> 512). Each frame is encoded like one or more USB packets independent of the
> next one. I.E. USB packet data may not cross a frame. This is not supported by
> the EHCI/OHCI and UHCI hardware, and the USB stack will not make a fixup
> buffer for this. The USB stack returns the device independent multiplier
> length for this purpose when calling usbd_xfer_max_framelen(). Only when
> (frame[n] % usbd_xfer_max_framelen() == 0) it will work like you want.
>
> --HPS
More information about the freebsd-usb
mailing list