The example code is written:
"
if (success)
{
memset(buf, 0, MAX_PACKET_SIZE_WRITE);

// Check for ACK packet after writing 8 pkts.
while ((buf[0] != 0xFF) && success)
{
success = DeviceRead(buf, 1, &dwBytesRead);
}
}
"

question : when finished to transfer 512 BYTE(8 pkts) data from the Host to the Device, We must be check for ACK packet???

The "PACKET" (MAX_PACKET_SIZE_WRITE) and "ACK" on this code have no direct relation to the USB protocol. These terms belong to the original protocol just for this application, carried over USB. To make it more USB savvy, the "PACKET" should be called as transfer. "ACK" is acknowledge transfer.

This is the first hurdle to understand USB.
I think even the programmer of this code doesn't have clear aspects on this point.

1) Transfer - transaction - packet

Transfer is the greatest unit of communication structure on USB.
USB carries transfer, splitting it into transactions on the bus. The wMaxPacketSize field of the endpoint descriptor determines the size of division unit.

The hardware parts, the host controller and the USB engine (SIE: Serial Interface Engine) on the MCU, interpret transaction into packets, like IN-DATA-ACK or OUT-DATA-ACK.

Host app handles transfer directly, and firmware does in the split shape, a sequence of transactions.

For example, suppose that a host app sends 200 bytes of data. It is sent by single WriteFile (or equivalent call) to the device driver. The device driver and the host controller splits it into transactions, according to the wMaxPacketSize of the endpoint. When wMaxPacketSize = 64, the firmware sees this sequence of transactions, as 200 bytes transfer.

64, 64, 64, 8

In the opposite direction, also, the reverse process is done; the firmware sends a sequence of transactions, they are combined together into a single block, and handed to the host app as a single transfer over single ReadFile().

In this way, any size of transfer is carried over USB, even if it grows up to MBytes.

Therefore,
- You don't see any USB packet or ACK packet on the coding of host app. It is true even on the firmware coding.

- When error occurs on the transfer, ReadFile and WriteFile returns error, either directly (synchronous call), or indirectly (asynchronous call). When these APIs succeed, the transfers succeed without error.

- On the coding of host app, you don't need to be aware of the packet payload size (wMaxPacketSize). It is handled automatically by the host controller.

OK, go one step further.

2) Termination of transfer

USB spec defines the end of bulk and interrupt transfer as follows,

a) Has transferred exactly the amount of data expected
b) Transfers a transaction with a payload size less than wMaxPacketSize or transfers a zero-length packet

5.8.3 Bulk Transfer Packet Size Constraints (usb_20.pdf p53)
5.7.3 Interrupt Transfer Packet Size Constraints (usb_20.pdf p49)

a) Expected transfer size
This is the primary criteria.
The host side always knows the expected transfer size, because any transfer is initiated by the host, regardless of the transfer direction, IN (from device to host) or OUT (from host to device).

For example, these parameters of ReadFile and WriteFile mean the expected transfer size.
ReadFile( ..., nNumberOfBytesToRead, ...)
WriteFile(..., nNumberOfBytesToWrite, ...)

On the other hand, the firmware doesn't know the expected size,
unless the host sends it to the firmware beforehand,
OR, it is documented explicitly as the protocol design.

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.

3) Protocol design

When you design an original protocol carried over USB, you have to make "expected transfer size" always clear for the firmware.

For transfers of fixed length,
Define "expected transfer size" for each type of transfer explicitly, and apply it to both of the host app and the firmware as the common constants in a common header file, or documentation.

For transfers of variable length,
- Send the "expected transfer size" beforehand from the host, using above fixed-length transfer.
OR
- For OUT transfer, the first byte(s) of the transfer holds the transfer size of this transfer.
- For IN transfers, define "expected transfer size" of large enough, and cut off the transfer by a short packet (including ZLP) on the firmware.

Tsuneo

thanks Tsuneo