cancel
Showing results for 
Search instead for 
Did you mean: 

USB Superspeed Peripherals

ZaTu_4258396
New Contributor

Good afternoon,

This may have been placed in the wrong area but I am sure that will get figured out.

As the title says we are developing on a Cypress CX3 chip that we are viewing issues on that has been designed to be used as a camera board with 2 LED's. The board is set up with a USB-C connector. We are attempting to have a powered usb hub connect to the device and allow the host computer to trigger the hub to power up and stream images. However during a specific power up sequence the camera device will get locked into an unknown state and be unable to stream images. However we are able to see the device in the tree and still issue vendor commands. 

 

How to reproduce the problem:

Using a powered hub we are able to 100% reproduce the issue by using the following steps ONLY with usb C to C cables. We cannot reproduce with C to A:

1. plug device into UNPOWERED USB hub w/ usb C  to usb C cable

2. plug hub into UNPOWERED laptop w/ usb C to usb C cable

3. plug in power to usb hub

3. power on laptop

 

Data and information collected:

1. The device appears to get some sort of power to the CX3 chip on the order of 80mV and we have an LED attached to the device reset call that *appears to attempt to start a reset but does not complete*. This is an assumption. During normal operation we would have the laptop turned on. We would plug the device into the laptop and see a full white LED pulse and have the device do its reset.

2. Issuing a hard reset over I2C will reset the device and fix the issue. But we need to find out what is causing the issue and prevent it or understand why it is happening

3. Connecting UART into the device during the initial start up allows me to see the following dma errors:

    1. AppInit:DmaMultiChannelCreate Err = 0x40
    2. AplnStop:ChannelReset Err = 0x40
    3. AppInit:MultiChannelReset Err = 0x40

4. Attempting to manually initialize the device through the API calls for the mipi and device initialization via a vendor command does not fix the issue.

5. Placing delays in the startup of the code does not prevent the initial startup from happening during power up of the hub

 

Any help or insight into how we could potentially get closer to our solution would be very appreciated. Thank you for your time and please let me know if I can provide any additional information to provide a more clear description of our issue.

 

0 Likes
1 Solution
hgroover
New Contributor II

To conclude here, there were a couple of issues:

1. This problem occurred only with the CoolGear CG-3X2C3AM powered hub connected to a computer or laptop with a Type C connector.

2. When powering up the hub with the host computer connected but powered off, the hub would bring up the USB device in FS or HS mode.

3. The application running on the USB device would come up in FS or HS mode, and when the SS host finally connected, the initialization done with FS or HS mode active had set key parameters incorrectly.

In short, this was a problem with the USB device application not handling FS and HS properly. For our application the desired behavior was to either disable FS and HS altogether, or wait until SS is available to proceed with initialization.

Another problem with this specific hub was also observed while investigating this problem. Although this hub asserts both CC1 and CC2 in a way that indicates it is capable of 3A (and advertises that it can provide 3A at 19V as well as 5V), it actually does not apparently provide more than about 1.5A at 5V. This current shortage results in voltage drops to as low as 3.5V on VBUS, which therefore results in unstable behavior and spontaneous resets.

View solution in original post

0 Likes
11 Replies
Rashi_Vatsa
Moderator
Moderator

Hello,

From the description, I understand that the streaming through CX3 doesn't work when the device is connected to unpowered USB host via hub (when later powered on). Is my understanding correct?

Please let me know the following details

- Cx3 works in self power mode or bus power mode

- Is the application a UVC application or vendor ?

- From the description, I understand the streaming works fine when C to A cable is used to connect the device to Hub. Is that correct?

- Does the video streaming work when the device is connected to powered hub and USB host using both the cables? Or for the case when CX3 is directly connected to USB host via USB type C to C cable?

The device appears to get some sort of power to the CX3 chip on the order of 80mV and we have an LED attached to the device reset call that *appears to attempt to start a reset but does not complete*.

>> Could you please let me know the reason of device reset being called and where in the firmware is it called?

 Connecting UART into the device during the initial start up allows me to see the following dma errors:

>> The error code returned by the API is 0x40 which is CY_U3P_ERROR_BAD_ARGUMENT (reason: One or more parameters to a function are invalid). Please let me know the instance/s in the firmware where the AppInit API called.

Regards,
Rashi
0 Likes
ZaTu_4258396
New Contributor

Rashi,

Thank you for the quick reply to our issue.

Your understanding is on point.

Our device is in Bus power mode

UVC application

Streaming does work fine from C to A, as the initialization seems to be different from the C to C

The CX3 will work when directly connected to the host. The CX3 will also work when it is plugged into the USB hub and powered up AFTER the host is powered up.  This has also been confirmed on a Linux machine.

Short answer: We are still trying to root cause this issue and identifying the exact reason of the reset and what the CX3 "black box" initialization may contain that we do not understand. Hoping to use your insight to help us find more "breadcrumbs" to root cause the issue.

The Applninit API function is only called inside of the following function:

esUVCUvcAppThread_Entry()

 

0 Likes
JayakrishnaT_76
Moderator
Moderator

Hello,

Please let us know your comments on the following questions so that we can have more information to debug the issue:

1. From the following statement in your description,

"The device appears to get some sort of power to the CX3 chip on the order of 80mV and we have an LED attached to the device reset call that *appears to attempt to start a reset but does not complete*."

We understand that when the issue occurs (powering host after powering the hub and using C to C cable), the CX3 chip will get a power of the order of 80mV. Is this 80mV, the supply voltage for core (VDD)? Is my understanding correct? If my understanding is not correct, please correct me. 

In addition to this, what exactly did you mean by reset call? By reset call, are you referring to power on reset or have you implemented a reset in firmware as a part of startup?

Also, how does the reset LED work normally? As per my understanding, it glows until the reset is completed. But, when the failure is seen, it turns off immediately. Please confirm if my understanding is correct. Please correct me if it is wrong.

2. Please elaborate the following statement:

"Issuing a hard reset over I2C will reset the device and fix the issue."

How is this event handled in the firmware? 

3. I believe that the firmware image for CX3 is stored in a non volatile memory like I2C EEPROM or SPI flash. Please let me know if there is a provision to do hardware reset for CX3. That is, have you used a switch on the RESET# pin of CX3 for resetting the device. If there is a switch, once the failure is seen, can you please reset the device using this switch and then check if the issue occurs again or not?

Best Regards,
Jayakrishna
0 Likes
ZaTu_4258396
New Contributor

Jayakrishna,

Thank you for the reply and nice to meet you as well!


We were able to measure the 80mV off of a usb-C breakout board connected to the end of the usb C-to-C cable that is plugged into the hub. This measurement was captured during the hubs initial power up.


I am specifically talking about "power on reset". We have however implemented a vendor command that allows for a hard reset "unplug replug event". Calling this vendor command to reset the device results in 100% success.


During a normal unplug/replug event we would see the white led blink once and enter reset, wait 2 seconds, then white led glow for about 1-2 seconds as it appears back onto the device manager tree.


During this failure case mentioned, we see one, somtimes two quick (~0.25 second apart if so) , blinks during the hub power up. Then once the host has powered up you see the device do a hard reset where the white LED glows for about 1-2 seconds and appears back onto the usb tree.


We handle the reset in the firmware through a vendor command. We have set up a number of vendor commands to adjust various parameters of the camera through this method as well.


There is a pin attached to the reset to the chip. If we see this issue and trigger the reset, it will fix the issue by causing the device to do a hard reset.
-Zach

0 Likes
ZaTu_4258396
New Contributor

Also,

On the specifics on the "vendor command process" we use ES_UVC_USB_SET_CUR_REQ and ES_UVC_USB_GET_CUR_REQ to send/get EP0 data over the USB from the host. Please let me know if I need to include additional information.

 

-Zach

0 Likes
JayakrishnaT_76
Moderator
Moderator

Hello Zach,

Please let me know the following details to debug the issue better:

1. On which pin is this 80mV measured when the CX3 device is connected to the hub and when the host is not powered up?

2. By vendor command, do you mean the extension unit requests? Please confirm if my understanding is correct. Please correct me if I am wrong.

3.  I did not understand the working of white LED properly yet. Please let us know how is this LED driven from the firmware so that we can understand more on the working of this LED. Does the white LED glow for 1-2 seconds when the device is about to enumerate? Please elaborate more about this. Also, please let me know the boot mode used.

4. Have you tested the setup using a different hub? If not, can you please test this? This is because, the failure is seen only when the device is connected to the hub (powered) first followed by powering the host. When the device is directly connected to the host or hub after powering the host, the issue is not seen. Also, upon pressing reset/issuing a software reset is fixing the problem. So, we can check if the problem follows hub or not.

5. Please let us know how is the software reset command handled in the firmware? Are you using CyU3PDeviceReset(CyFalse)?

6. Please share the complete UART debug logs for the working and failing case. In addition to this, please let me know if you can share the firmware file for us to review. 

Best Regards,
Jayakrishna
0 Likes
hgroover
New Contributor II

Hello Jayakrishna,

I have been working with Zach on this so I'll give you some responses...

In response to # 1, we are measuring this on one of the VBUS pins on the USB-C breakout. It's also worth noting that we do not have functional USB SS communication when using the breakout board (between the hub and the device), so this was an interesting observation but not necessarily significant.

In response to # 2, we are using the DirectShow terminology of "vendor commands" to refer to the extension unit requests, so yes, you are correct.

In response to # 3, we have an RGB LED on our board which is GPIO-controlled. We are treating this as a timing-sensitive issue and are continuing to debug the startup process.

I will leave Zach to address your other questions.

I also want to add that we are curious as to whether this might be a known issue covered by one of the errata listed in this document https://www.cypress.com/file/133591/download starting on page 32, specifically #8 or #11.

Thank you!

-Henry

0 Likes
ZaTu_4258396
New Contributor

In response to #4, We have tested this with three different powered hubs and get the same result. Your understanding is right on point.

#5, Yes we are using the CyU3PDeviceReset(CyFalse)

#6, I have included the logs for a failure and success. I would also be happy to share our Ovt.c with you in a private manner to gain better understanding. If you can email zturner@eyelock.com I will be happy to share that information with you.

 

0 Likes
JayakrishnaT_76
Moderator
Moderator

Hello Zach and Henry,

I have sent an email to zturner@eyelock.com , please reply with the source code of the project after removing the sensor configuration settings.

In addition to this, can you please capture the signals VBUS, VDD, VDDIO1, CLK_IN and RESET# together using a scope and share the same with us?

Best Regards,
Jayakrishna
0 Likes
hgroover
New Contributor II

To conclude here, there were a couple of issues:

1. This problem occurred only with the CoolGear CG-3X2C3AM powered hub connected to a computer or laptop with a Type C connector.

2. When powering up the hub with the host computer connected but powered off, the hub would bring up the USB device in FS or HS mode.

3. The application running on the USB device would come up in FS or HS mode, and when the SS host finally connected, the initialization done with FS or HS mode active had set key parameters incorrectly.

In short, this was a problem with the USB device application not handling FS and HS properly. For our application the desired behavior was to either disable FS and HS altogether, or wait until SS is available to proceed with initialization.

Another problem with this specific hub was also observed while investigating this problem. Although this hub asserts both CC1 and CC2 in a way that indicates it is capable of 3A (and advertises that it can provide 3A at 19V as well as 5V), it actually does not apparently provide more than about 1.5A at 5V. This current shortage results in voltage drops to as low as 3.5V on VBUS, which therefore results in unstable behavior and spontaneous resets.

View solution in original post

0 Likes
JayakrishnaT_76
Moderator
Moderator

Hello,

We are glad to hear that the issue is resolved. As mentioned above, the problem was that the USB device enumerated as an HS or FS device in the failing case. The required mode of operation was SS. So, the configuration parameters used in initialization section of the firmware was not added correctly for HS and FS mode of operation. This led to the DMA failures. The issue was resolved by re-attempting SS mode until it became success before carrying forward with the rest of initialization.

Best Regards,
Jayakrishna
0 Likes