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.

DS90UB960-Q1: Image ghosting issue

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

Hi team,

There are 4 UB953 connected using UB960, only /dev/video0 can get the picture. The ghosting picture looks like four images are overlaid: 

The reading value of CSI_VC_MAP Register (Address 0x72) is 0xE4.

What might be the cause of the issue? Could you help check it? Thanks.

Best Regards,

Cherry

  • Hi Cherry,

    Register 0x72 is a virtual channel mapping register. It is 0xE4 by default, so the VC-IDs of incoming CSI-2 packets are mapped as follows: VD-ID of 3 = 3, VC-ID of 2 = 2, VD-ID of 1 = 1, and VD-ID of 0 = 0. If needed, you can remap them depending on how your SOC is configured.

    To be able to debug this issue, can you send a register dump of the 960? 

    Can you also send any script that you are using to program the registers?

    Regards,

    Cindy

  • Hi Cindy,

    Thank you for the support.

    The following BUF is the register address and corresponding write value that the system writes to 90UB960 when boot:

    u8 buf[41][2] = {{0x01,0x07},{0x0c,0x0F},{0x1f,0x02}\

    ,{0x4c,0x01},{0x6d,0x7c},{0x58,0x5e},{0x5c,0x30},{0x5d,0x94},{0x65,0x94},{0x5e,0xda},{0x66,0xda}\

    ,{0x4c,0x12},{0x6d,0x7c},{0x58,0x5e},{0x5c,0x32},{0x5d,0x94},{0x65,0x84},{0x5e,0xda},{0x66,0xca}\

    ,{0x4c,0x24},{0x6d,0x7c},{0x58,0x5e},{0x5c,0x34},{0x5d,0x94},{0x65,0x74},{0x5e,0xda},{0x66,0xba}\

    ,{0x4c,0x38},{0x6d,0x7c},{0x58,0x5e},{0x5c,0x36},{0x5d,0x94},{0x65,0x64},{0x5e,0xda},{0x66,0xaa}\

    ,{0x1f,0x02},{0x32,0x01},{0x33,0x03},{0x21,0x00},{0x20,0x00},{0x21,0x01}

    The register values for reading 90UB960 are as follows:

    Thanks and regards,

    Cherry

  • Hi Cherry,

    Here is what I noticed from the Port 3 register dump:

    • Register 0x4D bit[4] LOCK_STS_CHG is flagged, meaning that LOCK for Port 3 had dropped since the last register read.  
      • Can you confirm that LOCK is stable for each port? You can do this by selecting the port in Reg 0x4C and reading Reg 0x4D multiple times with a delay between reads. PASS and LOCK should remain high while LOCK_STS_CHG stays low. 
    • Register 0x4E is reporting a line count change and a buffer overflow error. 
      • A buffer overflow error means that the sum of the input bandwidths to be forwarded is exceeding the output bandwidth (see Section 7.4.20 in the 960 datasheet). This may result in lost video data. Can you please provide the following imager parameters so that I can help you check whether you are able to aggregate the 4 video inputs? 
        • Horizontal active pixels
        • Vertical total lines
        • Frame rate
        • Bits per pixel 
        • Clock type (continuous or non-continuous)
        • CSI-2 lane speed
        • Number of CSI-2 lanes
        • Forwarding mode - looks like you are using best effort round robin, correct? 
    • When programming CSI-2 forwarding, make sure that you program Reg 0x21 before enabling forwarding in Reg 0x20.

    Regards,

    Cindy

  • Hi Cindy,

    • Horizontal active pixels    :1600
    • Vertical total lines             :1315
    • Frame rate                        :30fps
    • Bits per pixel                     :YUV422 8bit UYVY
    • Clock type (continuous or non-continuous)   :continuous 
    • CSI-2 lane speed               :800 Mbps
    • Number of CSI-2 lanes     :2-lane
    • Forwarding mode - looks like you are using best effort round robin, correct?

    --The customer tried something else Synchronized CSI-2 Forwarding, no waveforms can be measured from the MIPI interface, only Best-effort can measure data waveforms at the MIPI interface and get a normal image with a single 90UB953 access. 

    Register 0x4D bit[4] LOCK_STS_CHG is flagged, meaning that LOCK for Port 3 had dropped since the last register read.

    Lock_STS_CHG is flagged may because of the first read and no lock_STS_CHG is found to be flagged in subsequent read.

    Here are all register values read from 90UB953:

    Thanks and regards,

    Cherry

  • Hi Cherry,

    Thank you for confirming the LOCK status. Just to confirm, when they read 0x4E multiple times, is the value still 0x55 and showing a buffer error? 

    It looks like the input bandwidth coming from the 4 serializers is exceeding the output bandwidth of the transmitter. The input bandwidth sum is approximately 4.04Gbps (H*V*frame rate*(bits/pixel)*blanking*4 cameras).

    Can they try increasing the 960 CSI-2 output bandwidth? They can refer to Section 7.4.20 in the 960 datasheet for the calculations since the output bandwidth depends on several factors. 

    There is also a training video that goes over CSI-2 aggregation. 

    Regards,

    Cindy

  • Hi Cindy,

    Just to confirm, when they read 0x4E multiple times, is the value still 0x55 and showing a buffer error? 

    Set the 0x4C register to 0x01, 0x12, 0x24, 0x38 respectively, and 0x55 appears only on the first read of 0x4E, followed by 0x04. However, when the 0x4C register is set to 0x38, reading 0x4E occasionally results in 0x14.

    That is, 0x55 appears only on the first read of 0x4E, and it does not occur afterwards.

    Thanks and regards,

    Cherry 

  • Hi Cherry,

    If 0x4E is occasionally reading 0x14, that means the BUFFER_ERROR bit is getting flagged. I still suspect that it is a video buffer error given the sensor and transmitter configuration. Can the customer try increasing the CSI-2 output bandwidth so that the output bandwidth is greater than the input bandwidth of all four sensors going into the 960?

    Regards,

    Cindy

  • Hi Cindy,

    The customer sets the 0x1f register to 0x00, and with a 25MHz crystal oscillator, the CSI_TX speed should be 1.6 Gbps. 

    In this calculation, the bandwidth should be 4.36Gbps.

    Set the 0x4C register to 0x01, 0x12, 0x24, and 0x38 respectively. Only when 0x4E is read for the first time, it is 0x45, and the subsequent ones are all 0x04. BUFFER_ERROR has not been set. 

    The captured image is still the result of overlapping images from the four cameras. Currently, the Forwarding mode is configured with effort round robin.

    Should Forwarding mode be configured as synchronous forwarding mode?

    Basic Synchronized forwarding

    Line-Interleave forwarding

    Line-Concatenated forwarding

    When trying to configure the Forwarding mode to any of the three optional sync modes, there is no data on the CSI-TXD pin. Shall we continue looking for issues in sync mode?

    Regards,

    Annie

  • Hi Annie,

    If all subsequent reads of 0x45 are 0x04, that indicates normal operation.

    Can you check that the VCIDs are programmed correctly in 960 register 0x72? It should be programmed to what the SoC is expecting.

    In order to use synchronized forwarding, the video arriving at input ports should be synchronized within approximately 1 video line period. Are you using any frame sync to synchronize the incoming video data? All imagers also need the same video parameters for synchronized forwarding.  

    Are you following the datasheet examples to configure synchronized forwarding? If you check 960 register 0x35, you should see TX_PORT_PASS and TX_PORT_SYNC flagged for proper operation.

    Regards,

    Cindy

  • Hi Cindy,

    The value of 960 register 0x72 is 0xE4.

    Currently, the cameras used all have the same parameters. When the 0x21 register is configured as 0x08 (Line-Interleave forwarding), reading the 0x35 register multiple times will change between 0x01 and 0x00.

    No frame sync operation was taken.

    Regards,

    Annie

  • Hi Annie,

    Register 0x72=0xE4 is the default value, but you can change the VD-ID mapping depending on your system. The SoC will use the VD-ID mappings to differentiate between different streams of data and aggregate the data from multiple imagers. Can you confirm that this is the correct VC-ID mapping for your system? 

    Are you getting a consistent TX_PORT_PASS in register 0x35 in round robin mode? And is the issue just with the overlapping images (so no flickering screen or dropping video frames)?

    Can you enable patgen on the 960 to see if you can see that data successfully? You can use the ALP pattern generator tab to generate the appropriate register values depending on what video parameters you want.

    As for the synchronized forwarding issue, if there is no frame synchronization, you may not be meeting the requirement that all inputs are synchronized within 1 video line period. Can you see whether the inputs are lined up within one video line period? If not, frame sync may be necessary in order to use synchronized forwarding. 

    Regards,

    Cindy