• State TI Thinks Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 5 answers
  • Subscribers 33 subscribers
  • Views 753 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: Serdes Video Lock Status

Elango Palanisamy
Prodigy 30 points
Part Number: DS90UB960-Q1
Other Parts Discussed in Thread: DS90UB953-Q1

Tool/software:

Hi Team,

We're currently developing a product using DS90UB960-Q1 and DS90UB953-Q1. Our main concern is ensuring that the video frames are reliably received by the deserializer link. Despite experimenting with several debug registers, none have proven to be effective. Could you recommend specific debug registers or mechanisms to ensure smooth video reception at the deserilaizer end?

Thanks,

Elango

  • 0
    Prodigy 30 points

    Adding on,

    Our system has 4 DS90UB953-Q1 serilaizer connected to a single DS90UB960-Q1 deserilaizer. And any device could fail at anytime. We need a debug mechanism to ensure that proper video frame is received from the specific device. For example, to check the physical connection is active between deserilaizer and a specific serializer, we are using the debug register RX_PORT_STS1(0x4D). We need a similar mechanism/register to ensure video is received from the specific port/device. We have tried a few such as SENSOR_STS_0(0x51) but it is set to 0x00 always. Can you help us on this?

  • 0 in reply to Elango Palanisamy
    TI__Guru** 107910 points

    Hello Elango,

    You may check the registers 0x4D, 0x4E, 0x55, 0x56, 0x73 - 0x76, 0x7A-0x7C.
    Also, you may need to configure the Port PASS register (0x7D) and use it to make sure you are receiving valid video data.

  • 0 in reply to Hamzeh Jaradat
    Prodigy 30 points

    Hi Hamzeh Jaradat,

    Thanks for your reply. But those registers does not seem to help us. We read the registers between two cameras. One was streaming and other one was not. But the registers returned the same value for both the camera devices. I have attached the register values in multiple scenario for your reference.

    stream launch
[  361.678789] 0x4E:cd
[  361.786849] 0x55:0
[  361.894803] 0x56:0
[  362.002798] 0x73:2
[  362.110836] 0x74:d0
[  362.218831] 0x75:a
[  362.326811] 0x76:0
[  362.434793] 0x7A:e
[  362.542811] 0x7B:ff
[  362.650834] 0x7C:21



stream close
[  577.038810] 0x4E:4
[  577.146825] 0x55:0
[  577.254788] 0x56:0
[  577.362794] 0x73:2
[  577.470793] 0x74:d0
[  577.578824] 0x75:a
[  577.686786] 0x76:0
[  577.794792] 0x7A:0
[  577.902802] 0x7B:0
[  578.010793] 0x7C:21



streaming camera: 1st read
[80862.975842] 0x4E:4d
[80863.083837] 0x55:0
[80863.191851] 0x56:0
[80863.299842] 0x73:4
[80863.407837] 0x74:b0
[80863.515835] 0x75:f
[80863.623835] 0x76:0
[80863.731866] 0x7A:e
[80863.839850] 0x7B:ff
[80863.947845] 0x7C:21

streaming camera: 2nd read
[80878.983837] 0x4E:4
[80879.091833] 0x55:0
[80879.199837] 0x56:0
[80879.307868] 0x73:4
[80879.415869] 0x74:b0
[80879.523856] 0x75:f
[80879.631835] 0x76:0
[80879.739853] 0x7A:0
[80879.847837] 0x7B:0
[80879.955840] 0x7C:21

non-streaming camera: 1st read
[80894.759865] 0x4E:4d
[80894.867904] 0x55:0
[80894.975890] 0x56:0
[80895.083854] 0x73:4
[80895.191897] 0x74:b0
[80895.299905] 0x75:f
[80895.407884] 0x76:0
[80895.515850] 0x7A:e
[80895.623836] 0x7B:ff
[80895.731909] 0x7C:21

non-streaming camera: 2nd read
[80900.719847] 0x4E:4
[80900.827873] 0x55:0
[80900.935850] 0x56:0
[80901.043895] 0x73:4
[80901.151896] 0x74:b0
[80901.259843] 0x75:f
[80901.367860] 0x76:0
[80901.475880] 0x7A:0
[80901.583839] 0x7B:0
[80901.691872] 0x7C:21

    To explain in a better way, to check if a specific serializer is connected or not, we write the port number to FPD3_PORT_SEL(0x4C) and read back the PORT_PASS of register RX_PORT_STS1(0x4D). This help us to ensure if the serializer device is connected or not.

    Similarly we are looking for register that would help us to ensure proper streaming is received on the deserializer end from a specific serializer.

  • 0 in reply to Elango Palanisamy
    TI__Guru** 107910 points

    Hi Elango,

    Elango Palanisamy said:
    Thanks for your reply. But those registers does not seem to help us. We read the registers between two cameras. One was streaming and other one was not. But the registers returned the same value for both the camera devices. I have attached the register values in multiple scenario for your reference.

    No, this is not possible. Make sure before reading the registers for each port to select the right port in registers 0x4C. You would need to write 0x4C = 0x01 for reading RX Port0 registers and write 0x4C = 0x12 for reading RX Port1 registers. For the port where no camera is connected/streaming registers 0x73-0x76 must be 0x00.

    Elango Palanisamy said:
    To explain in a better way, to check if a specific serializer is connected or not, we write the port number to FPD3_PORT_SEL(0x4C) and read back the PORT_PASS of register RX_PORT_STS1(0x4D). This help us to ensure if the serializer device is connected or not.

    Correct.

    Elango Palanisamy said:
    Similarly we are looking for register that would help us to ensure proper streaming is received on the deserializer end from a specific serializer.

    Here you need to configure the PASS function in register 0x7D to 0x01 or 0x02, and then monitor 0x4D[1].

    Also, you can monitor registers 0x73-0x76 to see if you are receiving the correct resolutions.

    Note that all these registers are RX port specific, hence you would need to write 0x4C = 0x01 for reading RX Port0 status registers and write 0x4C = 0x12 for reading RX Port1 status registers, 0x4C = 0x24 for reading RX Port2 status registers, and 0x4C = 0x38 for reading RX Port3 status registers

  • 0 in reply to Hamzeh Jaradat
    Prodigy 30 points

    Hi Hamzeh,

    Hamzeh Jaradat said:
    Note that all these registers are RX port specific, hence you would need to write 0x4C = 0x01 for reading RX Port0 status registers and write 0x4C = 0x12 for reading RX Port1 status registers, 0x4C = 0x24 for reading RX Port2 status registers, and 0x4C = 0x38 for reading RX Port3 status registers

    Yes you are right. We are configuring 0x4C with right values ie 0x4C=0x01 for RX0, 0x4C=0x12 for RX1, 0x4C=0x24 for RX2, 0x4C=0x38 for RX3. And we have set the PASS_THRESHOLD=2 in 0x7D ie 0x7D=0x02. We are ensuring this by reading back the values.

    Let me explain about our setup. We have 4xDS90UB953-Q1 serializer connected to a DS90UB960-Q1 deserializer. And I need to ensure if valid frames are received from Port RX2 on the deserializer. To ensure that, I configure 0x4C=0x24 and 0x7D=0x02 as you mentioned.

    1. During normal streaming, when I read the debug registers or error counter registers everything looks fine. And if I manually corrupt the frames, the error registers are getting updated. But when the camera comes back to normal streaming state, the error counter register values remain the same. They don't set back to 0 or default values.
    2. Also when i remove the camera device from the link, the deserializer register still does not updated. It stays with previous values.
    3. Is there anyway to clear the registers or get the updated value?
  • 0 in reply to Elango Palanisamy
    TI__Guru** 107910 points

    Hello Elango,

    In order to clear the error counters of flag registers, you need to read those registers since they are "Clear on Read". However, there are some flag registers that can only be cleared by reading other registers, for example:

    To clear 0x4D[2] you need to read reg 0x55 and 0x56

    To clear 0x4D[3] you need to read reg 0x47

    .... etc

    Hence, you may need to go through the register map in the data sheet and see which registers you are monitoring and reading and how these can be cleared.

  • 0 in reply to Hamzeh Jaradat
    Prodigy 30 points

    Hi Hamzeh,

    Hamzeh Jaradat said:

    In order to clear the error counters of flag registers, you need to read those registers since they are "Clear on Read". However, there are some flag registers that can only be cleared by reading other registers, for example:

    To clear 0x4D[2] you need to read reg 0x55 and 0x56

    To clear 0x4D[3] you need to read reg 0x47

    We followed as you said and tested the working. We tested the below mentioned 5 scenarios and attached the register values

    1. The camera is streaming properly
    2. The camera is providing corrupted streaming
    3. Streaming is switched off in the forward channel
    4. Camera sensor along with serilaizer is removed
    5. Only serilaizer is connected and camera sensor is not connected.

    Note: Our serializer is connected to RX PORT I

    Normal streaming
0x4c: 0x12
0x7D: 0x02
0x02: 0x1c
0x4D: 0x43
0x47: 0x00
0x4E: 0x04
0x51: 0x00
0x54: 0x03
0x55: 0x00
0x56: 0x00
0x5B: 0x30
0x73: 0x02
0x74: 0xd6
0x75: 0x0f
0x76: 0x00
0x7a: 0x00
0x7b: 0x00
0x7c: 0x21

Corrupted Streaming
0x4c: 0x12
0x7D: 0x02
0x02: 0x1c
0x4D: 0x43
0x47: 0x00
0x4E: 0xc5
0x51: 0x00
0x54: 0x03
0x55: 0x00
0x56: 0x00
0x5B: 0x30
0x73: 0x02
0x74: 0x37
0x75: 0x0f
0x76: 0x00
0x7a: 0x00
0x7b: 0x00
0x7c: 0x21

Streaming switched off in forward channel
0x4c: 0x12
0x7D: 0x02
0x02: 0x1c
0x4D: 0x43
0x47: 0x00
0x4E: 0x45
0x51: 0x00
0x54: 0x03
0x55: 0x00
0x56: 0x00
0x5B: 0x30
0x73: 0x02
0x74: 0x37
0x75: 0x0f
0x76: 0x00
0x7a: 0x00
0x7b: 0x00
0x7c: 0x21

Serializer and modboard removed
0x4c: 0x12
0x7D: 0x02
0x02: 0x1c
0x4D: 0x50
0x47: 0x00
0x4E: 0x02
0x51: 0x00
0x54: 0x03
0x55: 0x00
0x56: 0x00
0x5B: 0x30
0x73: 0x02
0x74: 0x37
0x75: 0x0f
0x76: 0x00
0x7a: 0x00
0x7b: 0x00
0x7c: 0x21

Sensor removed
0x4c: 0x12
0x7D: 0x02
0x02: 0x1c
0x4D: 0x41
0x47: 0x00
0x4E: 0x04
0x51: 0x00
0x54: 0x00
0x55: 0x00
0x56: 0x00
0x5B: 0x30
0x73: 0x02
0x74: 0x37
0x75: 0x0f
0x76: 0x00
0x7a: 0x00
0x7b: 0x00
0x7c: 0x21

    The registers 0x73 and 0x74 gives the current streaming resolution. Once the data gets corrupted, the register value changes to some random value. But when the streaming recovers, the registers still holds the corrupted streaming value ie. the register doesn't get updated with current valid data. We also tried disabling the  RX_PARITY_CHECKER_EN in GENERAL_CFG register as mentioned in the data sheet but that too didn't help.

    Is there any PLL_LOCK registers on UB960 Deserializer which helps in ensuring valid video data is being received on the deserializer end?

  • 0 in reply to Elango Palanisamy
    TI__Guru** 107910 points

    Hello Elango,

    I will review the provided data and get back to you within 1-2 business days.

  • 0 in reply to Hamzeh Jaradat
    TI__Guru** 107910 points

    Hi Elango,

    Yes, I see what you do mean.

    Elango Palanisamy said:
    Is there any PLL_LOCK registers on UB960 Deserializer which helps in ensuring valid video data is being received on the deserializer end?

    You may need to configure and monitor the PASS register. To do so:

    1) Write 0x4C = 0x12 # for RX port 1
    2) Configure 0x7D[1:0] = 2 # setup a pass threshold for received valid 2 frames. If you want you can enable other criteria for configuring PASS, such as line size, line count, parity error ... etc in reg 0x7D
    3) Monitor 0x4D[1]

  • 0 in reply to Hamzeh Jaradat
    Prodigy 30 points

    Hi Hamzeh,

    Thanks for your input.

    May we know the reason why the registers LINE_COUNT_HI and LINE_COUNT_LO are not getting updated?

  • 0 in reply to Elango Palanisamy
    TI__Guru** 107910 points

    Hi Elango,

    The Line Count registers report the line count for the most recent video frame.  When interrupts are enabled for the Line Count (via the IE_LINE_CNT_CHG register bit), the Line Count value will be frozen until read.

    So, you may need to read those registers to clear the frozen value and get the updated values.

  • 0 in reply to Hamzeh Jaradat
    Prodigy 30 points

    Hi Hamzeh,

    We are following the steps mentioned by you but we are not able to get the expected results. We have connected a UB953 based camera to RX_PORT_0 of UB960 Deserializer and configured the registers as mentioned below.

    0x4C= 0x01,

    0x7D= 0x02,

    0xD9= 0x20,

    0x02 = 0x1C,

    Our camera is streaming 1920x1200px resolution and the LINE_COUNT registers 0x73, 0x74 returns the value 0x04 and 0xb0 ie 0x04b0 = 1200px. Also when we unplug the camera module and read the LINE_COUNT registers 0x73, 0x74 values again, it still returns 0x04, b0.

    Can you please perform the below test and share us the inference. We would like verify if the same happens there also.

    1. Connect a UB953 Serializer based camera setup with a UB960 Deserializer and configure 0x4C, 0x7D, 0xD9 and 0x02 accordingly.
    2. Stream the camera and read the LINE_COUNT registers 0x73, 0x74
    3. Unplug the camera module and again read the LINE_COUNT registers 0x73, 0x74

  • 0 in reply to Elango Palanisamy
    TI__Guru** 107910 points

    Hello Elango,

    As I said, these are freeze until read. So, if you unplug the camera, if you read first time you will get the old values, hence you need to read twice once you unplug the camera.