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.

Linux/DS90UB954-Q1: DS90UB95{4,3}-Q1

Part Number: DS90UB954-Q1

Tool/software: Linux

Hi,

I am currently bringing up a design using a DS90UB954/3 with a IMX219 camera sensor. I am able to see the camera at the serializer end via the i2c bus. I am also able to read and write registers on both the serializer and deserializer. 

The software driver I am using detects the camera, but I have been able to get any sensor data to start between the two endpoints.  I have tried the BIST (as suggested in the training videos training.ti.com/ds90ub953954-system-design-operation it appears the serializer and deserializer are OK.  When the camera is directly connected to the processor (without the DS90UB954/3) the camera is detected and the sensor data comes through (so the software driver works with the sensor).

There are a lot of settings for these chips, however, so I'd like to get some help on reviewing my current configuration. I realize there are many different parameters and it depends entirely on the hardware design, but I'm hoping someone could confirm that these settings are at least consistent. Am I missing a setting on the Serializer based on my Deserializer settings (or vice versa)?

Thanks for your help.

Deserializer (DS90UB954) settings

             ("FPD3_PORT_SEL", 0x4C, 0b00000011, "Enable writes on Port 1&0"),\
      ("I2C_CONTROL_1", 0x08, 0b10011100, "Enable LOCAL_WRITE_DISABLE") ,\
      ("RX_PORT_CTL"  , 0x0C, 0b10000001, "Disable PORT1_EN") ,\
      ("IO_CTL"       , 0x0D, 0b10111001, "3.3V I/O Supply, 3.3V Supply Mode"),\
      ("CSI_CTL"      , 0x33, 0b00100001, "CSI_LANE_COUNT=2, CSI_ENABLE"),\
      ("FPD3_ENC_CTL" , 0xBA, 0b00000011, "Enable FPD-Link III CRC"),\
      ("FPD3_CAP"     , 0x4A, 0b00010000,  "Enable CRC Error Flag"),\
      ("BCC_CONFIG"   , 0x58, 0b10011110, "Enable i2c passthrough"),\
      ("DATAPATH_CTL1", 0x59, 0b10000011, "Disable datapath regs, 4 GPIOs"),\
      ("PORT_CONFIG"  , 0x6D, 0b10111100, "see notes"),\
      ("BC_GPIO_CTL0" , 0x6E, 0b00010000,  "Enable GPIO"),\
      ("BC_GPIO_CTL1" , 0x6F, 0b00110010,  "Enable GPIO"),\

Serializer (DS90UB953) settings:
      ("BCC_CONFIG"   , 0x32, 0b10001001, "i2c passthrough"),\
      ("General_CFG"  , 0x02, 0b00010010,  "2 channel config"),\
      ("GPIO_INPT_CTL", 0x0E, 0b11111111, "Enable all GPIO outputs"),\

  • Hi Bob,

    Register 0x0E should not be 0xFF, it should be 0xF0 to enable all GPIOs as outputs. From a quick glance your other settings seems like they should be okay.

    Have you tried using pattern generation on the 954 to evaluate the link between the 954 & the processor? Details on this can be found in section 7.5.11 of the 954 datasheet.

    Could you provide more detail on how you are initializing the sensor? Are you using the GPIOs on the 953?

    If you want the GPIOs on the 953 to act as outputs (inputs to the image sensor) and control the 953 GPIOs via the 954 GPIO0 & GPIO1 here are the recommended settings:

    954:

    0x6E = 0b00010000 and 0x6F = 0b00110010 as you configured them

    0x59 as you have configured it sets up the 954 GPIOs to be controlled by the 953 GPIOs. If you are trying to use the 954 GPIOs as inputs, 0x59 should be equal to 0x00.

    0x0F[1:0] = 11 to enable GPIO0 & GPIO1 as inputs (this is true by default)

    953:

    Register 0x0E = 0xF0 953 GPIOs configured as outputs. Note that the 953 GPIOs should not be configured as outputs & inputs simultaneously.

    Register 0x0D = 0xF0 Remote enable 953 GPIOs (true by default)

    Please read the following registers:

    953: 0x61 (packet header data), 0x62 (packet header word count 0), 0x63 (packet header word count 1) 

    954: 0x73 (line count high), 0x74 (line count low), 0x75 (line length 1), 0x76 (line length 2), 0x5D (sensor ID), 0x65 (sensor alias)

    Regards,

    Zoe

  • Zoe,

    Thank you for the reply. We fixed the GPIO issue, but it did not resolve our problem.

    We scoped the i2c bus and discovered that the software driver was sending an i2c read to address 0x00 (General Call). When this read is sent, the deserializer i2c clock line (SCL) is driven low for over 250 ms. We do not know why this is occurring.  This long drop of the clock line is causing the software driver to malfunction. We do not have source for our driver, unfortunately, so I can't just comment out this 0x0 read.

    It appears that the deserializer is trying to do some kind of clock stretching(?), but it goes for too long.

    We can replicate this issue by sending a read command via python:

    $ python

    > import smbus

    > bus = smbus.SMBus(0)

    > bus.read_byte_data(0x0, 0x0)

    When we run this command the clock line on the deserializer drops as previously described and this may be an easy way of observing what we are seeing.

    We verified that all of the alias registers are disabled. We also confirmed that we can see other i2c read and writes (to addresses other than 0x00) successfully go across the connection between the serializer and the deserializer.

    Can you think of any reason why the 0x00 address is causing problems for the deserializer?


    Thank you for your help.

     

     

     

     

  • Hi Bob,

    I'm not sure of the exact reason for this, but in general the deserializer uses clock stretching when communicating with the 953 via I2C.

    The 250 ms you are seeing sounds like it corresponds to the BCC Watchdog Timer (the default value 0x7F is 254 ms). You may be able to resolve your issue by decreasing the watchdog timer, which can be do via the 954 register 0x07.

    Regards,
    Zoe