This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DS90UB953-Q1: CSI_ERR flags at low temperatures

Part Number: DS90UB953-Q1
Other Parts Discussed in Thread: DS90UB954-Q1, ALP

Hello,

While using a DS90UB953-Q1 serializer with OV10652 imager in a camera design, I am noticing five different cameras showing errors on the CSI_ERR_CNT (0x5C), and either the CSI_ERR_DLANE01 (0x5E) or CSI_ERR_DLANE23 (0x5F) registers while testing them at -40C.

For example, with one camera, polling the registers shows the following:

CSI_ERR_CNT (0x5C) = 4A

CSI_ERR_DLANE01 (0x5E) = 60

 

My question is: What can be done to better understand the reason for these errors and what can be done to troubleshoot the cause?

  • Hi Gerald,

    Have you implemented the code for temperature ramp initialization as per the 953 Datasheet Pages 75 and 76? Additionally, for a quicker system bringup time, we recommend to program 0x0A = 0x12. Please see Datasheet Section 7.3.1.1 System Initialization for more details.

    My question is: What can be done to better understand the reason for these errors and what can be done to troubleshoot the cause?

    These CSI errors reported on the Serializer are originated from the data incoming from the sensor. Specifically, the error registers 0x5E and 0x5F report errors related to any of the specific 4 CSI data lanes being input into the SER. Does your camera have diagnostic functionality as well and have any errors reported?

    To better troubleshoot, I would first recommend implementing the temperature ramp script and to program 0x0A = 0x12 during initialization. If problems are still encountered, it would be good to take a full register dump of both the SER and DES during operation and send it here for review.

    Could you also provide more details of your test setup and procedure such as:

    Are you bringing the temperature to -40C and then turning on the 953 serializer? Or are you ramping down the temperature while the 953 is powered-up? Are both the SER and DES in the temp chamber together? 

    Best,

    Ethan Woods

  • Hi Ethan,

    We have not implemented the temperature ramp code, as we do not have the ability to dynamically set the values as shown in the example during tests. I will try manually setting the correct configuration based on the starting die temp as see if that affects the outcome while at -40C. I can also try setting the watchdog timer speedup to 0x0A = 0x12 as well.

    We have tested a batch of cameras and are seeing 5 with similar issues regarding CSI_ERR flags being set, so I will get a dump of the SER and DES at temperature and send for review.

    For the test procedure, the test chamber is ramped to 25C, then to 85C, then to -40C, then ramped back to 25C. At each temperature, the camera is powered on and initialized along with the onboard serializer, while the deserializer remains outside the chamber. Once data is taken at temperature, the camera (and serializer) is powered off before ramping to the next temperature in sequence.

  • Hi Gerald,

    Thank you for giving me more information about your test setup. Given this, temperature ramp should not be the main issue at hand here since the SER is being powered on already at temp. You can attempt to manually set it, but if there is no actual temperature ramp going on, then this should not be an issue. The watchdog timer speedup should help, but I don't think it will also help with this specific test. These changes were more so for link stability at lower/higher ramping temperatures.

    Looking a bit more into the specific CSI errors you have seen, the CSI_ERR_DLANE01/ CSI_ERR_DLANE23 registers flag errors on incoming data into the Serializer. That is, it typically means either the image sensor is configured incorrectly and outputting bad data, or the MIPI traces are bad, which is causing the serializer to receive corrupted data.

    Do you know if the OV10652 has any diagnostic capabilities? If so, has it reported any errors? Looking forward to your register dumps as well. If possible, a working and failing case would be ideal.

    Best,

    Ethan Woods

  • Ethan,

    I have the dumped SER/DES information from two cameras, both at -40C and 25C for comparison. I am looking to get the data for two more units and will share when it is available. 

    SERDES Dump Summary_2.xlsx

    The OV10652 imager has diagnostic registers that are being monitored as well, but I have not seen anything of concern during testing.

  • Hi Gerald,

    Thanks for getting the register dumps. Give me a day or two to look over them and see what I can find.

    Best,

    Ethan Woods

  • Hello Gerald,

    Thank you for your patience. I have gone over the register dump provided. See below for feedback and some questions.

    Register dump feedback:

    On the Deserializer (assuming DS90UB954-Q1 since it was not stated, but register IDs correlate), I did not find any critical issues. The main difference between the failing case and the working case is the assertion of the Serializer Alarm bits in the SENSOR_STS_0 (0x51) register and the SENSOR_STS_3 (0x54) register. The Serializer alarms that were flagged in register 0x51 is the CSI_ALARM and the LINK_DETECT_ALARM. In register 0x54, U04 Hex had the CSI_CNTRL_ERR flagged while the U13 Hex had the CSI_SYNC_ERR flagged.

    Similar in both temperature cases, the Deserializer reported a line length change and line count change flag, meaning there was a change of line length/count detected in the data incoming to the Deserializer. Typically, this is followed with some sort of a flagged error, but the Deserializer in both cases did not report any CSI errors or any other type of errors outside of the Alarm bits from the Serializer. 

    On the Serializer, this is where you saw the errors that were flagged in registers 0x5E and 0x5F. The errors that were different between temperatures was a T_SENSOR_LO flag in the SENSOR_STATUS (0x57) register, a TEMP_MIN bitfield difference [2:0] in the SENSOR_T (0x5A) register, and then the errors already seen in the CSI_ERR_DLANE01/23 (0x5E/0x5F) registers. The temperature sensor flags correlate with the internal temperature of the device, so it is expected these would be flagged at the minimum operating temperature. Other than these errors, no other CSI errors were reported in the CSI_ERR_STATUS (0x5D) register. This likely points to an issue to data coming into the Serializer.

    Before giving some recommendations for next steps, can you please help answer the questions below:

    • Can you give some more details about your system? What is the Deserializer? What is the cable and length between the SER and DES you are currently using? What is the imager resolution, fps, datatype, and blanking (for a bandwidth estimation)?
    • What does the failure look like outside of the error flags? Are you observing the video output from the Deserializer and see any visual disturbances? With the Deserializer reporting no CSI errors, I am interested to see if there is a disturbance in the video output after the SERDES chain.
    • What is the failure rate of your Serializer boards? How many different boards were tested? Did they all fail or did only some of them fail?
    • If there is a working board with a working Serializer at cold temps, can you replace a failing Serializer to a working board and see if it then fails?
    • Have you tested Pattern Generation (PATGEN) on the Serializer to bypass the imager? If so, did the Deserializer or Serializer report any errors?
    • Are these errors one-off? As in, once they are cleared upon reading, do they return?
    • If the resolution or data rate from the Imager is lowered does this issue reproduce?
    • If the video bandwidth is low enough (below 1.6 Gbps from the imager), does lowering the CSI data rate from 800 Mbps (current data rate) to 400 Mbps on both the SER and DES show any improvement?
    • To my previous understanding, the Serializer board is not powered on until the temperature chamber has reached the desired temperature. Is this correct? At this temperature, have you experienced any issues with locking or have the errors only been CSI related?

    Looking forward to your responses.

    Best,

    Ethan Woods

  • Hi Ethan,

    Thank you for reviewing the data and providing this feedback. It does sound like it could be an issue stemming from the data coming into the serializer.

    As for your questions

    • The Deserializer is indeed the DS90UB954-Q1. The camera module contains the 953 serializer on the same board as the OV10652 imager. In the test setup, the camera connects via fakra cable to a separate board with the 954 deserializer, which can connect to a computer via USB for monitoring. The fakra cable length is around 7m. Imager resolution is 1824x940 @ 36fps, 12-bit Combined HDR RAW datatype, 620px horizontal blanking and 291px vertical blanking.
    • I have not noticed any visual disturbances in the image when the errors manifest.
    • I am testing a total of 52 cameras, and 5 cameras are showing CSI-related errors on their serializers. Each of the 5 cameras were tested on three different benches (different cables, deserializer board, and computer) to rule out potential bench setup issues, and the errors were able to be replicated.
    • I could try this, but at this point we have not performed any destructive testing on the cameras.
    • This also sounds like a good idea to help narrow down the cause. I assume this is in section 6.7.2.1 - Is there a recommended configuration for this test?
    • Yes, the errors return if the camera is still being tested at -40C
    • I will try a test with this and share the results early next week.
    • I will also try this
    • Yes, the testing is typically performed this way. The entire camera is powered on at -40C, and during the test the onboard serializer is monitored. During these tests I am not seeing errors from the imager or deserializer, or seeing other errors with locking on the serializer.

    Early next week I should be able to try some of the tests you have suggested and share the results. Thank you for the great feedback and suggestions so far.

  • Hi Gerald,

    Thank you for answering the questions so quickly and for your feedback as well, its greatly appreciated.

    Since you are not seeing any visual disruptions on the output video stream during testing, the main issue at hand here is to determine what is causing the errors to be flagged on the Serializer. Is this correct?

    Given that there are only failures in some camera modules, PATGEN could be a good tool to "bypass" the camera module and determine if there are any issues within the Serializer itself. 

    This also sounds like a good idea to help narrow down the cause. I assume this is in section 6.7.2.1 - Is there a recommended configuration for this test?

    Pattern Generation can be used to create a video stream that is generated on the Serializer, essentially removing the imager from the testing. PATGEN configuration requires a specific set of I2C writes to the indirect register map on the 953. A code example for PATGEN can be found in Section 6.6.4 in the 953 Datasheet. Additionally, if you have access to the local I2C bus on the Deserializer, you can connect to our Analog Launchpad (ALP) software for easier PATGEN configuration through the GUI. Please find the ALP software here: ALP Support software | TI.com. For additional information of how to use ALP with the 953, please see the DS90UB953-Q1 EVM User Guide.

    Also, below is a calculator tool you can use to determine the register values for the specific resolution, data type, blanking, and other properties of PATGEN you want instead of doing it through ALP. We recommend testing a PATGEN sequence that is very similar to the video stream coming from your connected imager.

    PATGEN Calculator.xlsx

    Could you also test a temperature ramp up from -40C (where errors occur) to -30C or -20C to see if the errors disappear? This would also be helpful to know the results of this test.

    I will discuss your response with the team for further recommendations while you are testing early next week. Looking forward to the rest of your results.

    Best,

    Ethan Woods

  • Hi Ethan, I'm still working on the last set of recommended tests, though I was able to identify the reels where the serializers came from: 3771836ZGT, 3584872ZGT, and 3748677ZGT. Would this be helpful for looking up the lot they came from and determining if there are any known issues?

  • Hi Gerald,

    Thank you for the update.

    The best way to identify the lots would be to write down the top markings on the affected Serializers. Since this is a public forum, you can reach out to me at e-woods@ti.com for further discussion related to this. This thread should continue to reflect the current debug, and we can update accordingly with any findings from external communication.

    Best.

    Ethan Woods

  • Eric,

    While we discuss that separately, I will post the results of other testing that was performed.

    This was performed on two cameras, placed into a chamber and ramped to -40C.

    I wrote a script to disable the OV10652 imager and enable PATGEN, changing the following:


    // Enable Pattern Generator
    SERIAL_REG = 0x30, 0xB2, 0x01, 8:8

    // Color Bar Pattern Generation
    SERIAL_REG = 0x30, 0xB2, 0x33, 8:8

    // CSI-2 Data Type = RAW12
    SERIAL_REG = 0x30, 0xB2, 0x2E, 8:8

    // Line Size = 2736 Bytes
    // Corresponds to 1824 Pixels in RAW12 Format
    SERIAL_REG = 0x30, 0xB2, 0x0A, 8:8

    SERIAL_REG = 0x30, 0xB2, 0xB0, 8:8


    // Produce 8 Vertical Color Bars Across Image
    SERIAL_REG = 0x30, 0xB2, 0x00, 8:8


    SERIAL_REG = 0x30, 0xB2, 0xE4, 8:8


    // Active Frame Height = 944 Lines
    SERIAL_REG = 0x30, 0xB2, 0x03, 8:8


    SERIAL_REG = 0x30, 0xB2, 0xB0, 8:8

    // Total Frame Height = 960 Lines
    SERIAL_REG = 0x30, 0xB2, 0x03, 8:8


    SERIAL_REG = 0x30, 0xB2, 0xC0, 8:8

    // Line Period
    SERIAL_REG = 0x30, 0xB2, 0x0B, 8:8

    SERIAL_REG = 0x30, 0xB2, 0xF5, 8:8

    // Vertical Back Porch
    SERIAL_REG = 0x30, 0xB2, 0x04, 8:8

    // Vertical Front Porch
    SERIAL_REG = 0x30, 0xB2, 0x08, 8:8

    With this, the imager was disabled and the following image was being sent:

    Initializing with these settings, I am still seeing the following on the serializer registers at -40C:

    CSI_ERR_CNT (0x5C) = 0x01

    CSI_ERR_DLANE01 (0x5E) = 0x26 

    CSI_ERR_DLANE23 (0x5F) = 0x60

    This is interesting. What do you make of it?

  • Hello Gerald,

    This is interesting to me as well. PATGEN generation is AFTER the CSI diagnostics/error detection block in the Serializer, so there should be no CSI errors associated with it.

    This leads me to a couple of questions:

    • Was this the first time the error registers were pulled? These registers are clear on read, so with PATGEN enabled, do they have this same error each time?
    • Lane specific errors are only flagged on INCOMING data, before the PATGEN block. Are you sure that the imager is disabled and not sending any sort of data to the Serializer? This is just a sanity check.
    • Are there any CSI errors being flagged on the Deserializer? Note, from previous register dumps, there were no CSI errors reported. You can find if there are any CSI errors by looking at register 0x7B on the Deserializer. If 0x7B is non-zero, then there is at least 1 CSI error reported

    Looking forward to the rest of your results and answers.

    Best,

    Ethan Woods

  • Ethan,

    Let me provide some more details

    • I had our tech run the test three times on two different cameras, reinitializing the camera between each test
      • While some tests came back clear, both eventually had CSI-related errors during the soak in the chamber.
      • The register content was not the same each time. For completeness, I will list the register contents for the SER/DES on each trial

    Unit 05 - Trial 1:

    CSI_ERR_CNT (0x5C) = 0x00

    CSI_ERR_DLANE01 (0x5E) = 0x00

    CSI_ERR_DLANE23 (0x5F) = 0x00

    SENSOR_STS_0 (0x51) = 0x28

    SENSOR_STS_3 (0x54) = 0x00

    Unit 05 - Trial 2:

    CSI_ERR_CNT (0x5C) = 0x24

    CSI_ERR_DLANE01 (0x5E) = 0x02

    CSI_ERR_DLANE23 (0x5F) = 0x06

    SENSOR_STS_0 (0x51) = 0x28

    SENSOR_STS_3 (0x54) = 0x00

    Unit 05 - Trial 3:

    CSI_ERR_CNT (0x5C) = 0x01

    CSI_ERR_DLANE01 (0x5E) = 0x44

    CSI_ERR_DLANE23 (0x5F) = 0x44

    SENSOR_STS_0 (0x51) = 0x28

    SENSOR_STS_3 (0x54) = 0x00

    Unit 18 - Trial 1:

    CSI_ERR_CNT (0x5C) = 0x00

    CSI_ERR_DLANE01 (0x5E) = 0x00

    CSI_ERR_DLANE23 (0x5F) = 0x00

    SENSOR_STS_0 (0x51) = 0x28

    SENSOR_STS_3 (0x54) = 0x00

    Unit 18 - Trial 2:

    CSI_ERR_CNT (0x5C) = 0x00

    CSI_ERR_DLANE01 (0x5E) = 0x02

    CSI_ERR_DLANE23 (0x5F) = 0x00

    SENSOR_STS_0 (0x51) = 0x28

    SENSOR_STS_3 (0x54) = 0x00

    Unit 18 - Trial 3:

    CSI_ERR_CNT (0x5C) = 0x25

    CSI_ERR_DLANE01 (0x5E) = 0x06

    CSI_ERR_DLANE23 (0x5F) = 0x06

    SENSOR_STS_0 (0x51) = 0x28

    SENSOR_STS_3 (0x54) = 0x00

    • Before these tests and activating PATGEN, OVT10652 register was set 0x3012 = 0x00, to end streaming and put the chip into standby. I will have our tech try another test where the Imager is set into a Power Down state instead of a Standby state to see if there is a difference in behavior.
    • While rerunning the test, I will record the contents of 0x7B and report back
  • I rewrote the initialization for the camera so the test could be re-run, this time setting the Imager into a Power Down state before enabling PATGEN and running the test at -40C

    Unit 05 - Trial 1:

    CSI_ERR_CNT (0x5C) = 0x00

    CSI_ERR_DLANE01 (0x5E) = 0x00

    CSI_ERR_DLANE23 (0x5F) = 0x00

    SENSOR_STS_0 (0x51) = 0x28

    SENSOR_STS_3 (0x54) = 0x00

    Unit 05 - Trial 2:

    CSI_ERR_CNT (0x5C) = 0x00

    CSI_ERR_DLANE01 (0x5E) = 0x00

    CSI_ERR_DLANE23 (0x5F) = 0x00

    SENSOR_STS_0 (0x51) = 0x28

    SENSOR_STS_3 (0x54) = 0x00

    Unit 18 - Trial 1:

    CSI_ERR_CNT (0x5C) = 0x1D

    CSI_ERR_DLANE01 (0x5E) = 0x40

    CSI_ERR_DLANE23 (0x5F) = 0x00

    SENSOR_STS_0 (0x51) = 0x28

    SENSOR_STS_3 (0x54) = 0x00

    Unit 18 - Trial 2:

    CSI_ERR_CNT (0x5C) = 0x00

    CSI_ERR_DLANE01 (0x5E) = 0x00

    CSI_ERR_DLANE23 (0x5F) = 0x00

    SENSOR_STS_0 (0x51) = 0x28

    SENSOR_STS_3 (0x54) = 0x00

    I mistakenly did not have our tech report the contents of the 0x7B register, so I will try to run the test again to gather as well. Regardless, it still seems there are is an instance were bits are flagged on some of the serializer registers.

  • Hello Gerald, 

    Thank you for providing the latest test results. A value of 0x28 in the SENSOR_STS_0 register corresponds to the alarm flags for CSI error and link detect from the Serializer, but in many of the trials, there are no CSI errors flagged on the Serializer. 

    This is still interesting to see that even with the imager in a power-down state, there are still lane specific errors being flagged. As stated before, this error should not flag unless there is some sort of data incoming into the serializer in the connected CSI data lanes. 

    During this test, was there any point in time that the imager was sending data to the Serializer, possibly causing these flags to appear? That is, during the initialization process, is there any point the imager is enabled and sending data before it is disabled? This is the only reason I can think of why these specific errors are flagged on the Serializer.

    In the future, if this test is run again and these specific data lane errors appear, could you re-read the associated registers a couple of times with some delay between to see if the errors re-flag themselves after you have enabled PATGEN?

    Note, an additional register you could monitor would be the CSI_ERR_STATUS (0x5D) register on the Serializer, which holds the rest of the CSI error flags that would count towards the total CSI error count in register 0x5C.

    Best,

    Ethan Woods