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.

DS90UB953-Q1: DS90UB914-Q1 and DS90UB953-Q1 I2C clock stretching behavior

Part Number: DS90UB953-Q1
Other Parts Discussed in Thread: , DS90UB914A-Q1, DS90UB913Q-Q1

I'm attempting to see if I can use the DS90UB953-Q1 serializer with the DS90UB914-Q1 deserializer, as described in SNLA270 (which refers to the DS90UB914A-Q1).  I'm bench prototyping this using the DS90UB953-Q1EVM, connecting via twisted pair to the DS90UB914-Q1 on our existing hardware.  I get a good LOCK output from the DS90UB914-Q1, suggesting that the FPD-Link III channel is working, and the I2C address of the DS90UB953-Q1 shows up in the SER ID register (0x06) of the DS90UB914-Q1.  I copy the 953's I2C address from the SER ID register to the SER Alias register (0x07), but then when I try to access the '953, the '953 apparently initiates a really long clock stretch, eventually forcing the I2C master behind the '914 to give up:

Is this a compatibility difference between the DS90UB914-Q1 and the DS90UB914A-Q1 that will prevent the "non-A" version from working with the DS90UB953-Q1?

  • Hey Brian,

    Can you send your programming steps over?

    Best Regards,

    Casey 

  • Here's an example U-boot sequence:

    U-Boot >
    U-Boot > i2c dev 1
    Setting bus to 1
    U-Boot > i2c md 0x60 0x00 0x100
    0000: c0 04 00 e9 00 00 30 00 00 00 00 00 00 00 00 00 ......0.........   <--- Note SER ID address already set to 0x30
    0010: 00 00 00 00 00 00 00 00 00 01 00 00 13 33 33 08 .............33.
    0020: fe 17 00 00 08 00 00 00 00 20 00 00 00 08 00 00 ......... ......
    0030: 00 00 00 25 fa 00 00 00 00 00 18 60 00 00 00 10 ...%.......`....
    0040: 82 82 00 35 00 00 00 00 00 08 00 00 00 20 00 00 ...5......... ..
    0050: fe fe fc 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    U-Boot > i2c mw 0x60 0x07 0x30     <--- Set SER Alias register to 0x30
    U-Boot > i2c md 0x60 0x00 0x10
    0000: c0 04 00 e9 00 00 30 30 00 00 00 00 00 00 00 00 ......00........
    U-Boot > i2c probe
    Valid chip addresses:wait_for_sr_state: failed sr=20 cr=b8 state=202
    wait_for_sr_state: failed sr=20 cr=88 state=2000
    i2c_imx_stop:trigger stop failed
    i2c_init_transfer: failed for chip 0x18 retry=0
    force_idle_bus: sda=1 scl=0 sda.gp=0x6d scl.gp=0x6c
    force_idle_bus: failed to clear bus, sda=1 scl=0
    i2c_init_transfer: give up i2c_regs=021a4000
    wait_for_sr_state: Arbitration lost sr=93 cr=80 state=2020
    i2c_init_transfer: failed for chip 0x19 retry=0
    force_idle_bus: sda=1 scl=0 sda.gp=0x6d scl.gp=0x6c
    wait_for_sr_state: failed sr=84 cr=a0 state=2020
    i2c_init_transfer: failed for chip 0x19 retry=1
    60     <--- DS90UB914Q deserializer shows up on bus probe, but DS90UB953 generates errors above
    U-Boot >

     

  • Hello Brian,

    The SERID and SERAlias should not be the same value. Please try setting the SERalias to another value, say 0x18 and try accessing the serializer from address 0x18

    Best Regards,

    Casey 

  • U-boot sequence:

    U-Boot > i2c mw 0x60 0x07 0x18
    U-Boot > i2c md 0x60 0x00 0x10
    0000: c0 04 00 e9 00 00 30 18 00 00 00 00 00 00 00 00 ......0.........
    U-Boot > i2c probe
    Valid chip addresses:wait_for_sr_state: failed sr=20 cr=b8 state=202
    wait_for_sr_state: failed sr=20 cr=88 state=2000
    i2c_imx_stop:trigger stop failed
    i2c_init_transfer: failed for chip 0xc retry=0
    force_idle_bus: sda=1 scl=0 sda.gp=0x6d scl.gp=0x6c
    force_idle_bus: failed to clear bus, sda=1 scl=0
    i2c_init_transfer: give up i2c_regs=021a4000
    wait_for_sr_state: Arbitration lost sr=93 cr=80 state=2020
    i2c_init_transfer: failed for chip 0xd retry=0
    force_idle_bus: sda=1 scl=0 sda.gp=0x6d scl.gp=0x6c
    wait_for_sr_state: failed sr=84 cr=a0 state=2020
    i2c_init_transfer: failed for chip 0xd retry=1
    60
    U-Boot >

    The only difference is that the bus probe now fails at the new address (0x0C if 0x18 is entered in the serial alias register, because the address is shifted one bit left).

  • Incidentally, if the DS90UB913Q-Q1 is the serializer, it works just fine to set SER Id and SER Alias to the same value.

  • Hi Brian,

    I'd like to verify a few things:

    - Could you probe the back channel of the 914?

    - Are you using PoC? What does your PoC network look like?

    Best,

    Jiashow

  • What exactly do you mean by probe the backchannel? I am seeing the serializer I2C address appear automatically in register 0x06 of the 914, so I assume the backchannel is working to some extent.  Let me know if there's something specific I need to try.

    I'm not using POC. We are using STP, and I have modified the DS90UB953-Q1EVM (with difficulty!) to use an STP connection. Again, I'm seeing the serializer I2C address appear, and I get a good LOCK signal out of the 914, so I think the physical connection is good.

  • Hi Brian,

    I meant checking the back channel by directly connecting the output of the 914 to the scope to verify that the back channel signal is okay.