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.

DS90UB914A-Q1: Back channel I2C data array

Part Number: DS90UB914A-Q1

Hi team,

Our customers seem to have an error when accessing remote I2C slaves from 914A to 913A side.

Analysis will be done in the future, but consecutive 2 bits of I2C seems to be wrong.

I assume that the cause is a data transfer error due to disturbance noise, but is the data array of back channel I2C data a continuous data?

Because it is assumed that instantaneous so-called single-shot noise is occurring, I think whether there is a possibility that two consecutive bits will be incorrect.

Could you tell me the back channel data array?

Best regards,

Tomoaki Yoshida

  • Yoshida-san,
    Is local I2C working fine on the 914A side? I am not sure if I follow the question about "back channel data array".
    They should confirm they are using proper SDA/SCL pull-up and filtering, and IDx address/I2C configuration registers are set properly.

    You can also refer to this TI app note SNLA222 on 913/914 I2C.
    www.ti.com/.../snla222.pdf
  • Hi Palaniappan-san

    Thank you for your support.

    Sorry, they don't know if local I2C is normal then.
    After that, it was clearly that local I2C was normal operation.
    It seems that it can not take the log because it occurs randomly after being incorporated in the case.

    In the case where the data sequence when sending I2C by the back channel is a continuous bit, even if a single noise occurs, there is a possibility that both neighboring two bits are error.
    They want to know the wheter I2C bit array are random or continuous as a material for estimating phenomenon.

    Best regards,
    Tomoaki Yoshida
  • Hi Palaniappan-san,

    Thank you for your support.
    Can you only tell me the next point?
    For example, is there a possibility that bit1 and bit2 of I2C data are continuous with data on back channel?

    Best regards,
    Tomoaki Yoshida
  • Since the real question here is remote I2C issues from the deserializer they should focus on the following:

    - Confirm proper SDA/SCL pull-up and filtering are being used
    - Confirm IDx address/I2C configuration registers are set properly
    - Measure the power pins and PDB to ensure device is powered up
    - LOCK should be high when I2C is initiated
    - Capture the failed I2C transaction (for remote I2C issue, capture both remote and local buses along with deserializer LOCK status)
  • Hi Palaniappan-san,

    Thank you for your support.

    I understand that you said.
    But this situation occured at only one time.
    Since it can not be reproduced, I2C capture, power supply, PDB can not be confirmed.
    As this happened, we think that there is a weak point somewhere.
    I want to identify the possibility of such a thing happening.
    As one of them, I wanted to know the bit arrangement in order to investigate whether there was a possibility of bit error between back channel communication between 913A and 914A.

    Best regrds,
    Tomoaki Yoshida
  • If they are not seeing this at all anymore it's going to be difficult to draw any conclusion. Perhaps there was a one-time power supply droop in the system that could have affected LOCK and I2C communication.
    If they want to investigate the back channel data integrity between the 913A and 914A, there are backchannel CRC error registers they can read - registers 0x0A and 0x0B on the serializer.