Data returned by FinishDataXfer() in a host application using the cyusb3 driver – KBA229186

Version 3

    Author : HemanthR_06          Version: **

     

    Translation - Japanese: cyusb3ドライバーを使用してホストアプリケーションのFinishDataXfer()から返されるデータ - KBA229186 - Community Translated (JA)

     

    Question:
    What is the difference between data returned by FinishDataXfer() for Bulk and Isoc asynchronous transfers in a host application using the cyusb3 driver?

    Answer:
    Asynchronous data transfers are done using the BeginDataXfer(), WaitForXfer(), and FinishDataXfer() APIs.

    This article discusses the applications consuming the data received from FinishDataXfer() in the case of Bulk and Isoc endpoints. BeginDataXfer() creates a USB Request Block (URB) and the data can be obtained in the application from FinishDataXfer().

    For the API description, refer to {FX3 Installation Path}\EZ-USB FX3 SDK\1.3\doc\SuiteUSB\CyUSB.NET.pdf

    The C# Streamer example in the EZUSB_FX3_SDK uses these APIs to acquire data from the device. The following discussion refers to this example for a USB3 device.


    Case 1:
    Bulk endpoints

    Consider the following configuration:

    • The endpoint companion descriptor for the Bulk endpoint has a burst value of 4.
    • Number of packets per Xfer (PPX) in the streamer application is 8.

    For this configuration, EndPoint.MaxPktSize is 4 * 1024 = 4KB. Here, 4 is the burst value; 1024 is the maximum USB PacketSize for the Bulk endpoint.

    BeginDataXfer() will create URB for 32KB: 8 * 4KB (The factor 8 is PPX). This transfer will be complete when one of the following occurs:

    • A short USB packet (packet size less than 1024 bytes) is received.
    • A zero-length packet (ZLP) is received
    • All 32KB data is received.

     

    Case 2: Isoc endpoints

    Consider the following configuration:

    • The endpoint companion descriptor for the Bulk endpoint has a burst value of 4.
    • Let the Mult setting be 2.
    • Number of packets per Xfer (PPX) in the streamer application is 8.

    For the above configuration, EndPoint.MaxPktSize is 4 * 2 * 1024 = 8KB. Here, 4 is the burst value; 2 is mult; 1024 is the maximum USB PacketSize for the Isoc endpoint.

    BeginDataXfer() will create URB for 64KB: 8 * 8KB (The factor 8 is PPX). The transfer in this case ends when all the packets are received – the packets received can include ZLP/short packet/full packet. In the above example, the URB is for 64KB; therefore, the number of packets expected is 64. When the transfer is complete, the 64 packets will be a combination of ZLP/short packet/full packet.

    Attached is an example firmware that sends data buffers of length 8K. The sequence in which the device sends data in this example is as follows: one buffer of data, delay on USB bus, two buffers, delay, three buffers, delay, 1 buffer, and so on. But when three buffers are sent, the second of the three buffers will be a short packet. Since there are eight 1024 packets in one buffer, the first byte of each packet is indexed starting from 0x00.

    A modified C# Streamer application example is also attached, which writes the data (first byte of each USB packet except ZLP) returned from FinishDataXfer() into a file. When you click the ‘Start’ button in the application, the FinishData.bin file will be created in the same directory where the application is present. If a file with this name already exists, then it will be deleted and created again. When the ‘Stop’ button is clicked, the file is closed.

    The following data is written when the above configuration of Isoc endpoint is selected:

    Untitled.png

     

    In this figure:

    1. 0xaa is a marker to indicate the start of FinishData.
    2. 0xcc indicates that the packet contains all ZLPs.
      Note: As mentioned earlier, 0xaa and 0xcc are not part of data received.
    3. The first line has 24 indices from 0x00 to 0x17 indicating 24 1024-sized packets, which amounts to 24KB. There are five 0xcc markers amounting to ZLPs in place of 5 * 8KB (that is, 40 ZLPs from the device). This sums up to 64KB, which was requested per Xfer.
    4. In the last box of the above figure, the index on the first packet of the second Xfer is 0x38 (which is from the short packet). Note that the remaining seven packets of the second Xfer are ZLPs.

    For better understanding of the above log, refer to the attached Streamer application source along with attached firmware.