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: FPD3_ENC_CRC_CAP and LINE_CNT_CHG

Part Number: DS90UB954-Q1

Hello TI Team,

i use the DS90UB954 with the DS90UB953. I have a few questions:

1. I can not set the FPD3_ENC_CRC_CAP in Regsiter 0x4A BIT 4. It is permanently at 0. I want to set ist because in the Datasheet it is recommendet to set it 1. How can I set it? Regsiter 0xBA Bit 7 can be set to 0.

2. Although the bit (0x4a) is set to 0, CRC errors can be recognised if I generate them through interference. Is this correct?

3. What does the Encoder Enable do (0x4A and 0xBA) even if it already works with false register setting?

4. From time to time i get some LINE_CNT_CHG. In my first setup I used 400 kHz I2C Clock at the Deserializer and 400 kHz at the Serializer. After I set the Clock at the Deserialzer to 100 kHz the errors were reduced by a factor of 36. What can it be? Some further informations: The MAP Test is very good, I get no parity or CRC errors, it is independent of the PoC current or ripple.

  • Hi Dirk,

    Register 0x4A is a port specific register. In order to write to this register and read back the value, reads and writes must be enabled for the intended port in register 0x4C. Register 0xBA is not a port specific register. 

    Register 0x4A enables a CRC error flag from the FPD-Link III encoder. It does not change the ability of the deserializer to recognize BCC CRC errors. The encoder enable in register 0xBA is a CRC check of the FPD-Link III encoder sequence, and serves as an extra layer of CRC checking. 

    For the question regarding LINE_CNT_CHG being asserted: 

    1. Is PATGEN being configured on the serializer or is an imager being used? 
    2. Is the LINE_CNT_CHG bit seen on initialization or is this error reoccuring? We recommend clearing all errors on startup of the device, if the errors are reoccurring this would potentially reflect an issue during normal operation. 
    3. Would you be able to provide a register dump of the 953 and 954 while this issue is being observed and one during a normal case? 

    Best,

    Zoe

  • Hi Zoe,

    thanks for your answer.

    Now I can enable the CRC error flag. However, I am still not quite sure what the flag does if the CRC errors are already registered correctly without this flag. Is there a more detailed explanation of this?
    Do I understand correctly that the encoder enable in 0xBA extends the CRC check? If this is not active, will some errors definitely not be recognised?

    Regarding to LINE_CNT_CHG:

    1. A imager is used.

    2. If i use the system in Livestream Mode no errors appear. If i use it in snapshot mode they appear. With 400 kHz I2C Clock at the Deserializer relativly fast (after 1 to 5 Minutes, approx 25-125 Snapshots). With 100 kHz after approx 3 hour (4500 Snapshots). It is surprising me that I have a dependency on the I2C clock. Even if the error occurs, the snapshots are error-free (testpattern of the image sensor).

    In snapshot mode, a part could possibly be reinitialised, as settings are made before capturing. However, I do not currently know exactly which accesses are carried out. I will be able to provide more details next week if they are still needed.

    3. Here are a register dump for normal case (I grab a image of 1920x1200):

    DS90UB954:
         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
    00: 7a 00 1e 20 df 01 00 fe 1c 10 7a 7a 83 b9 0c 7f    z.? ??.???zz????
    10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 02    ..............??
    20: 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00    .?..............
    30: 00 00 00 01 40 01 00 00 00 00 00 01 14 6f 00 40    ...?@?.....??o.@
    40: 00 a7 71 01 00 00 00 00 00 00 00 12 00 03 04 64    .?q?.......?.??d
    50: 00 00 00 03 00 00 00 00 5e 00 00 30 00 ac 20 30    ...?....^..0.? 0
    60: 00 00 00 00 00 ac 20 30 00 00 00 00 00 7c 88 88    .....? 0.....|??
    70: 2b 2c e4 04 b2 07 80 c5 00 01 00 00 20 00 00 00    +,??????.?.. ...
    80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    a0: 02 0f 00 00 08 18 00 00 00 00 00 00 00 00 00 00    ??..??..........
    b0: 08 14 3f 08 25 00 18 00 fc 33 03 74 80 00 00 00    ????%.?.?3?t?...
    c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    d0: 00 43 94 02 60 e2 00 00 00 00 00 00 00 00 00 00    .C??`?..........
    e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    f0: 5f 55 42 39 35 34 00 00 e0 e2 00 00 00 00 00 00    _UB954..??......
    DS90UB953:
         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
    00: 30 00 32 48 00 03 41 24 fe 1e 10 19 19 78 87 00    0.2H.?A$?????x?.
    10: 00 00 00 00 00 20 18 3c 80 62 62 62 00 00 00 00    ..... ?<?bbb....
    20: 00 00 00 00 00 02 00 00 67 33 01 00 00 00 00 00    .....?..g3?.....
    30: 00 20 09 04 00 10 00 7a 00 00 00 00 00 00 00 00    . ??.?.z........
    40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    50: 20 c0 45 00 00 00 00 00 07 07 07 00 00 00 00 00     ?E.....???.....
    60: 00 2a 80 07 0b c8 00 00 00 00 00 00 00 00 00 00    .*????..........
    70: 00 00 25 00 00 00 00 00 00 00 e4 00 00 00 00 00    ..%.......?.....
    80: 00 00 00 00 00 00 90 00 00 00 00 00 03 00 00 00    ......?.....?...
    90: 32 e3 64 01 00 00 00 00 00 00 21 24 03 00 01 0e    2?d?......!$?.??
    a0: 00 0e 0e 0d 0d 10 42 10 10 10 03 01 00 00 00 00    .?????B?????....
    b0: 04 4a 3f 00 00 00 00 00 00 00 00 00 00 00 00 00    ?J?.............
    c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    f0: 5f 55 42 39 35 33 00 00 00 00 00 00 00 00 00 00    _UB953..........

    Here with Line length change:

    DS90UB954:

         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
    00: 7a 00 1e 20 df 01 00 fe 1c 10 7a 7a 83 b9 0c 7f    z.? ??.???zz????
    10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 02    ..............??
    20: 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00    .?..............
    30: 00 00 00 01 40 01 00 00 00 00 00 01 14 6f 00 40    ...?@?.....??o.@
    40: 00 a7 71 01 00 00 00 00 00 00 00 12 00 03 05 64    .?q?.......?.??d
    50: 00 00 00 03 00 00 00 00 5e 00 00 30 00 ac 20 30    ...?....^..0.? 0
    60: 00 00 00 00 00 ac 20 30 00 00 00 00 00 7c 88 88    .....? 0.....|??
    70: 2b 2c e4 04 b1 07 80 c5 00 01 00 00 20 00 00 00    +,??????.?.. ...
    80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    a0: 02 0f 00 00 08 18 00 00 00 00 00 00 00 00 00 00    ??..??..........
    b0: 08 14 3f 08 25 00 18 00 fc 33 03 74 80 00 00 00    ????%.?.?3?t?...
    c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    d0: 00 43 94 02 60 e2 00 00 00 00 00 00 00 00 00 00    .C??`?..........
    e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    f0: 5f 55 42 39 35 34 00 00 e0 e2 00 00 00 00 00 00    _UB954..??......

    DS90UB953:
         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
    00: 30 00 32 48 00 03 41 24 fe 1e 10 19 19 78 87 00    0.2H.?A$?????x?.
    10: 00 00 00 00 00 20 18 3c 80 62 62 62 00 00 00 00    ..... ?<?bbb....
    20: 00 00 00 00 00 02 00 00 67 33 01 00 00 00 00 00    .....?..g3?.....
    30: 00 20 09 04 00 10 00 7a 00 00 00 00 00 00 00 00    . ??.?.z........
    40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    50: 20 c0 45 00 00 00 00 00 07 07 07 00 00 00 00 00     ?E.....???.....
    60: 00 2a 80 07 0b c8 00 00 00 00 00 00 00 00 00 00    .*????..........
    70: 00 00 25 00 00 00 00 00 00 00 e4 00 00 00 00 00    ..%.......?.....
    80: 00 00 00 00 00 00 90 00 00 00 00 00 03 00 00 00    ......?.....?...
    90: 32 e3 64 01 00 00 00 00 00 00 21 24 03 00 01 0e    2?d?......!$?.??
    a0: 00 0e 0e 0d 0d 10 42 10 10 10 03 01 00 00 00 00    .?????B?????....
    b0: 04 4a 3f 00 00 00 00 00 00 00 00 00 00 00 00 00    ?J?.............
    c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    f0: 5f 55 42 39 35 33 00 00 00 00 00 00 00 00 00 00    _UB953..........

    With best regards,

    Dirk

  • Hi Dirk, 

    For the single snap shot mode, is an ISP being used to reconfigure the image sensor between captures? How is this single snapshot mode being executed? Is there any reconfiguration of the serializer or deserializer between these captures? 

    Best,

    Zoe

  • Hi Zoe,

    no ISP is used between our SoC and the image sensor.

    Do you have any idea about the dependency of the I2C clock on this behaviour?

    I will get back to you next week about the possible reconfiguration once I have spoken to our responsible software expert.

  • Hi Dirk, 

    Thank you for the clarification. Since the failure rate has been observed to be correlated to the I2C transaction rate, the change in line count is likely due to an issue on the image sensor. 

    Has there been any observations of the I2C bus when the issue is observed? For instance, is there any confirmation of what is being written to the sensor and what is read back on these transactions? 

    In addition, it was stated the resolution was 1920x1200 however, the line count registers shared in the register dumps correlate to x1201 and x1202. What is the resolution of the images being captured? 

    Best,

    Zoe 

  • Hello Zoe,

    Some registers are reconfigured when the stream is started or stopped.

    Here is the overview:

    UB953: GENERAL_CFG : CSI_LANE_SEL (bits 4 and 5) BC_CTRL: BIST_CTC_ERR_CLR (bit 5) and CRC_ERR_CLR (bit 3)

    Both registers are not actively reset after stop the stream.

    UB954: CSI_CTL: CSI_EN (bit 0), LANE_COUNT (bits 4 and 5), CSI_CAL_EN (bit 6).

    All bits except LANE_COUNT are reset after stream stop. CSI_CONTS_CLOCK (bit 1) is only reset, but we can't remember why. FWD_CTL1: FWD_PORT0_DIS or FWD_PORT1_DIS (bit 4/5) depending on the port used. Is actively reset again.

    The reason why there are 1202 and not 1200 lines is that the sensor used (AR0234) outputs two lines of embedded data. But this line are not used by as at the moment.

    We do no confirmation of what is being written to the sensor. But at least the register dump does not show any errors.

    Best regards,

    Dirk

  • Further Information. I disabled the embedded data of the imaging sensor. Now I get 1200 lines if no error is detected. If the Error appears the Frame as now 1199 or 1198 lines.

    However, the snapshot never contains errors. Perhaps another incomplete frame may be sent after the actual snapshot. It looks like the sensor may be sending a second incomplete frame here.

  • Hi Dirk, 

    Thanks for the insight on the project. What is the reason for changing the CSI Lane select bits when the stream starts/stops? Can you provide more insight on this configuration?

    Best,

    Zoe

  • Hello Zoe,

    After consultation with the software developer, we do not reset the CSI_LANE_SEL, but we rewrite the configuration at each start. In this case, we set it to the value already set for 4 lanes each time.

  • Hi Dirk, 

    The CSI_LANE_SEL does not need to be written to each time however, I would not expect this to be the source of the issue. Since the issue rate has been correlated to the I2C transaction speed, we would expect this to be an image sensor issue. Is the incomplete frame send immediately after a complete frame? What is the CSI clock settings of the imager and what is the speed of operation? 

    Best,

    Zoe

  • Hello Zoe,

    I now also think that it is an image sensor issue. I only grab one Frame but because of the delay of the operating system the image sensors sends 4 frames until it is stopped again. Perhaps the last frame is corrupt. I have no protokoll analyser to check the frames.

    The sensor works with 97 fps and 288 MHz at the CSI clock Lane. We grab a picture every second.

    If you also think it is a imager issue we can close this issue. Thanks you very much for your support!

  • Hi Dirk, 

    Understood, this is likely an issue with the sensor not stopping sending data on a Frame Start or Frame End packet. Let me know if there are any further questions or support needed! I will close this thread for now but, feel free to reopen by posting a new reply on the thread. 

    Best,

    Zoe