cancel
Showing results for 
Search instead for 
Did you mean: 

USB Superspeed Peripherals

New Contributor

We have a USB 3.0 camera and we configure bulk endpoint for image data transfers. Normally, we use CyU3PUsbGetSpeed() API to know whether configure the bulk endpoint for USB 3.0 or USB 2.0 and its size accordingly. But turns out this sequence doesn't work out for all the mother boards when the device remains connected during boot up.

1. In ideal case, after CyU3PUsbStart();, in the evenCB, we get the evType = CY_U3P_USB_EVENT_CONNECT, evData = 1 (USB 3.0) before we configure the endpoint and the initialization goes well.

2. In some mother boards, when the device is connected before boot and when the OS boots up, first we get the event evType = CY_U3P_USB_EVENT_CONNECT evData = 0 (USB 2.0) and at this point when we use CyU3PUsbGetSpeed(), it shows HighSpeed. We complete the endpoint configuration at this stage. After the OS is fully loaded, we again get the events, evType = CY_U3P_USB_EVENT_RESET   evData = 0 (USB 2.0)  & evType = CY_U3P_USB_EVENT_CONNECT evData = 1 (USB 3.0). But at this stage, since the endpoint is configured for USB 2.0 already, obviously there are problems in transferring data through that endpoint.

Turns out that this is due to a special mode in certain mother boards, (XHCI Mode configurable through BIOS settings), the port remains as USB 2.0 compatible during the OS boot up and after its completion, it goes in switches to XHCI mode.

Now, with default sequence provided by Cypress, this condition is missed and we found a simple logic to make this work.

If we wait until the evType = CY_U3P_USB_EVENT_EP0_STAT_CPLT evData = 0, and then carry on with the end point configuration, then it works fine since all the CY_U3P_USB_EVENT_RESET & CY_U3P_USB_EVENT_CONNECT are completed before this.

Need advice if this kind of behavior is common and if the fix above is recommended.

0 Likes
Reply
1 Solution
Moderator
Moderator

Hi Arun,

1. This sequence is not common in the mother boards.

2. Your original implementation is as follows:

Wait for the CY_U3P_USB_EVENT_EP0_STAT_CPLT  event. Once you get it you will proceed for configuring endpoints.

As you might know that the above event will be generated after the status phase of the control transfer is complete. But it has to be noted that the event is generated for the control transfers which are handled in the firmware and not by the USB driver which are handled internally.

So, if no request is handled by the firmware (your application) when it is at 2.0, then yes, it is a solution. But as we discussed earlier, starting your application after SET_CONF comes would also be a solution since you would stop the application when RESET event occurs and re-start it again when the final enumeration occurs.

Let me know if you have any questions.

Regards,

Hemanth.

Hemanth

View solution in original post

0 Likes
Reply
5 Replies
Moderator
Moderator

Hi,

From the above description, I get that the sequence in some PCs is as follows:

- FX3 connects to PC as a High Speed Device

- OS issues a reset

- FX3 then comes up as a Super speed device

If this the case, the firmware can be designed such a way that, when a reset event occurs, stop the application. When ever connect happens the endpoints can be configured again.

Please refer to UsbBlkSrcSink application source code which is in FX3 SDK firmware examples.

In that, when reset event occurs and if the application is active, then CyFxBulkSrcSinkApplnStop() is called.

Let me know if you have any questions.

Regards,

Hemanth

Hemanth
0 Likes
Reply
New Contributor

Hi Hemanth,

Thanks for your suggestions. This is one way of tackling the issue as well. We have also handled this when ever the application is active. But for this happening during enumeration, please let me know if our current implementation will hold good.

Thanks,

Arun

0 Likes
Reply
Moderator
Moderator

Hi Arun,

Your Host application which handles the image data will be started only after the OS is loaded.

So, by the time you access the device in your application, the reset would have occurred and the firmware would have reconfigured the endpoints according to the speed.

So, I don't see a problem in this sequence. Please let me know if there is any.

Regards,

Hemanth

Hemanth
0 Likes
Reply
New Contributor

Hi Hemanth,

Can you confirm my original query?

1. Is this sequence is common in mother boards?

2. Can the original implementation that I explained be used only for first time configuration?

Thanks,

Arun

0 Likes
Reply
Moderator
Moderator

Hi Arun,

1. This sequence is not common in the mother boards.

2. Your original implementation is as follows:

Wait for the CY_U3P_USB_EVENT_EP0_STAT_CPLT  event. Once you get it you will proceed for configuring endpoints.

As you might know that the above event will be generated after the status phase of the control transfer is complete. But it has to be noted that the event is generated for the control transfers which are handled in the firmware and not by the USB driver which are handled internally.

So, if no request is handled by the firmware (your application) when it is at 2.0, then yes, it is a solution. But as we discussed earlier, starting your application after SET_CONF comes would also be a solution since you would stop the application when RESET event occurs and re-start it again when the final enumeration occurs.

Let me know if you have any questions.

Regards,

Hemanth.

Hemanth

View solution in original post

0 Likes
Reply