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:
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.
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.
Thank you for the quick reply to our issue.
Your understanding is on point.
Our device is in Bus power mode
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:
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?
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.
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.
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.
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.
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 firstname.lastname@example.org I will be happy to share that information with you.
Hello Zach and Henry,
I have sent an email to email@example.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?