• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 64 subscribers
  • Views 1230 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.

UCD9090: Invalid Log Flag Continuously Set

Thomas Moreno
Prodigy 170 points
Part Number: UCD9090
Other Parts Discussed in Thread: UCD90160, , UCD90160A, , UCD90120

Regarding UCD9090/A UCD90160/A

Situation:

On a UCD90160A, we recently saw the “Invalid Logs” bit set on all MFR-Status registers. This coincided with the Status-Byte = 0x01 and Status-Word = 0x1001. A power cycle of the unit did not clear any of these registers. On this device, we also have GPI faults enabled.  If the GPI faults are disabled, all status registers go clear.  Re-enabling the faults causes these registers to get set again.  We have other products that use the UCD9090 device. When this error showed in the UCD90160A, I checked the UCD9090 devices. I discovered that the “Invalid Logs” bit was set on all MFR-Status registers but the Status-word = 0x1000 and the Status-Byte = 0x00.

Questions:

For the second case above (Status-word = 0x1000 and the Status-Byte = 0x00) – is this an illegal combination? That is, how can the LSB of the status-byte be 0 and a bit is set in the upper byte of the Status Word? Isn’t the LSB of the Status Byte supposed to be set to indicate whenever any bit in the upper byte is set? Or does this mean, if the Status-Byte is equal to 0x00, all other status registers be ignored regardless of what bits are set?

For the first case above, I understand that the checksum can get interrupted on a shutdown and therefore be corrupted. However, the faults that are being logged happen at time that the device is fully powered. So why would the fault logs get corrupted?

 Question Regarding Fault Logging.

According to the PMBus Spec, if a fault is still present when the fault “bit” is cleared, the fault “bit” shall immediately be set again and the host notified in the usual means. My observation is that whenever a fault occurs and is cleared, but the fault is still present, the fault is not logged again. Is this the intentional behavior of all the UCD devices?

  • 0
    TI__Guru 66060 points
    Hi

    For the invalid log bit, it can not be cleared by the command. once it is set, it will be cleared on the next reboot automatically if the log is not corrupted.

    This applies to all UCD devices.

    Regards
    Yihe
  • 0 in reply to yihe
    Prodigy 170 points
    Thanks for the quick response. I understand about clearing the invalid log bit.

    I still need to know 2 things:
    1. If the status-byte is equal to 0x00, can all other status commands (STATUS_CML, MFR_STATUS, etc), regardless if their bits are set or not, be ignored?

    2. Condition: A rail or GPI fault is logged (LOGGED_FAULTS(EAh)) and the fault condition persists.
    Question: If the fault log is cleared (and the fault condition still exists), should the fault be logged again into LOGGED_FAULTS(EAh)?
  • 0 in reply to Thomas Moreno
    TI__Guru 66060 points
    1. STATUS_BYTE is only low 8bit of the STATUS_WORD. Please goto Fusion GUI->Status->Status Registser. Please look at STATUS_WORD to determine whether there is any events but not on STATUS_BYTE.
    2. no, GPI is edge triggered event, after the fault log is cleared, the fault does not re-log event the GPI stay de-asserted. It only re-log if the GPI changes from asserted to de-asserted.

    Regards

    Yihe
  • 0 in reply to yihe
    Prodigy 170 points
    Again - thanks for the quick reply.
    Fault behavior is clear now.

    From your answer on the Status-Byte, it appears these devices do not follow the PMbus Spec. Do you agree?
    The PMBus Spec Part II, Section 17.1 Table 14 defines the status-byte bit 0 as "NONE OF THE ABOVE" with the meaning "A fault or warning not listed in bits [7:1] has occurred"
    It further states in section 10.3 that the PMBus protocol provides three levels of status registers. This allows the host or system managers to retrieve the most important information in a fast, one byte transaction.
    I interpret this to mean that if the status-byte is 0x00, then there's is no need to read any other status register. If the status is not 0x00, then the host needs drill into the status levels.
    It appears that the ucd devices do not follow this definition, therefore our UCD9090s that reports status-word=0x1000 and MFR_status=0x00000080 are really indicating invalid logs. In our case,this condition is persistent, even across power cycles. If these logs are unusable/unreliable, then we lose one of the major reason for using these devices. Can someone work with me to resolve this issue? Perhaps it's a configuration issue.
    Last question: How is the host supposed to interpret bit 0 of the status-byte?
  • 0 in reply to Thomas Moreno
    TI__Guru 66060 points
    HI Thomas
    You are right. UCD9090 did not handle the bit0 of status_byte properly for the MFR information. This issue was fixed in the UCD9090A which is pin-to-pin compatible with UCD9090. For UCD9090, please use STATUS_WORD instead of STATUS_BYTE to determine the status of the device.

    In the UCD9090, there are ping-pong buffer for the fault logging. After ping buffer is updated with new fault, pong buffer is going to be erased for the next fault. If the device lost its power before finishing writing the fault into one buffer, on the next power cycle, INVALID bit is set but the fault log on the other buffer is still valid and can be retrieved.
    If you do not want to see a invalid log bit set, a brown-out circuit is required to hold the VCC from 2.9V to 2.6V for 5ms with 80mA, in this way, UCD can finish all the logging before VCC vanishes. you have to enable the brown-out feature in the globla configuraiton->misc config if brown-out ciruit is in placed.

    Hope this helps.

    Regards

    Yihe
  • 0 in reply to yihe
    Prodigy 170 points

    Thanks - this is making a lot more sense. I assume the UCD90160 and UCD90160A have the same status-byte situation?

    Can you point me to the errata for these devices UCD9090/A, UCD90160/A and UCD90120/A.

    This doesn't resolve the issue we have with invalid logs but it gives some things to look at.

  • 0 in reply to Thomas Moreno
    TI__Expert 4640 points
    Hi Thomas,
    You might find the information that you are looking for in these documents available in the "A" product folders:
    UCD9090/A and UCD90160/A: www.ti.com/.../slva908
    UCD90120: There is an errata document for the non-A devices (www.ti.com/.../slvz014). I assume that this errata constitute the enhancements in the "A" devices, but I'm not 100% positive. Maybe Yihe can elaborate.
    - Mark