Understanding the PKTEND signal for FX2LP

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
mata_4758791
Level 2
Level 2
First like received 10 sign-ins 5 sign-ins

Dear,

   Please help me a little bit for understanding the PKTEND.

   I'm following the below link to extract data from image sensor (code as I made in this post: CY7C68013a 128P vs 56P for image sensor )

Interfacing FX2LP™ with Image Sensor – KBA95736

   Up till now some image sensors works fine. I connect VSYNC to PA0(INT0#) to see the ending time when a frame is finished.  Now I  made a little bit of change (please note OEA=0, FIFOPINPOLAR = 0x07, thus PKTEND active LOW),

    case (1)VSYNC  --> connect to both PA0 & PA6,

    case (2)VSYNC --> connect to PA0;   PA6 tied to 3V3 (HIGH LEVEL)

   In case (1),  hopefully when the VSYNC goes to low level (active low), the last packet will be automatically sent to the computer host; but, anyhow, nothing happened, the results are exactly the same as  case (2).

  This puzzles me a little bit, in the technical reference manual chapter 9.2.5, it is stated that,

If the master wants to send a stream of data whose length is not a

multiple of 512, the last packet is not be automatically com-

mitted to USB because it is smaller than 512 bytes. To com-

mit that last packet, the master can do one of two things: It

can pad the packet with dummy data in order to make it

exactly 512 bytes long, or it can write the short packet to the

FIFO, then pulse the PKTEND pin.

  while in my case it seems letting the PKTEND signal go to low level (active low, thus asserted) has no effect, have I missed something ?

Best regards,

0 Likes
1 Solution

Hello,

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.

Thanks,

Yatheesh

View solution in original post

0 Likes
4 Replies
YatheeshD_36
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello,

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

Thanks,

Yatheesh

0 Likes

Dear Yathee,

      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

void TD_Poll(void){

     // 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?

Best regards,

Matthew

0 Likes

Hello,

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.

Thanks,

Yatheesh

0 Likes

Dear Yathee,

       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.

Great thanks.

matthew

0 Likes