a strange delay in USB2.0

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

cross mob
Ascs_4819156
Level 3
Level 3
10 replies posted 10 sign-ins 5 replies posted

Dear Sir,

I am using CYUSB3014 to develop a camera. Now it works normally at USB3.0 mode. But if I connect it to the USB2.0 port, it does not work well.

In high speed mode(USB2.0), when I read a value from the device, it always have a unbelieve delay, even if in the firmware I return a fake value when receive the request.

For example, By bushound, I can monitor the time. If I send out the request at 15:01:26:540, then after about 13 millisecond, I will get the fake return value at 15:01:26:553. But in Super speed mode(USB3.0), the fake value will be reported at the same time or only need 1 millisecond.

Does anyone know what happened?

Thanks

Chad

0 Likes
1 Solution

Hi Chad,

Answering to one of your posts above, the short duration in the control IN requests could be removed by following the firmware workaround mentioned in the first post of mine, where suspending of other channels is avoided during a control IN transfer.

After this workaround is implemented, could you try controlling (lowering) the BULK IN data time and see if the issue persists? and if the issue is not seen, is the data corrupted?

We need to find out where the firmware is getting stuck. For this you could do the following:

1. If the UART traces are coming out of the board, you could connect the UART lines to a USB converter and get the UART logs, if not,
2. You could try the CDC approach and get the logs, if not,
3. You could add CyU3PDeviceReset(CyTrue) to find out the places in the firmware which is getting executed and which is not.

Best Regards,
AliAsgar

View solution in original post

0 Likes
25 Replies
AliAsgar
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 750 replies posted

Hi Chad,

Could you let us know the FX3 SDK firmware version?

Could you let us know how the value is being read from the device? If it is using control endpoints, please look at the thread link given below and let us know if the issue persists after implementing the workaround.

https://community.infineon.com/t5/USB-Superspeed-Peripherals/CYUSB3014-How-to-speed-up-operate-contr....

Best Regards,
AliAsgar

0 Likes

Thanks Ali,

My SDK version is 1.3.4.

Yes, I used a control endpoints. And I will check the link you offered. If it works, I will let you know.

Thanks

Chad

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

Hello Chad,

Please refer to second point of IV of section 2.3 of Fx3 Trouble shooting guide and please confirm if simultaneous  IN transfers on any Bulk-IN endpoint along with the EP0-IN are done when the issue is seen.

If yes, as mentioned in the document from SDK versions 1.3.3 and later,  all BULK-IN DMA channels are suspended for a short duration while the EP0-IN transfer is being completed as a workaround for the problem.

Please let me know if any queries on this

Regards,
Rashi
0 Likes

Hi  Rashi,

Thanks for your answer.

Yes, about the delay, I know the reason now. I used to think this delay caused the failure in the USB2.0, but now it seems not to be the reason.

Now, my failure is that, my camera always works fine in Super-speed link, but in high-speed link, EP0-IN and Bulk-IN could not work at the same time. If I do not transfer data with EP0-IN, and only use Bulk-IN endpoint to capture the image, it always work fine. Once I try to transfer data with EP0-IN,  camera will freezes, then goes offline. So it is difficult for me to debug, because it can't communication after failure. Then I have to reconnect the camera to let it run again.

Usually, I can get the "USTS C0000011 xact error" on bushound.

Do you have any suggestion about this problem?

Thanks

Chad

0 Likes

Hi Rashi,

Another problem,  according to the trouble shooting, the workaround for the problem has been implemented in SDK versions 1.3.3 and later, but I think it is better to control the BULK-IN data time to avoid this problem. In this way, I do not need the short duration.

So do you know how to remove this duration in the SDK?

Thanks

Chad

0 Likes

Hi Chad,

1. How do you plan on controlling the BULK-IN data time?

2. Have you tried the workaround mentioned in the first post?

3. The camera freeze issue is happening with the workaround or with the SDK?

Best Regards,
AliAsgar

0 Likes

Hi Ali,

1, We used FPGA to send data into FX3, So we can control the BULK-IN Data time.

2, Tried, but not work. I am also not sure why. Because we can control the BULK-IN Time, so I think we can avoid this problem from the beginning.

3, What's you mean of workaround  and SDK? FX3's firmware or CYAPI?When the freeze issue happened, the camera will not give any feedback. The only way is re-connect the USB.

Thanks

Chad

0 Likes

Hi Chad,

1. Could you tell us what is the exact error you are facing? Is it the slow speed of the control endpoint or the camera freeze issue. If it is the camera freeze issue, is there any modifications that has been done to the firmware?

2.  If no modifications are done to the firmware and if the camera freeze issue still occurs, kindly share with us the wireshark traces.

3. Is it a UVC application or a vendor specific?

4. Which is the host application and what is the resolution and frame rate?

Best Regards,
AliAsgar

0 Likes

Hi Ali,

Thanks for your support.

Do I need to start a new topic?

Now this is my product. We used FX3( + FPGA + CMOS Image sensor) to develop a USB camera. It  is not an UVC camera. So we developped our FPGA and FX3 firmware, and we also developed a library which is based  on CYAPI to control the FPGA and camera. Beside we also have a demo based on the library.

Now this system works fine with USB3.0. But if it is connectted to USB2.0,  it does not.

With USB2.0, if I only send out the control request without capture, the camera works fine. And If I start capture without control request, camera also works fine. But you know, it always have some requests when the camera is capturing, then the camera will freeze.

I tried to find out why, and I find the strange delay of request. I used to think it leads the freeze, but according to the disscussion above, it is normal.

So now, what information should I give you to solve this problem?

There is a screenshot, please check.test.png

after this, I have to unplug the camera, only this way, the camera could be recoginzed again.

Thanks

Chad

0 Likes

Hi Chad,

1. Could you share the wireshark traces when the issue is seen?

2. What is the resolution and frame rate?

3. Is the issue seen using the default SDK or have you implemented any workaround mentioned in the first post?

Best Regards,
AliAsgar

0 Likes

Hi Ali,

1, I used bushound instead of wireshark. Usually, they are the same. About the traces, please check my last reply. I let the camera begin to capture, then tried to adjust the image sensor's gain. For the gain, I will read the default value first, then it is freeze. If this is not enough, please let me know. I will offer more information.

2, Now I am using 1936*1096, 16bits, 6fps with usb2.0.

3, Both the default SDK and the workaround are not useful, they have the same result.

Thanks

Chad

0 Likes

Hi Chad,

It would be better if you could share the wireshark traces as a file.

Best Regards,
AliAsgar

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

Thank Ali,

Here is the file, please check it. I am trying to adjust the gain, and before I set the new gain, I will try to read the sensor's standby status. After several times, then the camera is freeze.

Thanks

Chad

0 Likes

Hi Chad,

1. Could you add a debugPrint in the infinite for loop, and share with us the debug prints. This will help us to know whether the firmware is getting stuck somewhere during the freeze. It would also be helpful if you could share your firmware with us.

2. The "reset" and "cancelled" in the bushound trace, is it coming because of the manual reset being done, or is that coming automatically when the freeze issue is seen?

3. Which driver is the device binding to?

Best Regards,
AliAsgar

0 Likes

Hi  Ali,

Thanks again.

1, I am not sure where to add the debugprint, in CYAPI lib or my code? I can not add it in the firmware because I used both SPI and 32 bit data transfer. For the firmware, all project or part of them also will be helpful?

2, Reset is send out by us, because we can't receive the data from bulk-in endpoint. So I tried to reset it. And the cancelled is not, it is coming automatically when the freeze issue heppened.

3, The driver is based on the crpyess driver(Cypress\EZ-USB FX3 SDK\1.3\driver\bin\win7). Modified the INF file, and re-generated CAT file,  and signatured.

Thanks

Chad

0 Likes

Hi Ali,

I I found a topic very similar to my phenomenon. Is this topic finally solved?

Topic:https://community.infineon.com/t5/USB-Superspeed-Peripherals/CX3-uvc-bulk-in-transfer-failed-by-cont...

If you need the original firmware code, please offer me an email. Publishing code in forums is not a good idea.

Thanks

Chad

0 Likes

Hi Chad,

I am not sure whether that topic was finally solved. That is the reason I had asked you to try the workaround I had mentioned in the first post, as even this thread points to the same workaround.

My email id is AliAsgar.AliAsgar@infineon.com.

Meanwhile please answer the questions I have asked in the previous post.

Best Regards,
AliAsgar

0 Likes

Hi Ali,

Thanks for your email address.

And there are 2 replies for me, please check the old one. I had answered the questions.

I will send you the firmware code after I clean up the code. There are many testing code in it now.

Thanks

Chad

0 Likes

Hi Ali,

Thanks,the code had been send to your email box.

Thanks

Chad

0 Likes

Hi Chad,

UART debug prints can be taken from GPIO 55(TX) and GPIO 56(RX) if 32 bit GPIF bus is used. 
Please add debug prints in the for (;;) loop inside the  CyFxAppThread_Entry and CmdHandlerThread_Entry and kindly share with us the debugPrints from the start till the issue is seen.

Declare two global variables 'prod' and 'cons', initialize them to 0 and increment them during every prod and cons event callback respectively, and print their values in the CyFxAppThread_Entry infinite for loop. 

Are all the vendor commands causing this issue or only particular vendor commands?

When the freeze issue is seen, is any data coming on either of the endpoints? (control or BULK).

Best Regards,
AliAsgar

0 Likes

Hi Ali,

Thanks.

For the UART, sorry, we also used the spi flash to save the firmware, so uart will conflict with spi and 32-bits bus.  beside, there is no hardware reserved for them. So it is difficult for me to use UART now.

But we had used the CDC debug in the past, I am not sure if it still works now, soI will try it this week. If there is progress, I will update the topic.

And for the current, according to my test, the vendor command that need to return value will cause the issue., others will not.

And neither control nor bulk will come data when the issue is seen.

Thanks

Chad

0 Likes

Hi Chad,

Answering to one of your posts above, the short duration in the control IN requests could be removed by following the firmware workaround mentioned in the first post of mine, where suspending of other channels is avoided during a control IN transfer.

After this workaround is implemented, could you try controlling (lowering) the BULK IN data time and see if the issue persists? and if the issue is not seen, is the data corrupted?

We need to find out where the firmware is getting stuck. For this you could do the following:

1. If the UART traces are coming out of the board, you could connect the UART lines to a USB converter and get the UART logs, if not,
2. You could try the CDC approach and get the logs, if not,
3. You could add CyU3PDeviceReset(CyTrue) to find out the places in the firmware which is getting executed and which is not.

Best Regards,
AliAsgar

0 Likes

Thanks Ali,

Got your advices.

I am busy with other work these days, so I'll try that later.

Thanks again

Chad

0 Likes

Hi Chad,

Shall I close this thread?

You could always open new thread on the community, our engineers will be happy to help you.

Best Regards,
AliAsgar

0 Likes

Hi Ali,

Please close, if there is new information, I will create a new topic.

Thanks

Chad

0 Likes