CYUSB3014 stalls / freezes during bulk in transfer

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

cross mob
lock attach
Attachments are accessible only for community members.
GergelySimon
Level 1
Level 1
5 sign-ins First reply posted First question asked

Hi there,

We are seeing an issue with our design that is very similar to

Solved: CYUSB3014 freezes during Slave FIFO transfer - Infineon Developer Community

Solved: Re: How to debug device stall - Infineon Developer Community

Solved: FX3 Superspeed communication fails on link errors - Infineon Developer Community

however none of the above provides a definite answer.

 

Let me outline the test design, that is basically your slave FIFO example: we have an FPGA interfacing with the controller, and that FPGA pushes 4096x32 bits into the controller whenever a DMA buffer becomes available (both FLAGA and FLAGB high). The USB controller FW only has an additional IIC block, otherwise identical to the example files. Attached the modified .h and .c files. On the PC side we try to do continuous bulk IN transfers either with our c# software or your Streamer app.

 

What we see is the following:

In most cases (4 out of 5 or so) there are no issues and transfer progresses continuously at the expected 380 MBps or similar speed, for extended periods of time (tens of minutes).

In other cases the controller seems to initialize in a "strange" state. Not sure whether this is Windows10 or driver or FW or electronics issue, but the above bulk IN transfer fails after a few seconds or tens of seconds, stalling/freezing the controller. Soft reset temporarily resolves the issue and data transfer continues, but to fail again and again after short periods of time. What I found to resolve the problem is a hard reset of the controller (either pin C5 or CyU3PDeviceReset(CyFalse);) followed by a reprogram.

 

My questions:

1. Could you please advise on what causes this issue and how to solve it without having to hard reset?

2. Am I right saying that reset via pin C5 and CyU3PDeviceReset(CyFalse); are *exactly* the same or are there any differences between these?

 

Many thanks in advance,

Gergely

 

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

Hello Gregely,

Thank you for the update.

From your response, I understand that you are seeing CYU3P_USBEP_SS_RESET_EVT &  CYU3P_USBEP_SS_RETRY_EVT events.

Please refer to point IV of section 2.3 of FX3_trouble_shooting _guide of FX3 SDK to understand the reason of these events and the workaround.

From the Wireshark logs shared by you it seems that URB_FUNCTION_ABORT_PIPE is the equivalent of CY_U3P_USB_SC_CLEAR_FEATURE

You can use the GPIFtoUSB example to check if clear feature request is received at the instance (attached snippet)

 

Regards,
Rashi

View solution in original post

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

Hello Gergely,

To understand the issue better, please help me to the following:

- As in the pointed threads, are you seeing CYU3P_USBEP_SS_RESET_EVT/CYU3P_USBEP_SS_RETRY_EVT events?

- Is the issue seen with USBBulkSrcSink example firmware also? If yes, please share the UART debug prints for the same. This will help us to know if the issue is dependent on firmware or not.

2. Am I right saying that reset via pin C5 and CyU3PDeviceReset(CyFalse); are *exactly* the same or are there any differences between these?

>>CyU3PDeviceReset(CyFalse) is a hard reset similar to doing a reset using C5 (RESET) pin

Regards,
Rashi
0 Likes
lock attach
Attachments are accessible only for community members.
GergelySimon
Level 1
Level 1
5 sign-ins First reply posted First question asked

Hi Rashi,

Many thanks for your reply.

I managed to make the required changes to the firmware files to gather data.

>>> As in the pointed threads, are you seeing CYU3P_USBEP_SS_RESET_EVT/CYU3P_USBEP_SS_RETRY_EVT events?

Added a callback function and registered it in the main thread as shown in the cyfxgpiftousb example. When running the Streamer, and restarting a few times and it eventually fails, I see the following print:


▒▒▒
Debug start▒▒▒
Debug start▒▒▒
Debug start▒▒▒
Debug start▒▒▒
Debug start▒▒EP Event: ep=81 event=16
▒▒Halting USB Streaming EP: 0

I attached the modified FW files

>>>  Is the issue seen with USBBulkSrcSink example firmware also? If yes, please share the UART debug prints for the same. This will help us to know if the issue is dependent on firmware or not.

Yes, I could reproduce the issue. Attached zip has a "usb_debug_print_bulksrcsink.txt" file that contains the printouts from three consecutive tests. Attached also the source files and IMG file I used to program the chip with.

>>> CyU3PDeviceReset(CyFalse) is a hard reset similar to doing a reset using C5 (RESET) pin

Thanks for clarifying.

 

Please let me know your suggestions after reviewing this data.

Best wishes,

Gergely

0 Likes

Hello Gregely,

I understand that you are using the default gpiftousb example of the FX3 SDK. Is that correct?

From the usb_debug_printbulksrcsink.txt, I could only see that multiple enumerations takes place but there are no failures seen. Please capture complete UART logs when issue is seen.

Debug start▒▒EP Event: ep=81 event=16

>> In the debug prints hared by you, I can see that CYU3P_USBEP_SS_RETRY_EVT event has occurred. I understand all these tests are done using Streamer application, is my understanding correct? If yes, please put a debug print in handling of CY_U3P_USB_SC_CLEAR_FEATURE and let me know if clear feature is sent by the host when endpoint is stalled.

If possible, please share the USB traces using Wireshark when the issue is seen and also corresponding UART debug prints

Regards,
Rashi
0 Likes
GergelySimon
Level 1
Level 1
5 sign-ins First reply posted First question asked

Hi Rashi,

 

To clarify, I have used two FW tests (in both cases the PC software was your Streamer.exe):

1. Our own firmware (source files included in one of the previous messages):

This was originally a modification of the "slavefifosync" example, with adding IIC. I only mentioned the gpiftousb example because I used it as an example to implement the event monitoring callback in the exact same way. Now I have further modified it to add a debug print within 

if
((bTarget == CY_U3P_USB_TARGET_INTF) && ((bRequest == CY_U3P_USB_SC_SET_FEATURE)
|| (bRequest == CY_U3P_USB_SC_CLEAR_FEATURE)) && (wValue == 0))

and within

if ((bTarget == CY_U3P_USB_TARGET_ENDPT) && (bRequest == CY_U3P_USB_SC_CLEAR_FEATURE)
&& (wValue == CY_U3P_USBX_FS_EP_HALT))
{

to monitor the clear feature as you requested. When the streaming fails, I see the exact same debug print as before:

▒▒▒
Debug start▒▒EP Event: ep=81 event=16
▒▒Halting USB Streaming EP: 0

I have also seen

▒▒▒
Debug start▒▒
P Event: ep=81 event=256
▒▒Halting USB Streaming EP: 0

 

So I do not think there is a clear request. This example did not have any other debug prints in it, so please let me know if you want me to add any extra.

The relevant wireshark dump (highlighted where a partial packet is transferred):

1 0.000000 host 2.2.0 USB 36 GET DESCRIPTOR Request DEVICE
2 0.000000 2.2.0 host USB 46 GET DESCRIPTOR Response DEVICE
3 0.000000 host 2.2.0 USB 36 GET DESCRIPTOR Request CONFIGURATION
4 0.000000 2.2.0 host USB 59 GET DESCRIPTOR Response CONFIGURATION
5 0.000000 host 2.2.0 USB 36 SET CONFIGURATION Request
6 0.000000 2.2.0 host USB 28 SET CONFIGURATION Response
7 0.000000 host 2.56.0 USB 36 GET DESCRIPTOR Request DEVICE
8 0.000000 2.56.0 host USB 46 GET DESCRIPTOR Response DEVICE
9 0.000000 host 2.56.0 USB 36 GET DESCRIPTOR Request CONFIGURATION
10 0.000000 2.56.0 host USB 72 GET DESCRIPTOR Response CONFIGURATION
11 0.000000 host 2.56.0 USB 36 SET CONFIGURATION Request
12 0.000000 2.56.0 host USB 28 SET CONFIGURATION Response
13 0.000000 host 2.47.0 USB 36 GET DESCRIPTOR Request DEVICE
14 0.000000 2.47.0 host USB 46 GET DESCRIPTOR Response DEVICE
15 0.000000 host 2.47.0 USB 36 GET DESCRIPTOR Request CONFIGURATION
16 0.000000 2.47.0 host USB 59 GET DESCRIPTOR Response CONFIGURATION
17 0.000000 host 2.47.0 USB 36 SET CONFIGURATION Request
18 0.000000 2.47.0 host USB 28 SET CONFIGURATION Response
19 0.000000 host 2.48.0 USB 36 GET DESCRIPTOR Request DEVICE
20 0.000000 2.48.0 host USB 46 GET DESCRIPTOR Response DEVICE
21 0.000000 host 2.48.0 USB 36 GET DESCRIPTOR Request CONFIGURATION
22 0.000000 2.48.0 host USB 59 GET DESCRIPTOR Response CONFIGURATION
23 0.000000 host 2.48.0 USB 36 SET CONFIGURATION Request
24 0.000000 2.48.0 host USB 28 SET CONFIGURATION Response
25 0.000000 host 2.49.0 USB 36 GET DESCRIPTOR Request DEVICE
26 0.000000 2.49.0 host USB 46 GET DESCRIPTOR Response DEVICE
27 0.000000 host 2.49.0 USB 36 GET DESCRIPTOR Request CONFIGURATION
28 0.000000 2.49.0 host USB 85 GET DESCRIPTOR Response CONFIGURATION
29 0.000000 host 2.49.0 USB 36 SET CONFIGURATION Request
30 0.000000 2.49.0 host USB 28 SET CONFIGURATION Response
31 0.207397 host 2.49.0 USB 36 URB_CONTROL in
32 0.207520 2.49.0 host USB 32 URB_CONTROL in
33 0.718473 host 2.49.0 USB 36 URB_CONTROL in
34 0.718630 2.49.0 host USB 32 URB_CONTROL in
35 1.231446 host 2.49.0 USB 36 URB_CONTROL in
36 1.231542 2.49.0 host USB 32 URB_CONTROL in
37 1.746055 host 2.49.0 USB 36 URB_CONTROL in
38 1.746176 2.49.0 host USB 32 URB_CONTROL in
39 2.260614 host 2.49.0 USB 36 URB_CONTROL in
40 2.260741 2.49.0 host USB 32 URB_CONTROL in
41 2.774725 host 2.49.0 USB 36 URB_CONTROL in
42 2.774814 2.49.0 host USB 32 URB_CONTROL in
43 3.277317 host 2.49.0 USB 36 URB_CONTROL in
44 3.277406 2.49.0 host USB 32 URB_CONTROL in
45 3.431397 host 2.56.1 USB 27 URB_BULK in
46 3.431488 host 2.56.1 USB 27 URB_BULK in
47 3.431561 host 2.56.1 USB 27 URB_BULK in
48 3.431629 host 2.56.1 USB 27 URB_BULK in
49 3.431678 host 2.56.1 USB 27 URB_BULK in
50 3.431752 host 2.56.1 USB 27 URB_BULK in
51 3.431840 host 2.56.1 USB 27 URB_BULK in
52 3.431883 host 2.56.1 USB 27 URB_BULK in
53 3.431970 host 2.56.1 USB 27 URB_BULK in
54 3.432002 2.56.1 host USB 203803 URB_BULK in
55 3.432120 host 2.56.1 USB 27 URB_BULK in
56 3.432173 host 2.56.1 USB 27 URB_BULK in
57 3.432217 host 2.56.1 USB 27 URB_BULK in
58 3.432263 host 2.56.1 USB 27 URB_BULK in
59 3.432344 host 2.56.1 USB 27 URB_BULK in
60 3.432390 host 2.56.1 USB 27 URB_BULK in
61 3.432436 host 2.56.1 USB 27 URB_BULK in
62 3.432481 host 2.56.1 USB 27 URB_BULK in
63 3.789137 host 2.49.0 USB 36 URB_CONTROL in
64 3.789272 2.49.0 host USB 32 URB_CONTROL in
65 4.290775 host 2.49.0 USB 36 URB_CONTROL in
66 4.290870 2.49.0 host USB 32 URB_CONTROL in
67 4.805351 host 2.49.0 USB 36 URB_CONTROL in
68 4.805442 2.49.0 host USB 32 URB_CONTROL in
69 4.917708 host 2.49.0 USB 36 URB_CONTROL in
70 4.917887 2.49.0 host USB 92 URB_CONTROL in
71 4.918507 host 2.49.0 USB 36 URB_CONTROL in
72 4.918607 2.49.0 host USB 92 URB_CONTROL in
73 4.927541 host 2.49.0 USB 36 URB_CONTROL in
74 4.927631 2.49.0 host USB 92 URB_CONTROL in
75 4.929602 host 2.49.0 USB 36 URB_CONTROL in
76 4.929688 2.49.0 host USB 92 URB_CONTROL in
77 4.931008 host 2.49.0 USB 36 URB_CONTROL in
78 4.931090 2.49.0 host USB 92 URB_CONTROL in
79 4.931433 host 2.49.0 USB 36 URB_CONTROL in
80 4.931502 2.49.0 host USB 92 URB_CONTROL in
81 4.931651 host 2.49.0 USB 36 URB_CONTROL in
82 4.931720 2.49.0 host USB 92 URB_CONTROL in
83 4.931851 host 2.49.0 USB 36 URB_CONTROL in
84 4.931922 2.49.0 host USB 92 URB_CONTROL in
85 4.932042 host 2.49.0 USB 36 URB_CONTROL in
86 4.932107 2.49.0 host USB 92 URB_CONTROL in
87 4.932249 host 2.49.0 USB 36 URB_CONTROL in
88 4.932318 2.49.0 host USB 92 URB_CONTROL in
89 4.932464 host 2.49.0 USB 36 URB_CONTROL in
90 4.932540 2.49.0 host USB 92 URB_CONTROL in
91 4.945685 host 2.56.1 USB 27 URB_FUNCTION_ABORT_PIPE
92 4.945750 2.56.1 host USB 27 URB_BULK in
93 4.945814 2.56.1 host USB 27 URB_BULK in
94 4.945864 2.56.1 host USB 27 URB_BULK in
95 4.945938 2.56.1 host USB 27 URB_BULK in

The rest is a mix of  URB_BULK in / URB_FUNCTION_ABORT_PIPE / URB_CONTROL in

 

2. The other test is using the bulkscrsink FW as you had requested before

Now here again I had included the entire UART log before. So please let me know what you want me to add. Or ideally, please point me to the design files you want me to test, ideally the IMG file itself so I have the full debug print as you want.

Nevertheless, the Wireshark dump for this test case for a fail is this:

1 0.000000 host 2.2.0 USB 36 GET DESCRIPTOR Request DEVICE
2 0.000000 2.2.0 host USB 46 GET DESCRIPTOR Response DEVICE
3 0.000000 host 2.2.0 USB 36 GET DESCRIPTOR Request CONFIGURATION
4 0.000000 2.2.0 host USB 59 GET DESCRIPTOR Response CONFIGURATION
5 0.000000 host 2.2.0 USB 36 SET CONFIGURATION Request
6 0.000000 2.2.0 host USB 28 SET CONFIGURATION Response
7 0.000000 host 2.10.0 USB 36 GET DESCRIPTOR Request DEVICE
8 0.000000 2.10.0 host USB 46 GET DESCRIPTOR Response DEVICE
9 0.000000 host 2.10.0 USB 36 GET DESCRIPTOR Request CONFIGURATION
10 0.000000 2.10.0 host USB 72 GET DESCRIPTOR Response CONFIGURATION
11 0.000000 host 2.10.0 USB 36 SET CONFIGURATION Request
12 0.000000 2.10.0 host USB 28 SET CONFIGURATION Response
13 0.000000 host 2.47.0 USB 36 GET DESCRIPTOR Request DEVICE
14 0.000000 2.47.0 host USB 46 GET DESCRIPTOR Response DEVICE
15 0.000000 host 2.47.0 USB 36 GET DESCRIPTOR Request CONFIGURATION
16 0.000000 2.47.0 host USB 59 GET DESCRIPTOR Response CONFIGURATION
17 0.000000 host 2.47.0 USB 36 SET CONFIGURATION Request
18 0.000000 2.47.0 host USB 28 SET CONFIGURATION Response
19 0.000000 host 2.48.0 USB 36 GET DESCRIPTOR Request DEVICE
20 0.000000 2.48.0 host USB 46 GET DESCRIPTOR Response DEVICE
21 0.000000 host 2.48.0 USB 36 GET DESCRIPTOR Request CONFIGURATION
22 0.000000 2.48.0 host USB 59 GET DESCRIPTOR Response CONFIGURATION
23 0.000000 host 2.48.0 USB 36 SET CONFIGURATION Request
24 0.000000 2.48.0 host USB 28 SET CONFIGURATION Response
25 0.000000 host 2.49.0 USB 36 GET DESCRIPTOR Request DEVICE
26 0.000000 2.49.0 host USB 46 GET DESCRIPTOR Response DEVICE
27 0.000000 host 2.49.0 USB 36 GET DESCRIPTOR Request CONFIGURATION
28 0.000000 2.49.0 host USB 85 GET DESCRIPTOR Response CONFIGURATION
29 0.000000 host 2.49.0 USB 36 SET CONFIGURATION Request
30 0.000000 2.49.0 host USB 28 SET CONFIGURATION Response
31 0.078602 host 2.49.0 USB 36 URB_CONTROL in
32 0.078742 2.49.0 host USB 32 URB_CONTROL in
33 0.262472 host 2.49.0 USB 36 URB_CONTROL in
34 0.262656 2.49.0 host USB 92 URB_CONTROL in
35 0.263163 host 2.49.0 USB 36 URB_CONTROL in
36 0.263265 2.49.0 host USB 92 URB_CONTROL in
37 0.594419 host 2.49.0 USB 36 URB_CONTROL in
38 0.594582 2.49.0 host USB 32 URB_CONTROL in
39 1.094473 host 2.49.0 USB 36 URB_CONTROL in
40 1.094593 2.49.0 host USB 32 URB_CONTROL in
41 1.121827 host 2.10.1 USB 27 URB_BULK in
42 1.121901 host 2.10.1 USB 27 URB_BULK in
43 1.121936 host 2.10.1 USB 27 URB_BULK in
44 1.121978 host 2.10.1 USB 27 URB_BULK in
45 1.122035 host 2.10.1 USB 27 URB_BULK in
46 1.122094 host 2.10.1 USB 27 URB_BULK in
47 1.122142 host 2.10.1 USB 27 URB_BULK in
48 1.122182 host 2.10.1 USB 27 URB_BULK in
49 1.122222 host 2.10.1 USB 27 URB_BULK in
50 1.122258 host 2.10.1 USB 27 URB_BULK in
51 1.122297 host 2.10.1 USB 27 URB_BULK in
52 1.122332 host 2.10.1 USB 27 URB_BULK in
53 1.122360 host 2.10.1 USB 27 URB_BULK in
54 1.122388 host 2.10.1 USB 27 URB_BULK in
55 1.122421 host 2.10.1 USB 27 URB_BULK in
56 1.122448 host 2.10.1 USB 27 URB_BULK in
57 1.123116 2.10.1 host USB 524315 URB_BULK in
58 1.123183 host 2.10.1 USB 27 URB_BULK in
59 1.124401 2.10.1 host USB 524315 URB_BULK in
60 1.124494 host 2.10.1 USB 27 URB_BULK in
61 1.125878 2.10.1 host USB 524315 URB_BULK in
62 1.125973 host 2.10.1 USB 27 URB_BULK in
63 1.127026 2.10.1 host USB 524315 URB_BULK in
64 1.127089 host 2.10.1 USB 27 URB_BULK in
65 1.128620 2.10.1 host USB 524315 URB_BULK in
66 1.128681 host 2.10.1 USB 27 URB_BULK in
67 1.129806 2.10.1 host USB 524315 URB_BULK in
68 1.129867 host 2.10.1 USB 27 URB_BULK in
69 1.130104 2.10.1 host USB 50203 URB_BULK in
70 1.130158 host 2.10.1 USB 27 URB_BULK in
71 1.605352 host 2.49.0 USB 36 URB_CONTROL in
72 1.605457 2.49.0 host USB 32 URB_CONTROL in
73 2.119800 host 2.49.0 USB 36 URB_CONTROL in
74 2.119896 2.49.0 host USB 32 URB_CONTROL in
75 2.634765 host 2.49.0 USB 36 URB_CONTROL in
76 2.634793 host 2.10.1 USB 27 URB_FUNCTION_ABORT_PIPE
77 2.634818 2.10.1 host USB 27 URB_BULK in
78 2.634868 2.10.1 host USB 27 URB_BULK in
79 2.634896 2.49.0 host USB 32 URB_CONTROL in
80 2.634908 2.10.1 host USB 27 URB_BULK in
81 2.634951 2.10.1 host USB 27 URB_BULK in
82 2.635057 2.10.1 host USB 27 URB_BULK in
83 2.635162 2.10.1 host USB 27 URB_BULK in

The rest is a mix of  URB_BULK in / URB_FUNCTION_ABORT_PIPE / URB_CONTROL in

 

Can you please let me know if this helps, or point me to an example you'd like me to test with the exact firmware changes?

Many thanks,

Best wishes,

Gergely

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

Hello Gregely,

Thank you for the update.

From your response, I understand that you are seeing CYU3P_USBEP_SS_RESET_EVT &  CYU3P_USBEP_SS_RETRY_EVT events.

Please refer to point IV of section 2.3 of FX3_trouble_shooting _guide of FX3 SDK to understand the reason of these events and the workaround.

From the Wireshark logs shared by you it seems that URB_FUNCTION_ABORT_PIPE is the equivalent of CY_U3P_USB_SC_CLEAR_FEATURE

You can use the GPIFtoUSB example to check if clear feature request is received at the instance (attached snippet)

 

Regards,
Rashi
0 Likes
GergelySimon
Level 1
Level 1
5 sign-ins First reply posted First question asked

Hi Rashi,

 

Many thanks for your reply.

 

Carrying out more testing swapping devices / cables etc I have noticed a potential source of the issue. I have been using a StarTech hb30c4ab USB hub, and this gave the issues described in my first post.

 

However, tested now going through a direct port on my laptop instead, and it seems to be working fine (50+ tests successful), both using a CYUSB3KIT, and our own hardware, with all sorts of firmware.

 

Have you ever seen similar issue with a USB hub? Do you think this is a one-off issue or maybe an incompatibility between the hub and the CYUSB3014 chip?

 

Please let me know if you have any tips,

Many thanks,

Gergely

0 Likes

Hello Gregley,

We have seen that when USB link is bad USB retry events and USB reset events are seen. Adding hub could make the USB link bad and hence the retries/reset events

Similar thread  Solved: Why IN endpoint is always STALLED - Infineon Developer Community  

Regards,
Rashi
0 Likes
Biren_R
Moderator
Moderator
Moderator
First question asked First like given 250 sign-ins

Hello Gergely,

We still never face this type of issue with CYUSB3014 and the USB hub.

Best Regards,
Biren

0 Likes