We have a matured product based on CX3. Even when majority of the instances work without any problem (let me call them "Healthy parts"), some of the units do not perform at all. Let's say 10% (let me call them "Problematic Parts").
Trying to find the problem in order to improve the yield rate beyond 90%, I have enabled the #define PRINT_FRAME_INFO so that I can observe what is going on.
First problem is that the variable "Printflag" never goes to 1 because the Callback that set this variable to 1 seems never to execute so, I forced it to 1 so that the line CyU3PMipicsiGetErrors( CyTrue, &errCnts); and CyU3PDebugPrint(...) of the line below always execute every several loops of the CyCx3UvcAppThread_Entry thread.
Surprisingly, I get the following two errors from MIPI block.
< Multi-Data Lane Sync Byte Error Count>
< Unrecoverable Packet Header Error Count>
(it is worth to mention that these counters remain in 0(zero) when testing the Healthy parts)
Can anybody share their experience if has experienced something similar?
1) There is no problem with firmware, given it is the same firmware for all units (Healthy and Problematic parts) and most of them are working since long time ago.
2) Just in case some CY3065 chips could not be performing ok at 100MHz of GPIF II, we have launched a firmware version with reduced GPIF II bus to 75MHz. But the same happens. Firmware is tested on healthy parts, DENEBOLA and work ok in both except in these several Problematic parts under examination.
Thank you so much.
Please let me know if swapping the CX3 from good board to not good board makes the not good board healthy.
Please confirm if the MIPI routing guidelines mentioned in Q8 of this KBA are followed.
Also, kindly share the CX3 configuration tool settings for us to check
I was surprised when I received the notification of "solution". I mean, your reply was marked as solution by someone else just a few days after you posted. I didnt mark it! So it is a bit confusing for others given I always thought that solution must be marked by the problem owner who really confirm that it is indeed a solution.
Honestly, it is not a solution at all, not even close to the problem. I would like to keep going ahead with this problem sharing with you and community the details of the problem. I am performing measurements and testing to reply to your recommendations.
We have a large production and we buy thousands of CX3 units for our products. We take support as a serious thing. I will respond to your last post in a couple of days once I have the report.
Thank you so much
Hello @IvPe_4204671 ,
I have unmarked the previous response as solution. We can carry forward the discussion regarding this issue on this thread. Please perform the threads and share the results with us. We will keep the thread open for further discussion on this issue.
Regarding Swapping the CX: If you mean to replace the IC from the "Problematic Board"
that is something that we are not able to do. It is a very tight board manufactured by a PCBA company, so replacing a BGA component
is not something that is common for us. What we have are many boards that work and some boards that dont.
Most aspects of MIPI routing have been addressed however, the differential pair are losely coupled.
Rise/Fall time in LP is really slow and we dont see any intra-pair crosstalk in simulation.
SIM REPORT for MIPI Lanes (Hyperlynx)
Differential Z = 98.7 ohms
Common-mode Z = 51.5 ohms
CX3 Configuration Tool
DataLanes = 4
CSI Clock = 305
H-Active = 1760
H-Blanking = 138
V-Active = 3120
V-Blanking = 80
Frame Rate = 16.5
Pre Divider Value = 3
PLL OutRange = 500M to 1G
Output Parallel Clock Divider = 8
Please refer to the following KBA to understand the description of each MIPI errors reported by CX3:
From the description of the errors and based on the fact that the same firmware is used for "Healthy" and "problematic" boards, we can suspect that the issue is on hardware.
When you say "Most aspects of MIPI routing have been addressed", do you mean to say that some of them are not followed? If yes, can you please let me know which guideline was missed?
We also want to check if the issue follows silicon or not. This is the reason why Rashi suggested for a swap test of BGA component (CX3). We would recommend to do this test as we can narrow down the root cause of the issue. Please check for the possibilities to do this test at your end and let us know the result.
Can you share a snapshot of the CX3 Receiver tab of MIPI configuration Utility. I find that information like THS-Prepare, THS-Zero, input format, output format etc are missing in the information that was shared in your previous response. Also, do let me know if you are padding or packing the incoming data.
I also like to mention that the CSI clock should not be configured as 305MHz when 4 lanes are used. Please refer to Q13 of the following KBA that mentions the maximum supported CSI clock setting corresponding to different number of lanes used:
We cannot guarantee the performance of CX3 beyond this limit. So, please configure the CSI clock below 300MHz when 4 lanes are used.
First of all: thank you so much for your quick reply and support.
* I also think the issue is on hardware. So let's concentrate on that.
* Now I am checking the routing based on the D-PHY Standard from mipi.org which strongly recommends a loosely coupled differential pair reaching a 25ohms common-mode impedance. (currently we have 51 ohms as I said in the previous post). In the recommendations you sent Q8, it says "double width separation" which would in some manner, indicate loosely coupled diff pair. Now we are working on a full characterization/simulation of our boards and connectors to see if this could be the problem.
* Let's put aside the CX3 replacement for a further task given we are not able to do it easily right now. It is easier for us to reroute the board and order a small production lot.
* The snapshot of Configuration tool is invalid in our case, given we make all configuration in the code since long time ago. The configuration tool has some bugs that has messed up several times so, I can share all the configuration you ask but not from screenshot but from .c files. The info missing is:
THS-Prepare = 33ns
THS-Zero = 216ns
These two values have been measured with oscilloscope and also double checked and matching with CIS AR1335 register values for these parameters.
This gives a THS-Settle of 140ns so the PHY Time Delay to be set is 14 clock cycles if CSI LP<->HS CLK is running at 100MHz (which is our case). This is indeed done with CyU3PMipicsiSetPhyTimeDelay() just after calling CyU3PMipicsiSetIntfParams() in cycx3_uvc.c file. (by the way, note that in CX3_TRM.pdf file, section 1.11.9 it indicates that this value can be set in the structure argumented for CyU3PMipicsiSetIntfParams() and it is not correct)
We are using 24bits by packing 3 pixels of 8 bits. RAW data.
* I understand the bottleneck of GPIF II where the maximum frequency is 100MHz and that implies a maximum of 2.4Gbps. However, MIPI lanes and core are not affected by this constraint (indeed they can run up to 1Gbps each). We can run at 305MHz because line blanking is long enough to finish downloading the MIPI core internal buffer of 511 words. We are not running into overflow nor underflow (please check your own posts explaining in details this topic). In any case, and just to be sure it is not a problem, we have tested healthy and problematic boards with the GPIF II running at 75MHz and reconfiguring the CIS_clk to 225MHz to match such speed with a perfect balance between input and output and the problem persists, I mean, we still have the same issue.
I would aim to routing problems, let me know your comments.
Firstly, I find that the THS-Prepare setting that you are using is less than the minimum required setting. Please configure the THS-Prepare setting above 46.56ns and below 94.84ns.
Secondly, we recommend to follow all the Layout guidelines for routing the signals. If you have not followed even one recommendation, then it should be corrected. If possible, you can address the layout issues and re route the board. But, we would recommend to perform the swap test before making the next revision of boards.
Lastly, can you let me know if the problems occurred on silicons from a specific lot? Or did the problems occur on newer silicons?
Can you please indicate where is the minimum THS-prepare required in the documentation? In this particular case (with our AR1335 CMOS Image Sensor) we can change such a value through registers, however, it is not possible for other CMOS Image sensors like Sony. They do not usually declare such registers to change D-PHY timing parameters. Please, indicate where I can find this value. Regarding changing the value, we succeed doing it and we moved it to 50ns and also beyond. It was confirmed through oscilloscope measurement. Unfortunately, it didn't show any change or it is not linked to the problem.
We are redesigning new PCBs paying special attention to recommendation, very carefull simulations are performed.
Swap CX3 between boards will take place in the following days.
Nevertheless, We have performed measurements as close as possible to CX3 pads and they incredible match to simulation. So please, check the
simulations attached here so that you can give your opinion.
We have performed as much tests as possible with the boards we have here (others are already sent to clients so it is not possible to test).
Remember we are finding problems between duplas, I mean: one particular instance of the Camera Module with one particular instance of CX3 bridge board.
That means the following: The problem is probably marginal or related to one lot of CX3.
All boards with CX3 (Bridge) and boards with CIS (Camera Modules) are exactly the same, produced same day by the same provider.
I-2101 CYP601139 Total of 11 samples, 3 of them don't work with some Camera Modules.
C-2007 CYP606557 Total of 3 samples, 1 of them doesn't work with some Camera Modules.
I-1943 CYP639529 Total of 3 samples, they work with any board perfectly.
Please find my comments below:
1. The minimum THS-Prepare required is provided by the CX3 configuration utility. The tool internally uses this to calculate the Phy Time Delay value.
2. Regarding your second point, do you mean to say that the simulation results on your board and the actual measurements showed the same results? Please correct me if my understanding is wrong.
Also, please provide description for each snapshot shared in your previous response so that we can better understand them. In addition to this, I believe that the new board is designed by following all the hardware guidelines. Please confirm this.
In addition to this, please let us know how the simulations were done. Was it done by using IBIS file?
3. We will wait for the results of the swap test to see the issue is following silicon or not. Please share the results after the test is completed. Can you please share photos of silicon from Failing lots?