When the PKTEND (PA6) signal goes low the FIFO buffer will be committed to the USB side.
In your case, if the PKTEND is asserted, a zero length packets are sent to the host only if there are buffers available. Else nothing happens.
When PA6 is tied high, it behaves normally without short packets or zero length packets being committed.
When PA0 is shorted with PA6, the zero length packets or the short packets are sent only when there is buffers available on the interface side.
In your case when the PKTEND is asserted low, the buffers are already full and is committed to the USB side or a zero length packet is committed.
As per the KBA the last buffer is committed when PA0 is pulled high. Hence you will have to change the polarity of the PKTEND to active high to commit the last packet automatically without changing to manual mode.
You can also refer to this KBA: The function of PKTEND pin
Sorry that I didn't explain my problem correctly (ref code: CY7C68013a 128P vs 56P for image sensor ).
For image sensor MT9V034, if I use PA0/INT0# to trigger the frame_init() function, the program will get stuck somehow (for OV7725 the program will NOT stuck). So my purpose is use the PKTEND signal and frame_init() was removed completely, the TD_Poll does nothing, as below
// this function is empty now
Now I have to rely on the PKTEND signal to commit the short packet.
When I open the visual studio debug, I see that the transfer are always 16384 (=32Packets * 512Bytes).
Let's take an example 640*480 = 307200 = 18*16384 + 12288 bytes, it should be 18 transfers with 13684 bytes each, and the last transfer should be 12288.
If I use my frame_init function, the last transfer will be exactly 12288. Somehow the mt9v034 has a resolution of 752*480 = 705Packets*512Bytes (somebody says it is actually 752x481 by default, I have no idea), which got stuck with this frame_init() function (problem with EP2BCL?). Thus, I suppose if PKTEND can commit the buffer, I don't need to rely on EP2BCL.
I used different polarities for PKTEND, the results are the same, each transfer is 16384 exactly, while my expectation is that we should get (22 transfer * 16384 bytes + 1 short transfer * 512 bytes) = 752*480bytes in the streamer. The last transfer should be 512 bytes so I can be informed that this is the last transfer. Currently I have no idea about how to get the beginning or ending of the frame. How can I realize this task?
Packet end will be useful only when the last buffer is not a multiple of 512 or 1024. In your current code you are setting
EP2CFG = 0xE0; // enabled, quad buffered, 512B, IN, bulk fifo, 4 buffer(Page 347)
which is 512 byte FIFO buffer.
Each committed buffer will be 512 and not 16384. Since 12288 is also a multiple of 512 and 1024, PKTEND will not make any difference in committing the last packet as the channel is set in AUTO mode and the 512 byte (last) buffer will be committed as soon as it is filled.
Please use the USB analyzer (hardware or software) to capture USB traces between USB host and FX2LP.
In this case you will see the last transfer with less than 16384 bytes depending on the URB created from the host driver.
I understand your explanation. The transfer in my explanation means for windows driver transfer.
I assume that, if the packet is committed as soon as possible, the time from the last packet (even it is 512bytes) to next beginning will be rather long, thus the streamer will only get 512 bytes and we know it is the last tranfer of one frame; it didn't wait for the next packet, which belongs to the next new frame, to make 16384 bytes as a stuffed transfer.
It seems I missed something in understanding windows OS and I need more test to see the windows API. I tested a couple of days, currently no much success, I still cannot depend on the PKTEND signal to mark the ending of a frame.