This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Bulk transfer problem at Windows 2000 sp4

I am developing some usb device on LPC2141 using CDC ACM class.
Main problem is that I need to handle both XP and 2k system using usbser.sys.
Almost everything works fine, enumeration, line control requests,
modem status events, out transmissions, but I have problem with IN transfers on win2k.
I tried 5.0.2195.6655 (sp4) and 5.0.2195.7006 (KB838417) usbser drivers and both act same way:
small IN transfers (smaller than ep size) works fine. Problem occurs when I try to
send larger amount of data (divided in ep size transfers + rest of data).
Windows receives only first (ep size) chunk of data, but if I close and open com port again the missing data pops out.
I am using modified stack (to handle LineControl and ModemStatus) based on an10420 with ZLP after ep size transmission.
I tried adding ZLP after every last chunk of data, but it doesn't change anything.
Does anyone know how to handle data transfers in win2k.
Please help...

Best regards
Krzysztof

Parents
  • I don't know much about this. But I think that you may need to remove some unnecessary ZLP.

    See: (Tsuneo Chinzei's Article)

    www.cygnal.org/.../001627.html

    b) Short packet
    This is the secondary criteria.
    Short packet means a transaction shorter than wMaxPacketSize, including ZLP (Zero-Length Packet).
    As above example shows, each transaction on a transfer has wMaxPacketSize of data, until the last one. A short packet appears at the end of transfer.

    Using short packet, the firmware can cut off the transfer, before the transfer size reaches to the expected size. When the transfer size is just the multiple of wMaxPacketSize, ZLP is appended to the transfer to stop the transfer in halfway.

    For example, the host app requests 200 bytes transfer,
    nNumberOfBytesToRead = 200;
    ReadFile( ..., nNumberOfBytesToRead, ...);

    But the firmware returns 128 bytes (wMaxPacketSize = 64),
    64, 64, ZLP

    ZLP is appended because the firmware cuts off the transfer.

    However, the host app requests just 128 bytes here, no ZLP is appended, because it matches to the expected size.

    nNumberOfBytesToRead = 128;
    ReadFile( ..., nNumberOfBytesToRead, ...);
    64, 64 (no ZLP)

    Please note, ZLP is seen just for IN transfers, not for OUT transfers, because host always sends just the expected size of OUT transfers. No way to stop it without error.

Reply
  • I don't know much about this. But I think that you may need to remove some unnecessary ZLP.

    See: (Tsuneo Chinzei's Article)

    www.cygnal.org/.../001627.html

    b) Short packet
    This is the secondary criteria.
    Short packet means a transaction shorter than wMaxPacketSize, including ZLP (Zero-Length Packet).
    As above example shows, each transaction on a transfer has wMaxPacketSize of data, until the last one. A short packet appears at the end of transfer.

    Using short packet, the firmware can cut off the transfer, before the transfer size reaches to the expected size. When the transfer size is just the multiple of wMaxPacketSize, ZLP is appended to the transfer to stop the transfer in halfway.

    For example, the host app requests 200 bytes transfer,
    nNumberOfBytesToRead = 200;
    ReadFile( ..., nNumberOfBytesToRead, ...);

    But the firmware returns 128 bytes (wMaxPacketSize = 64),
    64, 64, ZLP

    ZLP is appended because the firmware cuts off the transfer.

    However, the host app requests just 128 bytes here, no ZLP is appended, because it matches to the expected size.

    nNumberOfBytesToRead = 128;
    ReadFile( ..., nNumberOfBytesToRead, ...);
    64, 64 (no ZLP)

    Please note, ZLP is seen just for IN transfers, not for OUT transfers, because host always sends just the expected size of OUT transfers. No way to stop it without error.

Children
No data