• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 63 subscribers
  • Views 1012 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.

UCD90120A: Device unresponsive to I2C/SMBus communications following interrupted block read

Francis Danforth82
Prodigy 60 points
Part Number: UCD90120A

Hello,

We have a number of UCD90120A monitors in a system that are powered via standby power. On occasion we have seen instances where a device will become unresponsive to SMBus communication. We believe that this state is triggered by an interrupted block read transaction due to system fault (the master device halts communication suddenly).

Is there any method or interface recommended for recovering communications? We have attempted the standard practice for recovering I2C communications through toggling the SCL line from the master device while not driving SDA. We are looking for a solution that would not require resetting the UCD90120A.

Thank you in advance

  • 0
    TI__Guru 66120 points
    Do you mean UCD NACK the address? Are either SCL or SDA holding low anyhow after master halts communication suddenlty?
    try to do a single page command(0x00) with payload 0x00 to see whether the device response if both SCL/SDA are high.

    Regards
    Yihe
  • 0 in reply to yihe
    Prodigy 60 points

    I am working to get visibility onto the bus at the moment as it is physically inaccessible. Only UCD devices are present on the bus (as many as 6). SDA and SCL are confirmed to not be held low from the master. In this state, the single page command with a 0x00 payload results in a NACK.

    If it is the case that one of the UCD devices is holding SDA or SCL is there guidance on how to recover?

  • 0 in reply to Francis Danforth82
    TI__Guru 66120 points
    If the SCl is hold low more than 35ms, UCD resets its I2C module to release the SCL. Does that particular UCD device function well, for example it can power up the configured rail? if you can get a waveform it will help us to see? how about other UCD devices in the same bus, do you have problem to access them?

    Regards
    Yihe
  • 0 in reply to yihe
    Prodigy 60 points

    I am still working to gain support on capturing a waveform. Outside of lockups, the device is functioning appropriately, in terms of power sequencing and monitoring. It has occurred on multiple different UCD devices, on different systems and buses. The bus that we are able to induce this on most reliably has only one UCD device on it, so I can not confirm right now that other devices are inaccessible.

    yihe said:
    If the SCl is hold low more than 35ms, UCD resets its I2C module to release the SCL.

    Are you stating that if the UCD holds the SCL longer than 35ms (due to clock stretching?) then it will reset it's own I2C controller and release both SDA and SCL? Or are you stating that a master can reset the UCD's I2C controller by holding SCL low for 35ms, releasing both SDA and SCL? If a master can reset the UCD I2C controller (without resetting the entire UCD device), that would provide us a good software mitigation.

  • 0 in reply to Francis Danforth82
    TI__Guru 66120 points
    I meant clock streching that's the only time slave will hold the SCL. but you can try to hold the SCL low more than 35ms after the 8th pusle of each byte.
    Do you mean for this particular case, there is only one UCD on the bus and the SCL is not low from master side.
    you may do a experienment to send a page command to all valid possbile address to see whether the ucd address is changed ?

    Regards
    yihe
  • 0 in reply to yihe
    Prodigy 60 points

    The device address has definitely not inadvertently been changed. The only transactions being sent are page set commands and block reads. Most devices have the address set by resistors. I was able to gain some scope captures. It has been verified that the bus is not held low by any device when the UCD is unresponsive. Attached are two captures of the device NACKing. Forcing SCL low by the master for greater than 35ms was not successful in recovering the device. The FPGA master that is communicating with device does not transmit the page set command byte following the address transmission.

    Besides a hard reset of the UCD device, do you have any other suggestions for recovery?

  • 0 in reply to Francis Danforth82
    TI__Guru 66120 points

    you can see from the waveform, the NACK is happend on the address. it seems that the address is wrong or it has been changed.

    Do you have the usb-to-gpio dongle from TI.  If so you can connect this to your board and launch the TI fusion GUI to see what address is detected.

    You only need SCL/SDA/GND to work with dongle.

    Regards

    Yihe

  • 0 in reply to yihe
    Prodigy 60 points

    The I2C address has not been changed. A hard power cycle makes the device recoverable, at the expected I2C address. The address is set using fixed resistors. In the PMBus command reference SLVU352E, I do not see any mention of a command to change the device address. Is there something I am overlooking in this reference?

  • 0 in reply to Francis Danforth82
    TI__Guru 66120 points
    If the device can be detected after a power cycle at assigned address, the address is correct.
    Is this the same case as what Dan Fischer reported?
    I2C master need support clock stretching in order to communicate with UCD.
    Regards

    Yihe
  • 0 in reply to yihe
    Prodigy 60 points

    I am unable to find the mentioned post from Dan Fischer. Our decided solution is to add a mechanism to hard reset the device.