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.

DS90UB954-Q1: DS90UB954-Q1 Randomly count error

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

Hi Sir,

We find that 954 errors are randomly counted.

When errors are counted, CSI output will stop at that moment. Our system will shut down.

We print 954 registers: 0X35=1, 0X37=3, 0x4D=53, 0X4E=24.

Is there any reason for the error count, or is there any way to set 954 to reduce errors?

We used ALP to check cable quality, and it looks good.

  • Hello Song_po,

    What Serializer is being used on the system? Do you have ability to turn on the Patgen on the Ser? Want to see if you still have errors when using patgen from the ser.

    Can you provide the following:

    1. How many units are experiencing this issue?
    2. Simple block diagram of the system. Include FPD rate, resolution, data type, and CSI rate?
    3. Register dumps of a passing and failing run? 

    Thank you,

    Glenn 

  • Hi sir,

    Sorry for late

    Serializer is DS90UB953.

    1.We have 6 units. Each unit can try this issue. We have attempted to reboot 954 300 times, with approximately 40 times.

    2.

    * FPD rate : 1.83G

    * Resolution : 2592 * 732

    * data type : MIPI

    * CSI rate : 460.8/Lane

    3.Referring to the text, we dump 3 times 954 CIS error register to ref.

    954 log.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    Apr 1 00:00:29 Check954: DESERIALIZER_ICG 0x35= 1
    Apr 1 00:00:29 Check954: DESERIALIZER_ICG 0x37= 3
    Apr 1 00:00:29 Check954: DESERIALIZER_ICG 0x4D= 115
    Apr 1 00:00:29 Check954: DESERIALIZER_ICG 0x4E= 229
    Apr 1 00:00:29 Check954: read_ICG_RXPARERRLO_value= 0
    Apr 1 00:00:29 Check954: read_ICG_RXPARERRHI_value= 0
    Apr 1 00:00:29 kernel: [ 33.043023] 954 debug 0 : read = 60
    Apr 1 00:00:29 kernel: [ 33.047655] 954 debug 1 : read = 0
    Apr 1 00:00:29 kernel: [ 33.052199] 954 debug 2 : read = 1E
    Apr 1 00:00:29 kernel: [ 33.056650] 954 debug 3 : read = 20
    Apr 1 00:00:29 kernel: [ 33.061064] 954 debug 4 : read = DF
    Apr 1 00:00:29 kernel: [ 33.065475] 954 debug 5 : read = 1
    Apr 1 00:00:29 kernel: [ 33.069900] 954 debug 6 : read = 0
    Apr 1 00:00:29 kernel: [ 33.074228] 954 debug 7 : read = FE
    Apr 1 00:00:29 kernel: [ 33.078656] 954 debug 8 : read = 1C
    Apr 1 00:00:29 kernel: [ 33.083069] 954 debug 9 : read = 10
    Apr 1 00:00:29 kernel: [ 33.087533] 954 debug A : read = 7A
    Apr 1 00:00:29 kernel: [ 33.091950] 954 debug B : read = 7A
    Apr 1 00:00:29 kernel: [ 33.097226] 954 debug C : read = AB
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    .

  • Hi Song_po, 

    Thanks for the update. In the initial MAP results, was the imager on while this data was collected? I recommend having the image powered on during this testing as link may be impacted while MAP is running. 

    Additionally, is there a reason register 0x41 was changed from 0xA7 to 0xE0? We recommend setting 0x41[3:0] to 0x9 for better link margin. 

    Best,

    Zoe