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.

UCD90160: I2C Timing

Part Number: UCD90160

Hi Team,

Good afternoon, my customer is using two of the UCD90160s in their design. They have seen inconsistent issues with the device responding with all Fs and is looking deeper at the timing parameters.

Along with this, we have a couple questions:

- How will the device behave if the I2C line is held low for longer than 35ms between the command cycle and read cycle?

- What is the best way to recover from a case where the device responds with bad data (all Fs for instance)?

- In some cases after the bad data has been sent, the following transfers are also messed up or NACed

Thank you!

Regards,

~John

  • Hi John

    The I2C timing of UCD90160 meets the timing defined in the I2C spec Table 10 of https://www.nxp.com/docs/en/user-guide/UM10204.pdf  

    The I2C master need support clock stretching in order to communicate with UCD90160.

    If the I2C line is held low for more than 35ms, UCD90160 will reset its PMBUS module to release the SCL and abort the current operation.

    Under which Circumstances, UCD responded with 0xFF. did you have waveform to share? what're the inconsistent issues between two UCD90160?

    Regards

    Yihe

  • Hi Yihe,

    Thank you for the quick response and confirmation on the device's response after 35ms.

    The circumstances under which the device responded with 0xFF is being looked at more, because of it's inconsistency, there isn't a scope capture available yet.
    To answer your second question - the inconsistency is with the 0xFF response, not between the two devices.

    Regards,
    ~John
  • Hi Yihe,

    After further testing, the UCD is resetting because of a 35ms delay between the command and the read clocks.

    A couple follow-up questions:
    1. How long does the PMBus Module take to reset and abort the current operation before communication can resume again?
    2. During this reset, does the device hold down the SCL or SDA lines to indicate to the host this reset?

    Thank you!

    Regards,
    ~John
  • Does UCD hold SCl low for 35ms when master performs a block read command?

    if this is the case, hope this helps:

    For the block read type commands, if host reads more data than what the command supports, UCD90160 holds SCL low since at this point the device expect the transaction is finished and there is no more data to send out. Therefore the SCL is low until 35ms timeout.

    Let’s take example of the 0xFD command, for this command, the real data size is 0x1B(27). If counting size itself + PEC, the total size is 29.
    If host try to ready data no more than 29 bytes, device functions as expected. But PMBus timeout is present when host read more than 29 bytes.

    The correct way to perform block read is to follow below and avoid 35ms timeout:
    1. Read one byte first this will tell the exact the length of data to read
    2. Read the length + 1 or length + 2(if PEC is required)

    Could you check your cusotmer about how they perfrom block read?

    Regards

    Yihe
  • Hi Yihe,

    That is not the case - the issue is coming from the host side holding the SCL line for >35ms.

    The questions around the reset are a follow-on to understand once the host sees this error, how to correct for it:
    1. How long does the PMBus Module take to reset and abort the current operation before communication can resume again?
    My thought here is that waiting 35ms will be long enough for the full reset to occur and to start communication again.
    2. During this reset, does the device hold down the SCL or SDA lines to indicate to the host this reset?
    For this second question, the customer has seen the UCD device hold SCL low during this reset period.

    Regards,
    ~John
  • Instead of correct, why not fix the timeout issue from host side. The host shall not hold the bus low more than 10ms based on the PMBus spec.

    1. I do not have the number. But the rest shall be accured after 35ms timeout. But if the SCL is hold low by master, i am not sure the reset initialized by UCD will help or not.
    2. The SCL/SDL shall be released as soon as reset is finished.for this case, the reset is due to host holding SCL, i do not think UCD is hold low during the reset.

    Regards

    Yihe