USB stack gives misleading indications when Polling Interval not 1

Discussion in 'Windows Vista Drivers' started by Colin Helliwell, Oct 8, 2005.

  1. I am seeing some incorrect indications from the usb stack (XP SP2) when my
    device indicates a Polling Interval of 2 on its isochronous endpoint:

    My hardware has a high speed (not high bandwidth) iso In endpoint; it
    generates fixed size 1000-byte packets at an interval very slightly over
    I have taken the isousb sample from the 3790 DDK, and adapted it to work
    with my configuration.
    Because of the data rate, it seemed sensible to increase the polling
    interval on that endpoint so as to only poll every other microframe, so I
    set a value of two.
    I use the test app (rwiso) to read an amount of data from the device, and
    the driver output is as follows:
    IsoPacket[0].Length = 0x03E8 IsoPacket[0].Status = 0
    IsoPacket[1].Length = 0x0000 IsoPacket[1].Status = 0
    IsoPacket[2].Length = 0x03E8 IsoPacket[2].Status = 0
    IsoPacket[3].Length = 0x0000 IsoPacket[3].Status = 0
    IsoPacket[4].Length = 0x03E8 IsoPacket[4].Status = 0
    IsoPacket[5].Length = 0x0000 IsoPacket[5].Status = 0
    IsoPacket[6].Length = 0x03E8 IsoPacket[6].Status = 0
    IsoPacket[7].Length = 0x0000 IsoPacket[7].Status = 0
    IsoPacket[8].Length = 0x03E8 IsoPacket[8].Status = 0
    IsoPacket[9].Length = 0x0000 IsoPacket[9].Status = 0
    IsoPacket[10].Length = 0x03E8 IsoPacket[10].Status = 0
    IsoPacket[11].Length = 0x0000 IsoPacket[11].Status = 0
    IsoPacket[12].Length = 0x03E8 IsoPacket[12].Status = 0
    IsoPacket[13].Length = 0x0000 IsoPacket[13].Status = 0
    IsoPacket[14].Length = 0x03E8 IsoPacket[14].Status = 0
    IsoPacket[15].Length = 0x0000 IsoPacket[15].Status = 0
    IsoPacket[16].Length = 0x03E8 IsoPacket[16].Status = 0
    IsoPacket[17].Length = 0x0000 IsoPacket[17].Status = 0
    IsoPacket[18].Length = 0x03E8 IsoPacket[18].Status = 0
    IsoPacket[19].Length = 0x0000 IsoPacket[19].Status = 0
    IsoPacket[20].Length = 0x03E8 IsoPacket[20].Status = 0
    IsoPacket[21].Length = 0x0000 IsoPacket[21].Status = 0
    IsoPacket[22].Length = 0x03E8 IsoPacket[22].Status = 0
    IsoPacket[23].Length = 0x0000 IsoPacket[23].Status = 0

    So this suggests that every other packet is coming back zero-length.
    However, when I look at the entire buffer from the user-space app there are
    no gaps - every piece of data *is* there (and correct) from beginning to
    end - all 24 packets. The return value from the read() call is 12*1000 yet
    the whole buffer has in fact been written.
    I've also used SnoopyPro to examine what the stack thinks the packets
    contain, and diagrammatically (and very much simplified), this is what I'm
    seeing (with "." indicating a zero-length packet):

    According to stack Actually in buffer
    0 1 2 3 0 1 2 3
    .. 4 5 6 7
    8 9 A B 8 9 A B
    .. C D E F
    0 1 2 3 0 1 2 3

    This is a problem to me because I will occasionally get genuine zero-length
    packets (due to the data generation being asynchronous to the usb frames),
    and I need to be able to detect them.
    The USBD_SHORT_TRANSFER_OK flag is not set.

    This only happens when the Polling Interval is 2; when it is set to 1 then
    the behaviour is as expected (albeit interspersed with genuine zero-length
    packets, generated by the h/w when it is polled but has no data available)
    I'm running a free build XP SP2, but with checked versions of ntoskrnl, hal,
    usbport.sys, usbccgp.sys and usbd.sys (also from an SP2 version).

    Is it a bug in the usb stack?
    There is a report of this kind of problem - - but although it is dated only a
    few days ago, it seems to be saying that the issue is fixed in SP2; and I
    have newer versions of all the files indicated (though why don't I have
    usbccgp.sys - isn't that needed for composite devices??)
    [I'm having trouble with my Win2K installation at the moment, so I've not
    had a chance to compare].

    In fact, as I repeat the test today to check my results (before hitting
    "Send"), I'm *also* now seeing an additional effect: a packet with a length
    of 1000, but contents all zero - but, again, without any loss of data -
    where there *is* data in the buffer it is continous and valid (the data
    stream contains a count to help spot discontinuities).
    What with the results I was seeing yesterday plus this additional weirdness
    I'm now seeing, I'm wondering if there are still issues with non-one values
    of polling interval?

    Anyone got any thoughts? Can anyone at MS confirm whether 837371 really is
    Colin Helliwell, Oct 8, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.