USB 2.0 High Bandwidth Iso

I am having an issue with a USB 2.0 high-bandwidth iso endpoint. It isn't
behaving the way I expect.

The descriptor for the endpoint has the maximum bandwidth -- wMaxPacketsize
of 0x1400, meaning 1024 bytes with 3 transfers per microframe. I had
assumed that I would use this like any other isochronous endpoint, by
sending it a series of 1024-byte packets, so that each microframe would
consume 3 such packets.

However, that does not seem to be what the host controller driver expects.
I was VERY surprised to find that USBD_PIPE_INFORMATION.MaximumPacketSize
was 3072, not 1024. Further, if I send it a series of 1024-byte packets, I
get USBD_STATUS_INVALID_PARAMETER. It looks as though USBD will only
schedule one URB per microframe.

So why is this a problem? Well, let's say our data is coming in chunks of
2600 bytes, which means 1024 plus 1024 plus 552. We are using an FX2. Our
data rate is lower than the maximum bandwidth. When the FX2 gets an IN
token but its FIFO is empty, it does not reply. When that happens, I will
get a packet with 1024+1024 bytes plus an error, followed by a packet with
552+1024+1024, but those bytes are all packed together. I can't identify
the packet boundaries.

So, is it a fact that USBD will only schedule one URB per microframe? Or
have I missed something?
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Tim
Sat Mar 04 19:00:18 CST 2006

Tim Roberts <timr@probo.com> wrote:
>
>I am having an issue with a USB 2.0 high-bandwidth iso endpoint. It isn't
>behaving the way I expect.
>
>The descriptor for the endpoint has the maximum bandwidth -- wMaxPacketsize
>of 0x1400, meaning 1024 bytes with 3 transfers per microframe. I had
>assumed that I would use this like any other isochronous endpoint, by
>sending it a series of 1024-byte packets, so that each microframe would
>consume 3 such packets.
>
>However, that does not seem to be what the host controller driver expects.
>I was VERY surprised to find that USBD_PIPE_INFORMATION.MaximumPacketSize
>was 3072, not 1024. Further, if I send it a series of 1024-byte packets, I
>get USBD_STATUS_INVALID_PARAMETER. It looks as though USBD will only
>schedule one URB per microframe.

I have a bit more information. The INVALID_PARAMETER error seems to have
been something else. I reduced each URB from 64 packets of 1024 down to 48
packets of 1024, and that error went away. However, I'm now getting
USBD_STATUS_XACT_ERROR on each packet, even those that contain valid data.
Further, the valid data I'm receiving seems to be only the first packet of
the three that should be sent. It fills the 1024-byte packet in the first
transaction, and discards the other two until the next microframe.

So, it looks like further evidence that USBD (or EHCI) will only schedule
one URB per pipe per microframe. That seems like a surprising restriction
to me. Neither the USB 2.0 spec or the EHCI spec mentions such a
restriction.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

HemanshuSrivastava
Tue Apr 25 00:57:01 CDT 2006

Hi Tim,

I am facing exactly same problem. Do you have any clue? Is this resolved?



"Tim Roberts" wrote:

> Tim Roberts <timr@probo.com> wrote:
> >
> >I am having an issue with a USB 2.0 high-bandwidth iso endpoint. It isn't
> >behaving the way I expect.
> >
> >The descriptor for the endpoint has the maximum bandwidth -- wMaxPacketsize
> >of 0x1400, meaning 1024 bytes with 3 transfers per microframe. I had
> >assumed that I would use this like any other isochronous endpoint, by
> >sending it a series of 1024-byte packets, so that each microframe would
> >consume 3 such packets.
> >
> >However, that does not seem to be what the host controller driver expects.
> >I was VERY surprised to find that USBD_PIPE_INFORMATION.MaximumPacketSize
> >was 3072, not 1024. Further, if I send it a series of 1024-byte packets, I
> >get USBD_STATUS_INVALID_PARAMETER. It looks as though USBD will only
> >schedule one URB per microframe.
>
> I have a bit more information. The INVALID_PARAMETER error seems to have
> been something else. I reduced each URB from 64 packets of 1024 down to 48
> packets of 1024, and that error went away. However, I'm now getting
> USBD_STATUS_XACT_ERROR on each packet, even those that contain valid data.
> Further, the valid data I'm receiving seems to be only the first packet of
> the three that should be sent. It fills the 1024-byte packet in the first
> transaction, and discards the other two until the next microframe.
>
> So, it looks like further evidence that USBD (or EHCI) will only schedule
> one URB per pipe per microframe. That seems like a surprising restriction
> to me. Neither the USB 2.0 spec or the EHCI spec mentions such a
> restriction.
> --
> - Tim Roberts, timr@probo.com
> Providenza & Boekelheide, Inc.
>

Tim
Wed Apr 26 23:26:24 CDT 2006

Hemanshu Srivastava <HemanshuSrivastava@discussions.microsoft.com> wrote:
>
>I am facing exactly same problem. Do you have any clue? Is this resolved?

The only "resolution" is to submit the URB with packets large enough to
hold all three transfers. For a maximum bandwidth endpoint, with 3x1024
bytes per microframe, each isochronous URB must contain a multiple of 8
packets of 3072 bytes each.

Once we followed that rule religiously we had few problems.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.