FX3 USB3.0 Endpoint problem

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

cross mob
GiMU_801241
Level 2
Level 2
25 sign-ins 10 replies posted 10 sign-ins

Hi

We are currently using 6 endpoints.

 

F/W : 

#define CY_FX_NUMBER_OF_ADDR_LINES 3

As shown in the figure below, if you use 5 endpoints, it works normally.

Endpoints 0x82 & 0x83 (test only 3800KBps) are transfer rate limited.

 

figure 1

in3_out2.PNG

figure 2

in3_out2_2.PNG

However,
if all 6 endpoints are used, the 0x81, 0x82, 0x83 endpoint stops working.

figure 3

in3_out3.PNG

 

 

question:

Can't I use all 6 endpoints at the same time?

Or is there a problem with the interface of the FX3 device?

 

 

0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.

Hello,

I tried some tests after modifying bulksrcsink example with 6 endpoints. When the streamer is configured with 1 - packets per xfer and 1- xfer per queue, I do not see the failures (tried the tests for 15 mins - snippet attached)

When packets per xfer and xfer per queue are increased, the issue can be reproduced. From this test, it seems that issue is due to the bandwidth limitation of the host controller or host application. 

Please let me know if it is possible for you to create a single host application that does data transfers through 6 endpoints. The reason for asking this is we can narrow down the problem as currently, we are using multiple instances of the streamer application which doesn't seem to be a good practice.

Please refer to this thread for XACT error issue  Solved: Why IN endpoint is always STALLED - Infineon Developer Community  

You can also refer to this thread with a similar issue  Solved: FX3 multiple descriptors - Infineon Developer Community  

Regards,
Rashi

View solution in original post

0 Likes
13 Replies
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello,

Please let me know if all the 6 endpoints work if the packets per xfer and xfer per queue are 1 & 1 or something less than 32 and 16 respectively.

Can you capture USB traces using Wireshark and share the Wireshark traces when the issue is seen with 32 & 16 confguration?

Also, please let me know which firmware example is used for this test

Regards,
Rashi
0 Likes
lock attach
Attachments are accessible only for community members.

Hello

1. Packets per xfer and xfer per queue changed.
However, only 5 endpoints worked.

2. I checked the USB data with wireshark.
I noticed that the endpoint values came out strangely.

fx3_cap.PNG

* The destination address 2.3.x is considered as another USB device.

3. Uploaded Firmware File

 

Is USBD-STATUS-XACT-ERROR a big problem?

fx3_cap_error.PNG

 

 

0 Likes

Hello,

From the Wireshark traces, I can see that the BULK OUT packet size is 32*8192 = 262144 bytes - which is expected but BULK IN transfer packet size is not as expected when all 3 endpoints are used.

Please let me know if any other devices are connected to the host when the issue is seen. Also, is FX3 connected directly connected to the host, or is connected via a hub.

Kindly, let me know if the issue is seen with multiple host PCs

I will try to reproduce the issue at my end and update you soon

Regards,
Rashi
0 Likes

Hello,

1. BULK IN packets are not always sent with MAX length.
FX3 <-> FPGA (FIFO size 32x2048) structure.
If there is data in the FIFO, it is transmitted even if the status is not full.

2. It is directly connected to the USB3.0 port of the PC.
If USB3.0 HUB is used, both BULK IN & BULK OUT may be stopped depending on the type of USB3.0 HUB.

Later, we plan to test using 4PORT USB3.0 HUB (NEXT-505UHP) and CYPRESS's USB3.0 HUB part in between.

3. I tried to check using 6 ENDPOINTs on another PC, but
Perhaps because of the performance of the PC, there was a case where it stopped when using 3 ENDPOINTs.

0 Likes
lock attach
Attachments are accessible only for community members.

Hello,

I tried some tests after modifying bulksrcsink example with 6 endpoints. When the streamer is configured with 1 - packets per xfer and 1- xfer per queue, I do not see the failures (tried the tests for 15 mins - snippet attached)

When packets per xfer and xfer per queue are increased, the issue can be reproduced. From this test, it seems that issue is due to the bandwidth limitation of the host controller or host application. 

Please let me know if it is possible for you to create a single host application that does data transfers through 6 endpoints. The reason for asking this is we can narrow down the problem as currently, we are using multiple instances of the streamer application which doesn't seem to be a good practice.

Please refer to this thread for XACT error issue  Solved: Why IN endpoint is always STALLED - Infineon Developer Community  

You can also refer to this thread with a similar issue  Solved: FX3 multiple descriptors - Infineon Developer Community  

Regards,
Rashi
0 Likes

Hello,

Later, we will create and test the application.
However, at present, it seems that it will take a long time to create an application according to the schedule of the person in charge of the software team.

 Thank you.

 

0 Likes

Hello,

From the result observations, it seems the issue is due to the USB bandwidth provided by the host controller. To confirm this, please try using 4 endpoints ( 1 - packets per xfer and 1- xfer per queue) and let me know if the issue is seen with your PC.

Regards,
Rashi
0 Likes

Hello,

For ENDPOINT OUT, using 1 - packets per xfer and 1- xfer per queue will stop.
If you adjust 32 packets per xfer and 16- xfer per queue to a lower value,
There is a phenomenon of stopping. I don't know why yet.

Figure 1

Inkedxfer1_que1_a_LI.jpg

 

 

However, in the case of 32 - packets per xfer and 16 - xfer per queue, I tested it for about 10 minutes and there was no problem.

Figure 2

xfer1_que1_b.PNG

0 Likes

Hello,

For ENDPOINT OUT, using 1 - packets per xfer and 1- xfer per queue will stop.
If you adjust 32 packets per xfer and 16- xfer per queue to a lower value,
There is a phenomenon of stopping. I don't know why yet.

>> Please let me know if the same USBD_STATUS_XACT_ERROR is seen for this condition and is the behavior same on multiple host PCs?

Also, can you please check if the endpoints 0x01, 0x81, 0x02,0x082 work fine together? Meanwhile i will try to reproduce the issue at my end

Regards,
Rashi
0 Likes

Hello,

For ENDPOINT OUT, using 1 - packets per xfer and 1- xfer per queue will stop.
If you adjust 32 packets per xfer and 16- xfer per queue to a lower value, There is a phenomenon of stopping.

=>
in this case
URB Function: URB_FUNCTION_ABORT_PIPE (0x0002) and
USBD_STATUS_CANCELED (0xc0010000) is displayed.

status_canceled.PNG

in2out2_a.PNG

 

ENDPOINT OUT, using 32 - packets  per xfer and 16- xfer per queue
and 0x01, 0x81, 0x02,0x82 worked fine.

in2out2_b.PNG

 

 

0 Likes

Hello,

I tried reproducing the issue at my end with pkts per xfer = 1 and xfer per queue = 1 but I couldn't see failures for around 20 mins

To understand the issue better, please confirm if you are using the cyusb3 v1.2.3.20 driver and the latest FX3 SDK 1.3.4

To check if there are any PHY or LINK errors, please call CyU3PUsbGetErrorCounts in app thread entry for loop for(;;). You can also try registering for endpoint events using CyU3PUsbRegisterEpEvtCallback for all the three endpoints and check if there are any events triggered when the issue starts

Regards,
Rashi
0 Likes

Hello,

I am using cyusb3 v1.2.3.20 & FX3 SDK 1.3.4.

Could you please share the F/W you used for the test?

 

0 Likes
lock attach
Attachments are accessible only for community members.

Hello,

Please find the attached firmware for testing. Please note you would not need an FPGA to be connected to FX3 for this test.

The firmware reads data from the GPIF interface (without connecting any device to the GPIF interface) and sends out the data to the USB

As the GPIF interface is read by 3 GPIF sockets one after the other, please start the BULK IN 0x81, 0x82, 0x83 together and then start the BULK OUT (0x01, 0x02, 0x03) transfers.

Please provide the UART debug prints when the issue is seen at your end with the attached firmware

Please let me know if any queries on this

Regards,
Rashi
0 Likes