FX2LP Endpoint2 (IN, BULK) Issue in Slave FIFO mode

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

cross mob
arbhc_3614956
Level 1
Level 1

Hi,

I am using FX2LP to transfer an image captured from an image sensor. It is very similar to Interfacing FX2LP™ with Image Sensor – KBA95736. The VSYNC (Frame Valid) in our setup is connected to PA6 instead of PA0.

Here is the basic functioning of the firmware. As soon as the host makes a vendor request 0xAC, image sensor is woken up from standby and a header packet is sent with Endpoint2 in Manual mode. Then we wait for the PA6 (Frame Valid) to become LOW which means that no data is being transferred over the FD bus. As soon as PA6 goes LOW, we put Endpoint2 in Auto mode. Then, we wait for while PA6 is high. Once, PA6 returns to LOW, we put the image sensor in standby and wait for Endpoint2 Buffer to clear by monitoring EP2CS NPAK bits. But the NPAK bits never become zero. I have tried increasing the length of the bulk transfer initiated by the host but to no avail. The bulk transfer returns timeout with same length as before but the NPAK bits are still not zero.

Kindly, guide me on this.

Below is my TD_Poll Function:

void TD_Poll( void )

{ // Called repeatedly while the device is idle

     if(vendorCmdIssued_AC )     // if Vendor command issued

     {

          IOD &= ~(0x02); // Wake up the image sensor from standby

          //ongoing Transfer

          while(PA6);

          //wait for idle time

          while(!PA6);

          //skip frame

          while(PA6);

          IOD |= 0x04;   // Turn on the LED

   

          while(PA6);  // to insert the header when Frame Valid FV is low. So it will wait if FV is high

   

          EP2FIFOBUF[0]=0xFF;    // 5bytes of Header used by the Preview Utility to detect the Start of Transmission

          EP2FIFOBUF[1]=0x00;

          EP2FIFOBUF[2]=0x0F;

          EP2FIFOBUF[3]=0x00;

          EP2FIFOBUF[4]=0xFF;

          EP2BCH=0x02; //512 bytes committed

          SYNCDELAY;

          EP2BCL=0x00;

          SYNCDELAY;

   

          EP2FIFOCFG = 0x08; //Switching to Auto mode

          SYNCDELAY;

          IOD &= ~(0x02); // Wake up the image sensor from standby

          while(!PA6);

          //actual transfer

          while(PA6);

          IOD |= 0x02; // Put the image sensor in standby mode

          IOD &= ~(0x04);   // Turn off the LED

          while( ( ( (EP2CS & bmBIT6) | (EP2CS & bmBIT5) | (EP2CS & bmBIT4) ) >> 4 ) != 0 )

               DebugBufferPush(( (EP2CS & bmBIT6) | (EP2CS & bmBIT5) | (EP2CS & bmBIT4) ) >> 4);

          FIFORESET = 0x80; // activate NAK-ALL to avoid race conditions

          SYNCDELAY;

          EP2FIFOCFG = 0x00; //switching to manual mode

          SYNCDELAY;

          FIFORESET = 0x02; // Reset FIFO 2

          SYNCDELAY;

          FIFORESET = 0x00; //Release NAKALL

          SYNCDELAY;

     

          EP2BCH=0x02; //512 bytes committed

          SYNCDELAY;

          EP2BCL=0x00;

          SYNCDELAY;

         

          IOD &= ~(0x04);   // Turn off the LED

          IOD |= 0x02; // Put the image sensor in standby mode

   

          vendorCmdIssued_AC=FALSE;    

     }

}

Thanks and Regards,

Arth Bhatt

0 Likes
1 Solution

Hi,

The one packet count after FIFORESET is expected since the mode is being changed to Manual mode and hence only one packet gets committed. I was able to read the packet that we are committing after the reset. However the previous data was also read successfully on the host i.e. if I comment out the part after the monitoring of EP2CS, I am able to see the count getting updated when I read on the host.

Could you please try reading the data using the Control Center application?

Best Regards,

Sananya

View solution in original post

0 Likes
5 Replies
Sananya_14
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hi Arth Bhatt,

-Based on your TD_Poll() function, could you please explain why there is second set of commit statements after the FIFORESET?

-The EP2CS buffer will show empty status and contain no packets when all the bytes committed to the host have been read on the host application. Since you have mentioned that the bulk transfer fails with a timeout error on the host side, it means that the buffer may not have had the required length of bytes when the host requested a read and hence it failed.

Best Regards,

Sananya

0 Likes

Hi SananyaM_56,

I have added a second set of commit statements after the FIFORESET because if I don't add that then I get USB_TRANSFER_ERROR. I do not know the reason for this but  adding these commit statements seem to solve the issue.

You told that the bulk transfer fails with a timeout error on the host side means that the buffer on FX2LP may not have the required length of bytes when the host requested a read. But the EP2CS shows that the buffer is not empty and contains one commited packet which is not read by the host.

Also, I want to understand the behaviour of FX2LP in the following cases:

1) Is there a way to know that the host has initiated an IN-BULK transfer?

2) What happens when we reset a buffer using FIFORESET? Is the buffer cleared or only the byte counts?

3) Is there any way to check overwrite of Endpoint buffer in Autonomous mode? For example, a host does not read the BULK data but the Slave FIFO writes new data to the buffer, and the buffer is full at the time of writing?

Thank You for helping!

0 Likes

Hi,

Could you please check the status of EP2CS after the second set of commit statements? It will only consider the number of packets which are committed to the host so ideally if it shows one packet host should be able to read it and not give any error.

1. You can enable the interrupt for EP2 through the EPIE endpoint which generates an interrupt when host initiates an IN request.

2. FIFORESET will reset the individual FIFO i.e. clear the buffer and restore byte counts to default values.

3. There is no way to check the data overwrite in the firmware but you could check in the host application. For eg, the number of bytes between two frame headers should be the exact expected number of bytes.

Best Regards,

Sananya

0 Likes

Hi,

Thanks again for your reply.

I checked the status of EP2CS after the second set of commit statements and it shows one packet.

Regards

0 Likes

Hi,

The one packet count after FIFORESET is expected since the mode is being changed to Manual mode and hence only one packet gets committed. I was able to read the packet that we are committing after the reset. However the previous data was also read successfully on the host i.e. if I comment out the part after the monitoring of EP2CS, I am able to see the count getting updated when I read on the host.

Could you please try reading the data using the Control Center application?

Best Regards,

Sananya

0 Likes