USB max packet size under XP, Vista x86, Win7 x86

Discussion in 'Windows Vista Drivers' started by Bruce Naylor, Aug 5, 2009.

  1. Bruce Naylor

    Bruce Naylor Guest

    Hi all,

    My product transfers an uncompressed video frame either 307200 or 614400
    bytes in size 10 times a second through a Cypress USB2.0 controller. Product
    has been selling over 12 months and all is well. An single async read for the
    full data amount is set up prior to an external trigger (multiple read
    buffers of smaller size never gave a stable result).

    I use KMDF, code was based on the OSR driver example.

    Under Windows XP. No problems.

    Under Vista, the 307200 mode is fine, but 614400 peiodically fails having
    524288 bytes. Hmm, that equates to 1024 x 512!!

    Under Win7, 307200 mode is fine, but 614400 periodically fails having
    transfered 613888 bytes. Hmm that is 614400 - 512!!

    Ok, so I'm doing it wrong - I should be using Video Class etc. But the spec
    says I'm good for 1MB transfers, so why are they dodgy under Vista and Win7?

    Bruce Naylor, Aug 5, 2009
    1. Advertisements

  2. Bruce Naylor

    DamL Guest

    had same problem !
    in fact from Vista, USB stack has reduced possible tranfer sizes in bulk
    to 512KBytes max.

    It was 4MBytes under XP.
    There is nothing to do except reduce your own transfer size (if possible...)

    Bruce Naylor a écrit :
    DamL, Aug 5, 2009
    1. Advertisements

  3. Bruce Naylor

    Bruce Naylor Guest

    Thanks for the reply DamL. Should these issues under Vista/Win7 be resolved
    by having a round-robin of async reads waiting for less than 512k (a solution
    which I never got to work reliably in the past)?

    If so could someone point me in the direction of relevent
    documentation/samples that explain a solid implimentation of this technique
    using KMDF. Data source is unbuffered, so the USB gets the data at 24Mhz
    (with minimal delays at the end of each scanline).

    Many thanks,

    Bruce Naylor, Aug 5, 2009
  4. if you want always pending async reads, use the continuous reader feature on

    Doron Holan [MSFT], Aug 6, 2009
  5. Bruce Naylor

    DamL Guest

    Bruce Naylor a écrit :
    I don't know KMDF well, but indeed solution is to use smaller transfers
    than 512KBytes. With a Cypress (FX2?) data are buffered due to onboard
    fifo insde chip which should be sufficient to allow this technique
    (multi transferring with packets less than 512Kbytes).

    By the way, in former documentations of Vista, Transfer bulk sizes
    should have been ported up to 8MBytes... what a deception this has never
    been done (and will never be. I have already requested microsoft for this.)

    DamL, Aug 6, 2009
  6. Bruce Naylor

    Tim Roberts Guest

    What error do you see in these cases? Are you, in fact, using a bulk pipe
    for your video data?
    Tim Roberts, Aug 10, 2009
  7. Bruce Naylor

    Bruce Naylor Guest

    I took what I thought was the easy route and linked the Cypress via it's GPIF
    to a 10bit micron sensor, coded up some firmware to define 16bit transfers
    via a bulk 4x512byte buffered endpoint, and stream'd the data triggered from
    an external event. All this works fine under XP and is very reliable.

    The errors crop up under Vista/Win7 with numberOfBytesTransferred from a
    call to GetQueuedCompletionStatus after setting up an async read (code was
    designed for multiple bufers, but tests showed that the only reliable
    solution was to have just one buffer large enough to hold the entire frame -
    splitting a frame into 2 or more async read buffers caused occational
    confusion that I never got to the bottom of).

    Been trawling the web looking for examples of a Bulk Continious Reader (my
    "Developing Drivers with the WDF" book doesn't appear to go into enough
    detail) but so far still non the wiser. Has anyone used this aproach
    succesfully (words of encouragement welcome :> )

    Bruce Naylor, Aug 11, 2009
  8. Bruce Naylor

    Tim Roberts Guest

    You're using GPIF, not slave mode? Do you really have time to keep up with
    that? It's hard to remember how incredibly slow that 8051 runs. At the
    max clock rate of 48MHz, you only get about 4 MIPS.
    Most video data goes by isochronous pipe, because you don't have enough
    buffering to survive transmission retries anyway.
    Are you using KMDF? It includes a bulk continuous reader, fully formed and
    ready to go. You'd end up using a single buffer in the driver, filling it
    from the continuous reader, emptying it into the user-mode requests.
    Tim Roberts, Aug 12, 2009
  9. Bruce Naylor

    Bruce Naylor Guest

    By way of GPIF, I use the state machine to pump the data direct to the USB
    dualport buffers, not via CPU. I guess this is what you define as slave mode.

    Yes, KMDF - I love it over the WDM. Last driver I wrote was for Win95 -
    nightmare when working alone with deadlines and blue screens to keep you
    company. The KMDF is so much nicer to work with, but still a fairly steep
    curve, expecially when driver writing is not your day2day work and you hit
    problems a year since the last time you touched the code!

    Will try and devote more time decoding the examples. If anyone has any tips
    or things to watch out for, I'm all ears.


    Bruce Naylor, Aug 12, 2009
    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.