• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 32 subscribers
  • Views 230 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

DS90UB960-Q1: CSI output BW calculation

DS90UB960-Q1: Stream stops inconsistently during long stream

Dharanitharan Mani
Prodigy 90 points
Part Number: DS90UB960-Q1
Other Parts Discussed in Thread: TDA4VM

Hi,
We works on integrating AR0234 sensor interfacing FPD LINK3 with Ti's TDA4VM starter kit.

The deserializer has four RX port and two CSI-2 TX Port. The linux driver for UB960 support one CSI-2 TX port for four RX port. So four camera which is connected with each RX port is routed to one TX port.

MIPI clock speed of each camera is 300 MHz and the TX port of CSI-2  deserialiser is 1.6 GHz. By calculating four camera speed it is 1.2 GHz nearly still less than 1.6 GHz speed of TX port.

When we starts stream with 4 cameras initially, it streams properly without issue, But after sometimes it stops due to some issues. when we check the dmesg messages, it shows "ds90ub960 6-0030: rx<port> buffer error".

Is there any way to get rid of this issue which help to stream cameras for log time?

Note: This issue occurs inconsistently, Sometimes the stream runs more than two days, sometimes its just 20 mins or less than that. While checked with DSO we can see frame data from camera and outside of Deserializer.

  • 0
    TI__Guru* 88310 points

    Hello Dharani,

    For which RX Port do you see this buffer error? Is it on all 4 or just a single one?

    Does swapping cameras or using different cables have any impact?

    Which clocking mode are you using, Sync or non-Sync?

    What is the value of CLK source on SER and on DES?

    Can you provide the exact V & H resolutions, frame rate and data type for each camera?

    What is the used Port forwarding type on the DES?

    Is your DES TX CSI-2 rate setup to 1.6Gbps/lane?

  • 0 in reply to Hamzeh Jaradat
    Prodigy 90 points

    Hi,

    Hamzeh Jaradat said:

    For which RX Port do you see this buffer error? Is it on all 4 or just a single one?

    Does swapping cameras or using different cables have any impact?

    Yes, the buffer error occurs in all the four ports randomly. Swapping cameras and cables does not have any effect on the buffer error.

    Hamzeh Jaradat said:

    Which clocking mode are you using, Sync or non-Sync?

    What is the value of CLK source on SER and on DES?

    The Synchronous clocking mode is being used. and the value of CLK  source is 25 MHz.

    Hamzeh Jaradat said:
    Can you provide the exact V & H resolutions, frame rate and data type for each camera?

    Width - 1280 , height - 720, frame rate - 30 Fps, Data type - UYVY16.

    Hamzeh Jaradat said:
    What is the used Port forwarding type on the DES?

    Round robbing forwarding type is used.

    Hamzeh Jaradat said:
    Is your DES TX CSI-2 rate setup to 1.6Gbps/lane?

    Yes, Deserializer TX CSI-2 data rate is setup to 1.6Gbps/lane.

    And we are using deserialiser driver "ds90ub960.c" which is provided in ti-linux-kernel.git itself

  • 0 in reply to Dharanitharan Mani
    TI__Guru* 88310 points

    Hi,

    your used datarate is fine.

    Can you provide register dumps from SER and DES for a good case and a bad case?

  • 0 in reply to Hamzeh Jaradat
    Prodigy 90 points

    Hi,
    All registers looks same on both cases except the status register. In that status register, Buffer bit is being set while the error occurs.
    While checking further we can stream 1920 X 1080 at 30FPS without buffer error. For both resolution at 30 FPS, we have made no changes on both SER and DES setting.

  • 0 in reply to Dharanitharan Mani
    TI__Guru* 88310 points

    Hello,

    have you done any other changes than the H and V resolutions? for example data type or multiple vs single exposure or data types?

    You can make sure the received data is stable by outputting the Frame valid signal to a GPIO and the Line-valid signal to another GPIO and measure those.

    For example, you can set the registers using the following settings for measuring the Frame valid on GPIO0 and Line valid on GPIO1.
     
    Reg0x10 = 0xC1
    Reg0x11 = 0xE1

  • 0 in reply to Hamzeh Jaradat
    Prodigy 90 points

    Hi,
    After checking all four camera's Frame valid and line valid details by probing GPIO's.There is no change between proper stream and buffer error stream, both conditions streams 30FPS and the frame and line valid signals looks similar.  We reduced the FPS to 25 even we got buffer error.

  • 0 in reply to Dharanitharan Mani
    TI__Guru* 88310 points

    Hi,

    This is strange behavior which I have never seen before!!

    Is this a single DES issue or all DES are showing the same behavior?

    What is the number of CSI-2 lanes at DES TX are you using?

  • 0 in reply to Hamzeh Jaradat
    Prodigy 90 points

    Hi,
    This behaviour happens in all the deserialiser which we are using. The deserialiser has Two CSI-2 TX with four lanes each.

  • 0 in reply to Dharanitharan Mani
    TI__Guru* 88310 points

    Hi,

    I recommend you measure the following signals:

    1) Power supply voltage level, i.e. VDD11, VDD18 and VDD33 pins and make sure these are within the datasheet specs (+/- 5%).

    2)  Noise on all power supply pins, i.e. VDD11, VDD18 and VDD33 pins, and make sure noise is within max allowed levels, from DC to 50MHz.

    3) Measure the power-up sequency and make sure this fulfills the sequence and timings as per datasheet section "8.4 Power Supply Recommendations".

    4) Measure your REFCLK frequency and make sure it is within our specs as per Table 7-3

    5) Measure the FPD input Jitter and make sure it is within our tolerance as per section "7.4.6 Input Jitter Tolerance"

    6) Provide your up-to-date schematic for review.

    PS: Please use the latest datasheet on TI.com.